A contractor needs time-limited read-only access to a staging AWS account. Which design best matches temporary, conditional access?
Select an answer to reveal the explanation.
Short Explanation
Contractors get a visitor badge that expires—not a forever master key mailed in plain text. A read-only role with a short session and MFA condition matches that idea. Permanent admin users and shared keys are how staging becomes a standing risk.
Full Explanation
A contractor who needs time-limited read-only access to a staging AWS account should receive an IAM role (or Identity Center assignment) with read-only permissions, a short maximum session duration, and preferably an MFA condition on AssumeRole—not a permanent IAM user whose password was emailed in cleartext. Temporary sessions expire, can be revoked by updating the trust policy, and leave clearer CloudTrail evidence via role session names. That mirrors a visitor badge to the staging annex that stops working after the engagement.
Creating a permanent IAM user with AdministratorAccess and emailing the password without MFA maximizes privilege, duration, and disclosure risk. Sharing an existing employee's long-lived access keys over SMS mixes identities and spreads secrets on an insecure channel. Publishing staging root credentials on an internal wiki offers standing unrestricted access to anyone who can read the page—past and present.
Exam caveat: AWS STS session durations have maximums based on role configuration; contractors from external accounts should assume a cross-account role with an external ID when appropriate. Prefer AWS managed ReadOnlyAccess only if truly needed; otherwise scope to staging resource ARNs. Operational check: assume the contractor role, confirm Describe/List succeed and Create/Delete fail; wait for session expiry or revoke by removing the trusted principal; confirm email/wiki contain no passwords or keys.