AWS Systems Architect Professional

AWS IAM Authentication Methods and MFA – SAP-C02 Study Guide

Learn AWS IAM console and programmatic authentication, access keys, MFA factors, device types, security best practices, and SAP-C02 exam traps.

AWS Systems Architect ProfessionalAWS Systems Architect ProfessionalUpdated Sep 1, 2026
Study options
WatchComing later
ListenComing later
ReadAvailable
ReviewComing later

Study guide

Technical reference and lesson notes

Purpose of This Lesson

AWS Identity and Access Management (IAM) authentication establishes who or what is making an AWS request. Authorization is a separate step that determines which actions that authenticated identity is allowed to perform.

This lesson focuses on IAM user authentication for:

  • The AWS Management Console
  • The AWS CLI and AWS APIs
  • Multi-factor authentication (MFA)
  • Root and IAM user protection

Key Concepts

Authentication Versus Authorization

  • Authentication verifies an identity.
  • Authorization evaluates policies to determine whether that identity can perform an action on a resource.

For example, a user might successfully authenticate to the AWS Management Console but still be denied access to an S3 bucket because no applicable IAM policy allows the requested operation.

Console Authentication

IAM users typically access the AWS Management Console with:

  • An IAM account identifier or account alias
  • A username
  • A password
  • An optional MFA code or security-key confirmation

The AWS account root user also uses console credentials, but it is not an IAM user and should not be used for routine administration.

Programmatic Authentication

The AWS CLI, SDKs, and direct API clients use programmatic credentials. For an IAM user, these are commonly represented by:

  • Access key ID: Identifies the access-key pair
  • Secret access key: Secret material used to sign AWS requests

An access key pair is a form of long-term credential. It remains usable until it is deleted, deactivated, or rotated. The secret access key is shown only when the key is created, so it must be stored securely at that time.

Access keys are not equivalent to a password in every implementation detail, but they serve a similar purpose for programmatic authentication: they allow software to authenticate as the associated identity.

MFA Factors

MFA combines two or more independent authentication factors:

  1. Something you know — such as a password or PIN
  2. Something you have — such as a virtual MFA device, hardware token, or security key
  3. Something you are — such as a fingerprint or retinal characteristic

AWS IAM commonly uses the first two factors. A password alone is a single-factor authentication method; requiring an additional device or token makes account compromise more difficult.

AWS MFA Device Types

Common MFA options include:

  • Virtual MFA devices: Authenticator applications that generate time-based one-time passwords (TOTP), often on a smartphone.
  • Hardware TOTP devices: Physical devices that generate rotating authentication codes.
  • FIDO security keys: Hardware security keys that use public-key cryptography and user interaction to authenticate.

MFA devices are associated with an identity. The device must be available when the identity signs in or performs an operation that requires MFA.

MFA for CLI and API Requests

MFA is not limited to console sign-in. Programmatic workflows can also require MFA. A common pattern is:

  1. The user authenticates with long-term credentials and supplies an MFA code.
  2. AWS Security Token Service (STS) issues temporary security credentials.
  3. The CLI, SDK, or application uses the temporary credentials for subsequent requests.
  4. IAM policies can require the request context to include MFA, commonly through conditions involving aws:MultiFactorAuthPresent.

This approach allows organizations to protect sensitive programmatic operations without embedding a permanent access key in scripts.

Exam-Relevant Takeaways

  • Console access generally uses a username and password, with MFA as an additional factor.
  • CLI and API access uses access keys or, preferably, temporary credentials obtained through an IAM role or STS.
  • An access key consists of an access key ID and a secret access key.
  • IAM user access keys are long-term credentials and require rotation, protection, and eventual replacement.
  • MFA protects against password-only compromise but does not replace authorization policies.
  • Enable MFA on the AWS account root user, especially the root user’s console access.
  • Enable MFA for privileged IAM users when IAM users are required.
  • For workloads, prefer IAM roles and temporary credentials over IAM user access keys.
  • MFA can be required for API operations by using STS and IAM policy conditions.

Architecture Decision Guide

RequirementRecommended authentication approachImportant consideration
Human console accessIAM Identity Center or an appropriately governed IAM identityRequire MFA and least privilege
Emergency root accessRoot user credentials protected with MFADo not use root for routine work
AWS CLI access for a humanFederated or IAM Identity Center credentials, or temporary STS credentialsAvoid persistent user access keys where possible
Application access to AWS servicesIAM role with temporary credentialsDo not embed IAM user keys in application code
Legacy integration requiring a user keyDedicated IAM user with tightly scoped access keyStore securely, rotate, monitor, and replace when possible
API action that must require MFATemporary credentials obtained using MFA and an IAM policy conditionMFA authentication and permissions are separate controls

