Outside contractors need temporary access to a city AWS account without long-lived shared IAM user passwords. Which IAM identity approach best fits that temporary access pattern?
Select an answer to reveal the explanation.
Short Explanation
Roles are visitor badges that expire — contractors assume a role, get temporary credentials, and leave without owning a permanent shared login. Shared passwords, root emails, and public access keys are how temporary work turns into permanent risk.
Full Explanation
Outside contractors who need temporary access should assume an IAM role that issues temporary credentials instead of sharing long-lived IAM user passwords. Roles are visitor badges that expire — contractors assume a role, work, and leave without owning a permanent shared login. Creating one shared IAM user password posted in chat for all contractors creates non-attributable standing access. Disabling MFA and emailing the root password for the engagement window is severe malpractice. Storing permanent access keys in a public S3 bucket labeled "temporary" converts a label into a lie attackers will find. Distractors fail by preferring shared secrets, root exposure, or public key dumps over temporary role assumption. Exam caveat: cross-account or identity-provider-assumed roles are the usual pattern; still apply least privilege and short durations. Operational check: define a contractors role with minimal permissions, require MFA on assume-role where applicable, set session duration limits, log AssumeRole events, revoke trust when the engagement ends, and forbid shared user passwords in procurement language. In practice, expire contractor role trusts on the contract end date, require ticketed assumption reasons, and ban shared chat passwords in vendor onboarding checklists.