Build and test run in a shared tools account, but production lives in separate accounts. How should CI/CD deploy safely across those accounts?
Select an answer to reveal the explanation.
Short Explanation
The tools account builds; production stays locked unless the pipeline puts on a temporary badge. Cross-account roles let CodePipeline deploy without parking root keys in the workshop.
Full Explanation
When builds run in a shared tools account and production lives elsewhere, safe promotion depends on temporary, auditable cross-account role assumption rather than copied secrets. CodePipeline can orchestrate build, test, and deploy while assuming IAM roles into production accounts for the duration of each stage—credentials stay short-lived and CloudTrail attributes who deployed what for municipal auditors. Sharing long-lived root credentials from production into build agents is a critical anti-pattern that expands blast radius and fails least privilege. Copying production access keys into plaintext CodeBuild environment variables embeds durable secrets in configuration that is easy to leak through logs or parameter exposure. Deploying only from a developer laptop VPN with personal IAM users bypasses pipeline controls, peer review, and consistent audit trails. Exam caveat: the production deploy role must be tightly scoped and trust only the tools-account pipeline principal—over-broad AdministratorAccess on the assumed role recreates the secret-sharing risk in role form. Operational check: run a pipeline deploy, confirm STS AssumeRole events from the tools account into production, verify no static production keys exist in CodeBuild environment variables, and attempt a deploy with the trust policy removed to prove it fails closed.