Common Exam Traps

  • Confusing authentication with authorization: A valid password or access key does not automatically grant permission to an AWS resource.
  • Treating MFA as authorization: MFA confirms an additional factor; IAM policies still determine what the identity can do.
  • Using IAM user access keys for workloads by default: IAM roles and temporary credentials are the preferred design for EC2, Lambda, ECS, and other AWS workloads.
  • Assuming an access key is temporary: Standard IAM user access keys are long-term credentials unless deactivated or deleted.
  • Protecting only IAM users but not the root user: The root user requires separate MFA protection.
  • Assuming MFA applies only to the console: API and CLI workflows can require MFA through STS and IAM policy conditions.
  • Storing the secret access key in source control: The secret must be treated as sensitive credential material and should never be committed to repositories.
  • Believing a virtual MFA device means weak MFA: A properly protected authenticator application still provides a second factor, although organizational requirements may favor phishing-resistant security keys.

Real-World Engineer Notes

  • Prefer centralized workforce authentication with IAM Identity Center and an external identity provider for human access in multi-account environments.
  • Use IAM roles for AWS services and federated users rather than distributing long-lived access keys.
  • If a long-term access key is unavoidable, use a dedicated identity, least-privilege permissions, secure storage, monitoring, rotation, and a documented revocation process.
  • Do not share credentials between administrators or applications. Individual identities improve accountability through CloudTrail and simplify access reviews.
  • Keep root credentials offline and use them only for tasks that specifically require root privileges.
  • Test MFA recovery procedures. Losing a phone or security key should not create an untested operational emergency.
  • MFA is one layer of defense. Combine it with least privilege, strong password policies, logging, anomaly detection, and separation of duties.

Quick Reference Summary

  • Console: Username and password, optionally combined with MFA.
  • CLI/API: Access key ID and secret access key, or preferably temporary role credentials.
  • MFA: Combines independent factors, usually a password plus a device-generated code or security key.
  • Root account: Enable MFA and avoid routine use.
  • IAM users: Enable MFA for privileged users when they are required.
  • Applications: Use IAM roles and temporary credentials instead of embedded long-term keys.
  • MFA-protected API calls: Use STS temporary credentials and IAM policy conditions that require MFA.

Flashcards

  1. Q: What is the difference between authentication and authorization in IAM?

A: Authentication verifies identity; authorization determines which actions that identity may perform.

  1. Q: Which credentials are commonly used for AWS Management Console access?

A: A username and password, potentially supplemented by MFA.

  1. Q: What two values make up an IAM access key pair?

A: An access key ID and a secret access key.

  1. Q: Are IAM user access keys long-term or temporary credentials?

A: They are long-term credentials until deactivated or deleted.

  1. Q: What are the three general MFA factor categories?

A: Something you know, something you have, and something you are.

  1. Q: Give two examples of AWS-compatible MFA devices.

A: A virtual authenticator application and a hardware TOTP device; a FIDO security key is another option.

  1. Q: Which AWS identity should always have MFA enabled?

A: The AWS account root user.

  1. Q: What should workloads use instead of embedded IAM user access keys?

A: IAM roles that provide temporary credentials.

  1. Q: Can MFA be required for CLI or API requests?

A: Yes. A user can obtain temporary STS credentials with MFA, and IAM policies can require an MFA-authenticated request context.

  1. Q: Does successful MFA automatically grant permission to an S3 bucket?

A: No. IAM and resource policies still determine authorization.

Practice Questions

Question 1

A company runs a data-processing application on Amazon EC2. The application needs to read from an S3 bucket. A developer proposes storing an IAM user access key and secret access key in the application configuration file. What is the best solution?

A. Store the access key in the EC2 user data script
B. Create an IAM role with least-privilege S3 permissions and attach it to the EC2 instance
C. Require MFA on the IAM user and store the credentials in the application
D. Use the root user credentials because the application is trusted

Correct answer: B

Explanation: EC2 applications should obtain temporary credentials from an attached IAM role. This avoids distributing long-term credentials and allows permissions to be managed centrally.

Question 2

An administrator must ensure that a sensitive IAM operation can be performed only after MFA authentication. Which approach meets this requirement?

A. Add MFA to the administrator’s password policy only
B. Use an IAM policy condition that requires MFA and obtain temporary credentials through STS after MFA
C. Add the administrator’s access key ID to the MFA device configuration
D. Enable MFA only for the root user

Correct answer: B

Explanation: MFA can be incorporated into programmatic access by obtaining temporary STS credentials after MFA and using an IAM condition such as aws:MultiFactorAuthPresent to control sensitive actions.

Question 3

An organization wants to protect its AWS account against a stolen root-user password. Which control is most appropriate?

A. Create a second root user
B. Enable MFA on the root user and restrict routine root-user use
C. Attach an administrator policy to an IAM user without MFA
D. Rotate the account alias regularly

Correct answer: B

Explanation: The root user is unique to the AWS account and cannot be replaced by another root identity. MFA adds a second factor, while restricting root use reduces exposure.

Question 4

A security team discovers an IAM user access key in a public source-code repository. What should the team do first?

A. Rename the IAM user
B. Deactivate or delete the exposed access key and investigate its use
C. Enable MFA on the IAM user and leave the key active
D. Change the AWS account alias

Correct answer: B

Explanation: An exposed secret access key must be treated as compromised. Immediately deactivate or delete it, investigate CloudTrail and other logs for unauthorized use, and replace the integration with a safer credential design where possible.