A city auditor requires that a contractor AWS account may deploy into a project account only through a break-glass role that enforces MFA and short session durations. Which cross-account access design best satisfies the auditor?
Select an answer to reveal the explanation.
Short Explanation
Break-glass means a monitored, temporary key—not a spare admin badge left under the mat. Contractors assume a tight role with MFA and short sessions, then leave. Long-lived admin keys in their laptops fail the audit before lunch.
Full Explanation
Auditor-friendly contractor access into a project account uses a break-glass IAM role in the project account that trusts the contractor account, requires MFA via condition keys, and enforces a short maximum session duration. Contractors receive only sts:AssumeRole into that role—not standing AdministratorAccess inside the project account—and never long-lived project-account access keys on laptops. Temporary credentials bound to MFA and time limits satisfy break-glass intent while preserving a clear audit trail of who assumed what and when.
Issuing long-lived IAM access keys with AdministratorAccess to contractor laptops creates persistent standing privilege the auditor rejected. Adding the contractor account as a full Organizations management-account peer with SCPs disabled expands blast radius far beyond a single project break-glass path. Allowing anonymous account access with resource policies that skip principals and MFA removes authentication guarantees entirely.
Exam caveat: cross-account AssumeRole with aws:MultiFactorAuthPresent (and session duration limits) is the classic pattern; external ID may also appear for third parties, but MFA and short sessions are the stem’s explicit controls. Operational check: attempt AssumeRole without MFA and confirm denial, succeed with MFA, verify session expiry matches the short max duration, and review CloudTrail for AssumeRole events tied to contractor principals.