A CI pipeline role may deploy one SAM stack in the city’s test account but must not create IAM users. How should that deploy principal be scoped?
Select an answer to reveal the explanation.
Short Explanation
Hand the pipeline a work order for one SAM stack, not the keys to create contractor IAM users. Least privilege for deploy roles means CloudFormation/SAM powers without identity-admin powers. Root keys in CI are a citywide incident waiting to happen.
Full Explanation
A CI pipeline that deploys one SAM stack in the city’s test account should receive least-privilege permissions for the resources that stack creates and manages, while explicitly excluding IAM user administration such as iam:CreateUser and iam:CreateAccessKey. Deploy principals need CloudFormation and service permissions for the template—not standing authority to mint long-term human users during every deploy.
Attaching AdministratorAccess makes deploys convenient while allowing catastrophic lateral movement if the pipeline role is compromised. Allowing iam:CreateUser and CreateAccessKey on "*" for convenience directly violates the constraint in the stem. Using account root user access keys in the pipeline is never an acceptable simplification for municipal CI.
Exam caveat: SAM and CloudFormation often need iam:PassRole for roles they create—grant PassRole narrowly on those roles rather than opening full IAM user administration. Operational check: deploy the SAM stack successfully with the tightened role, attempt iam:CreateUser from the same principal and confirm denial, then review CloudTrail for unused broad permissions that can be removed from the pipeline role. For municipal workloads, document the chosen pattern in the runbook so the next on-call engineer applies the same control instead of inventing a weaker shortcut under pressure.