A municipal CI job running in account A must deploy CloudFormation stacks into account B. How should cross-account automation authenticate?
Select an answer to reveal the explanation.
Short Explanation
The pipeline in account A should knock and borrow a deployment badge from account B—not carry B’s long-lived keys in its pocket. A trusted cross-account role gives temporary deploy rights. Keys in plaintext or root passwords in logs are automation anti-patterns.
Full Explanation
Municipal CI that runs in account A and deploys CloudFormation into account B should authenticate by assuming a cross-account deployment role in B. The role's trust policy allows the pipeline principal in A (CodeBuild role, GitHub OIDC role, etc.); its permissions policy allows cloudformation:*, required IAM pass-role for named roles, and service deployments needed by the stacks. The pipeline calls AssumeRole (or uses OIDC federation into that role), deploys with temporary credentials, and never stores B's long-lived keys.
Committing account B access keys as plaintext CI variables embeds standing secrets in the pipeline system and often in logs. Disabling IAM in B and deploying with anonymous API calls is not a valid AWS pattern—unsigned anonymous calls cannot manage CloudFormation in a private account. Pasting B's root password into build logs exposes unrestricted credentials in an immutable artifact store.
Exam caveat: for GitHub Actions or similar, prefer OIDC federation to IAM roles over access keys. Limit the deployment role with permissions boundaries and SCPs; use separate roles for plan versus apply when possible. Operational check: run the pipeline and confirm AssumeRole into B succeeds; revoke trust and confirm deploy fails; scan CI variables for AKIA keys related to B and remove them; verify CloudTrail in B attributes stack events to the deployment role session.