A municipal permits team keeps development, test, and production CloudFormation stacks in separate AWS accounts with distinct parameter sets. What environment-management practice should they follow when promoting a release?
Select an answer to reveal the explanation.
Short Explanation
Think of three locked rooms with different keys—not three copies of the same room. Dev, test, and prod stay in separate accounts with their own parameters, and you promote the same reviewed build instead of freestyle rebuilds. That discipline keeps civic prod from inheriting laptop surprises.
Full Explanation
For municipal permits stacks, environment management is about promoting a single reviewed application artifact through isolated AWS accounts while keeping environment-specific parameters—and secrets—out of shared mud. Development, test, and production CloudFormation (or CDK-synthesized) stacks should live in separate accounts or at least under strongly separated parameter sets so a bad experiment in development cannot silently rewrite production citizen data. The correct practice is therefore to promote the same reviewed build with disciplined configuration: the binary or packaged template does not freestyle-rebuild on a laptop for production, and each account retains its own parameter values for VPC IDs, table names, alarm ARNs, and secret references. That pattern matches how city change boards expect releases to move: one stamped crate, three locked rooms, different keys.
Rebuilding production from a developer's laptop parameters fails because it breaks artifact immutability and injects unreviewed, machine-local configuration into the highest-risk civic environment. Copying production secrets into the development account so stacks stay "identical" collapses secret isolation and expands blast radius when a junior account is compromised. Merging all three environments into one account with identical parameters simplifies the wrong thing—audit boundaries, blast radius, and least-privilege roles—while making accidental cross-environment writes far more likely.
Exam caveat: DVA-C02 asks developers to manage application environments and promote safely with CI/CD and IaC; it does not require inventing a full multi-account landing-zone product. Account separation plus parameter discipline is enough conceptual framing.
Operational check: confirm the pipeline publishes one artifact version ID, that each stage's CloudFormation/CDK parameters resolve from the target account's parameter store or pipeline variables (not a laptop file), and that production secrets never appear in development parameter sets or commit history before the next permits release.