An AWS account administrator created an IAM group and applied the following managed policy to require that each individual user authenticate using multi-factor authentication: After implementing the…

Question

Exhibit

Options

• AChange the value of aws:MultiFactorAuthPresent to true.
• BInstruct users to run the aws sts get-session-token CLI command and pass the multi-factor
• CImplement federated API/CLI access using SAML 2.0, then configure the identity provider to
• DCreate a role and enforce multi-factor authentication in the role trust policy. Instruct users to run

• A
  8% (2)
• B
  72% (18)
• C
  16% (4)
• D
  4% (1)

Explanation

When the IAM policy includes a condition like aws:MultiFactorAuthPresent: true, long-term access key credentials used directly by the CLI do not satisfy this condition - the CLI call fails because no MFA context is attached. Running aws sts get-session-token --serial-number <mfa-arn> --token-code <code> generates temporary session credentials that do carry the MFA context, satisfying the policy condition and restoring EC2 access.

Why the distractors are wrong:

• A is wrong because the policy already requires MFA (true); changing the condition value doesn't fix the root problem - users simply aren't presenting MFA-backed credentials via the CLI.
• C is wrong because SAML 2.0 federation is a heavyweight solution for a different use case (SSO/enterprise identity); it doesn't directly solve the CLI MFA problem and introduces unnecessary complexity.
• D is wrong (or at least suboptimal) because role assumption with MFA in the trust policy is a valid but more complex architecture - it requires creating and maintaining a role, whereas get-session-token solves the problem with no structural changes.

Memory tip: Think of sts get-session-token as the CLI's MFA badge scanner - you swipe your MFA code once to get a temporary badge (session token) that proves you authenticated with MFA, which the policy then accepts.

No community discussion yet for this question.