Set Up an Individual AWS IAM User and Secure Account Access – SAP-C02 Study Guide

Purpose of This Lesson

AWS accounts begin with a root user, but day-to-day administration should use controlled identities instead. This lesson demonstrates how to create an IAM user, assign permissions through an IAM group, and sign in without using the root account.

For modern AWS environments, AWS IAM Identity Center with federation is generally preferred over creating long-lived IAM users for human access. IAM users remain relevant for specific compatibility requirements, legacy workflows, or carefully controlled use cases.

Key Concepts

AWS root user

The root user is created when the AWS account is created with an email address. It has unrestricted access to account resources and account-level functions. Root access cannot be limited by attaching an IAM policy to the root user.

Use the root user only for tasks that specifically require it, such as:

• Changing certain account settings
• Managing support plans or some billing-related functions
• Closing the AWS account
• Configuring or resolving root-user credentials and security controls

Protect the root user with a strong, unique password and multi-factor authentication. Do not create root access keys unless an exceptional requirement exists.

IAM users

An IAM user represents a long-term identity within one AWS account. An IAM user can have:

• A console password
• Access keys for programmatic access
• Permissions through group membership, identity-based policies, or both

A newly created IAM user has no permissions by default. It cannot access AWS services until permissions are granted.

For workforce identities, prefer IAM Identity Center and an external identity provider where possible. This provides centralized access, federation, and temporary credentials rather than relying on long-lived IAM user credentials.

IAM groups

An IAM group is a collection of IAM users. Permissions assigned to a group are inherited by its members. Groups are useful for applying a common job-function policy consistently, such as administrator, developer, or read-only access.

Groups cannot contain other groups, and IAM groups are not identities that can sign in directly. Users sign in individually and receive permissions from their group memberships.

IAM policies

IAM policies are JSON documents that define permissions. A simplified administrator policy effectively includes:

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

This grants permission for all actions on all resources and should be treated as highly privileged access. In production, follow least privilege and grant only the actions and resources required.

A policy can be attached to a user, group, or role. AWS managed policies are maintained by AWS, while customer managed policies can be tailored to an organization’s requirements. Inline policies are embedded directly into an individual identity and are generally less convenient to manage consistently at scale.

IAM console sign-in details

An IAM user signs in using:

• The AWS account alias or account ID
• The IAM username
• The IAM password
• MFA, if configured or required

The account alias makes the sign-in URL easier to use, but it does not change the account’s security boundary.

Exam-Relevant Takeaways

• The root user has unrestricted account access and should not be used for routine administration.
• Enable MFA on the root user and protect its credentials.
• An IAM user has no permissions by default.
• Permissions can be inherited through IAM group membership.
• IAM policies use explicit Allow and Deny statements. An explicit deny overrides an allow.
• Action: "*" and Resource: "*" represent extremely broad permissions.
• Prefer temporary credentials and federation for human access. AWS IAM Identity Center is the typical modern solution for centralized workforce access.
• Use IAM roles rather than IAM users for workloads running on AWS services, such as EC2, Lambda, and ECS.
• Avoid sharing one IAM user among multiple people. Individual identities improve attribution, auditing, and revocation.
• Apply least privilege rather than assigning AdministratorAccess by default.

Architecture Decision Guide

Requirement	Recommended approach	Reason
Initial AWS account protection	Secure root credentials and enable root MFA	Root access is unrestricted and should be reserved for exceptional account tasks
Workforce access across AWS accounts	IAM Identity Center with an external identity provider	Centralized sign-in and temporary role-based credentials
A person must access one account and federation is unavailable	Individual IAM user with MFA and narrowly scoped permissions	Better accountability than shared credentials, but less modern than federation
EC2, Lambda, ECS, or other AWS workload access	IAM role attached through the service’s identity mechanism	Temporary credentials avoid embedded long-lived access keys
Several users need the same permissions	IAM group or centrally managed permission set	Consistent access management and simpler revocation
One special-purpose identity needs a unique permission set	Role or customer managed policy, depending on the access model	Avoid unnecessary inline-policy sprawl
Full administration in a lab	AdministratorAccess group membership	Convenient for learning, but inappropriate as a production default

Common Exam Traps

• Assuming a new IAM user can immediately use AWS services: New users have no permissions until policies are attached directly or inherited.
• Using the root user for normal work: Root should be tightly protected and used only when required.
• Confusing account alias with username: The alias identifies the AWS account in the sign-in URL; the username identifies the IAM identity.
• Treating AdministratorAccess as least privilege: It grants broad access and is dangerous outside controlled labs or explicitly authorized administrator roles.
• Using IAM groups for application access: Groups organize IAM users. Applications should generally assume IAM roles or use service-integrated roles.
• Assuming an IAM allow is always sufficient: Explicit denies, permission boundaries, service control policies, resource policies, and session policies can limit effective permissions.
• Creating access keys for console-only users: Access keys are unnecessary when the user needs only console access and increase credential exposure.
• Selecting IAM users when IAM Identity Center is available: For human users, centralized federation and temporary credentials are usually the stronger architectural choice.

