A team copies an AMI once through the console for a lab, but every production release must update identical multi-resource stacks the same way. Which practice should they choose for those ongoing identical deploys?
Select an answer to reveal the explanation.
Short Explanation
One AMI copy in the console is fine for a lab one-off. For every release that must look the same, switch to a repeatable IaC path like CloudFormation stack updates.
Full Explanation
Copying an AMI once through the console is fine for a lab, but every production release that must update identical multi-resource stacks the same way should use CloudFormation stack updates or equivalent infrastructure as code. IaC versions the full environment—compute, IAM, load balancing, networking references—so each release applies the same declared state instead of relying on a one-time AMI copy ritual that does not rebuild accompanying resources consistently.
Using console AMI copy as the forever process for every identical production release does not manage the surrounding stack and invites drift. Ad-hoc console clicks whenever two environments must match exactly scale poorly and defeat auditability. Emailing AMI IDs is not a release orchestration system; it lacks validation, approvals, and dependency ordering.
Exam caveat: Distinguish a single manual action (AMI copy) from ongoing identical multi-resource deploys (IaC). Cloud Practitioner loves “repeatable / identical / multi-resource” cues for CloudFormation or IaC.
Operational check: store templates in source control, promote the same change set through lab → staging → production municipal accounts, parameterize environment-specific values, and treat AMI IDs as parameters or data lookups inside the template rather than as the entire release process. Review stack drift detection results after emergency console changes.