Break a deployment by getting the order wrong

short · 40 min · Objective 2.4

Task

Build a stack whose compute depends on an identity and a secret that nothing in the template connects it to, and watch it fail intermittently. Undeclared implicit dependencies are the cause of 'it works on the second run', and causing one on purpose is how you learn its signature.

Steps

  1. Write a stack with three resources: a secret, an identity permitted to read it, and a container whose startup script fetches the secret. Do NOT reference the secret or the identity from the container's definition.
  2. Apply from scratch several times, destroying in between. Record in lab/order.txt how many attempts succeeded and how many failed, and what the failure looked like from the container's logs.
  3. Add an explicit dependency from the container to both the secret and the identity.
  4. Apply from scratch several more times and record the results again.
  5. Write the signature sentence: what an intermittent deployment failure, or one that succeeds on a re-run, almost always means.

Verify

grep -Ec 'succeed|fail' lab/order.txt
grep -Eci 'depends|explicit' lab/order.txt
grep -Eci 'intermittent' lab/order.txt

The file must record failures before the fix and none after. If the first version never failed, the resources happened to be created in a lucky order -- increase the secret's creation time or add more resources until the race shows.

This is an independent study companion for CompTIA Cloud+ CV0-004 and is not produced by or endorsed by CompTIA.