A stack update for the grants API must refresh staging without changing production parameters. What is the correct targeting approach?
Select an answer to reveal the explanation.
Short Explanation
Staging is not a teleport into production. Point the SAM/CloudFormation update at the staging stack and staging parameters only. Mixing change sets or copying prod parameter sets is how civic outages start.
Full Explanation
A stack update for the grants API that must refresh staging without changing production should deploy the SAM or CloudFormation update to the existing staging stack and its staging parameters only, leaving the production stack untouched. Environment targeting is deliberate: municipal change sets are applied to named stacks with named parameter sets, not sprayed across production and staging in one combined operation that couples their fates.
Applying the same change set to production and staging stacks in one combined operation fails because production then receives unproven staging-bound changes without a separate gate. Overwriting production parameter values with staging values to keep environments identical fails conceptually by breaking intentional environment isolation and risking staging secrets or endpoints in production. Deleting the production stack first so staging can reuse resource names fails as a catastrophic approach to naming conflicts.
Exam caveat: confirm pipeline roles are scoped so a staging job cannot assume production deploy permissions accidentally through overly broad IAM. Operational check: run the update against the staging stack ARN only, diff production stack parameters afterward to ensure they are unchanged, and promote only after staging validation passes.