A new city permit API needs IAM roles that separate read-only auditors, deployment pipelines, and runtime application tasks. Which design best follows least privilege?
Select an answer to reveal the explanation.
Short Explanation
Auditors peek, pipelines ship, the app runs—three badges, three jobs. One shared god-role is how a read-only visit turns into a production remodel.
Full Explanation
A new city permit API needs separation of duties among auditors, deployment pipelines, and runtime application tasks under least privilege. Distinct roles—auditors with read-only access, deployers with release permissions, and runtime tasks limited to APIs the app needs—with no shared long-term admin keys implement that separation cleanly. Giving every human and service AdministratorAccess in one shared role maximizes blast radius for speed. Embedding a root-equivalent access key in the API container collapses personas into one stolen secret. Granting auditors permission to delete production databases so they can fully test recovery violates least privilege and court-adjacent change control. Exam caveat: role design must pair with permission boundaries, SCPs, and secret-free runtime identity such as task roles. Operational check: attempt an auditor read of CloudTrail without write APIs, deploy with the pipeline role only, confirm the runtime role cannot IAM-mutate, and verify no static admin keys exist in images or parameter stores. In municipal cloud governance, record the owners, success metrics, and rollback or restore contacts beside this technical choice so the next incident, budget review, or audit does not rediscover the decision from scratch under time pressure.