Real-World Engineer Notes

• Require MFA for privileged identities and consider phishing-resistant methods where supported.
• Use AWS Organizations and IAM Identity Center to manage access across multiple accounts rather than duplicating IAM users in every account.
• Monitor root and privileged activity with AWS CloudTrail and alert on unexpected use.
• Use IAM Access Analyzer to identify unintended external access and help refine policies.
• Start with job-function or resource-specific permissions, then expand only when a documented requirement exists.
• For break-glass administration, maintain a tightly controlled emergency procedure rather than using shared administrator credentials for everyday work.
• Remove inactive IAM users and rotate or disable credentials according to organizational policy.
• A group-based design is easier to audit than attaching different ad hoc policies to every individual user.

Quick Reference Summary

• Root user: unrestricted, protected with MFA, rarely used.
• IAM user: long-term identity with no permissions by default.
• IAM group: collection of users receiving common permissions.
• IAM policy: JSON document describing allowed or denied actions.
• AdministratorAccess: broad administrative permissions; not least privilege.
• Human access: prefer IAM Identity Center and federation.
• Workload access: prefer IAM roles and temporary credentials.
• Console login: account alias or ID, username, password, and MFA as applicable.

Flashcards

1. Q: What is the AWS root user?

A: The original account identity created with the account email address; it has unrestricted access.

1. Q: Should the root user be used for daily administration?

A: No. Protect it with MFA and use it only for tasks that require root access.

1. Q: What permissions does a new IAM user have?

A: None by default.

1. Q: How can an IAM user receive group-based permissions?

A: By being added as a member of an IAM group with attached policies.

1. Q: What does Action: "*" mean in an IAM policy?

A: It matches all API actions.

1. Q: What does Resource: "*" mean?

A: It matches all resources applicable to the policy statement.

1. Q: What identity model is preferred for workforce access in modern AWS environments?

A: IAM Identity Center, commonly integrated with an external identity provider.

1. Q: What should an EC2 instance use to access AWS APIs?

A: An IAM role attached through an instance profile, not an IAM user’s access keys.

1. Q: Can IAM groups contain other IAM groups?

A: No, IAM groups cannot be nested.

1. Q: What overrides an IAM allow?

A: An applicable explicit deny.

Practice Questions

Question 1

A company has created an AWS account and wants to prevent unauthorized use of the most privileged account. Which two actions should the solutions architect recommend? (Choose two.)

A. Create access keys for the root user and store them in a password manager.
B. Enable MFA for the root user.
C. Use the root user for all administrative operations.
D. Create controlled administrative access for named users or federated identities.
E. Delete the root user.

Correct answer: B and D

Explanation: The root user cannot be deleted and should not be used for routine administration. MFA protects the root identity, while named or federated identities provide accountability and controlled permissions. Root access keys should generally not be created.

Question 2

An IAM user was created successfully, but the user receives AccessDenied when opening the Amazon S3 console. The user is not a member of any group and has no policies attached. What is the most likely cause?

A. IAM users automatically require root approval for S3 access.
B. The account alias is invalid.
C. The IAM user has no permissions.
D. S3 can be accessed only by the root user.

Correct answer: C

Explanation: IAM users have no permissions by default. The user needs an appropriate identity-based policy, group membership, or another valid permission path.

Question 3

A company wants employees to access multiple AWS accounts using their existing corporate identities. The company wants centralized access assignment and short-lived credentials. Which solution best meets these requirements?

A. Create an IAM user in every account for each employee.
B. Share one administrator IAM user across all accounts.
C. Configure IAM Identity Center with federation and account permission sets.
D. Store IAM access keys in the corporate directory.

Correct answer: C

Explanation: IAM Identity Center supports centralized workforce access, federation, account assignments, and temporary credentials. Individual IAM users in every account create unnecessary operational and credential-management overhead.

Question 4

An application running on Amazon EC2 needs to read objects from one S3 bucket. Which approach follows AWS security best practices?

A. Store an administrator access key in the application configuration.
B. Attach an IAM role to the EC2 instance with read permissions limited to the required bucket and prefix.
C. Add every EC2 instance to an IAM administrator group.
D. Use the root user access keys.

Correct answer: B

Explanation: An instance role provides temporary credentials to the application and allows permissions to be scoped to the required S3 resources. Long-lived keys and administrator permissions violate least privilege.

Question 5

An IAM group has an AWS managed AdministratorAccess policy attached. A member can sign in to the console but cannot perform an operation because an organization-wide policy denies that action. Why?

A. Group policies apply only to the console.
B. The IAM user must also be the root user.
C. An explicit deny can override an identity-based allow.
D. AWS managed policies cannot authorize API operations.

Correct answer: C

Explanation: Effective permissions are evaluated across multiple policy types. An applicable explicit deny, including one from an AWS Organizations service control policy, overrides an allow.