Implementation and Deployment
Implementation questions probe whether you can move from an approved design to a repeatable, reversible rollout.
Provisioning and automation
Understand infrastructure as code. Declarative definitions describe the desired end state and are idempotent - applying them twice yields the same result. Imperative scripts describe the steps and are not naturally idempotent, so re-running them risks duplicates or errors. Templates and modules should be version-controlled and reviewed like application code.
Release strategies
- Blue-green: two full environments; traffic switches at once; rollback is a switch back.
- Canary: a small slice of traffic goes to the new version first, then expands as metrics stay healthy.
- Rolling: instances are replaced in batches, so both versions coexist briefly.
Pipelines and parity
A healthy pipeline builds once, tests automatically, promotes the same artifact through environments, and injects secrets at runtime rather than baking them into images. Environment parity matters: differences between test and production are a leading cause of failed releases.
Traps
- Calling a script "infrastructure as code" when it is imperative and non-idempotent.
- Confusing blue-green (instant full cutover) with canary (gradual exposure).
- Forgetting that a deployment plan needs a rollback plan, including data-schema reversibility.
- Storing credentials in a repository or image layer.
Rule of thumb
Deploy small, verify against your SLIs, then expand. If you cannot describe how to undo the change in one sentence, the plan is not finished.