AWS Systems Architect Professional

AWS IAM Users, Root Account Security, and Administrator Access

Purpose of This Lesson This lesson covers the difference between the AWS root user and an IAM user, why the root account should not be used for daily administration, and how permissions are assigned through IAM groups and IAM policies. For the SAP-C02 exam, this topic matters because AWS identity and access management is foundational […]

AWS Systems Architect ProfessionalAWS Systems Architect ProfessionalUpdated May 25, 2026
Study options
WatchComing later
ListenComing later
ReadAvailable
ReviewComing later

Study guide

Technical reference and lesson notes

Purpose of This Lesson

This lesson covers the difference between the AWS root user and an IAM user, why the root account should not be used for daily administration, and how permissions are assigned through IAM groups and IAM policies.

For the SAP-C02 exam, this topic matters because AWS identity and access management is foundational to secure architecture. Many exam scenarios test whether you understand how to avoid root account usage, apply least privilege, assign permissions through groups or roles, and choose the right identity model for human access.

Key Concepts

AWS Root User vs IAM User

When you create a new AWS account, the first identity created is the root user. This account is tied to the email address used during AWS account creation.

The root user has unrestricted access to the AWS account. It can perform account-level actions that even administrator IAM users may not be able to perform, such as closing the account or changing certain billing and account settings.

Because of this, the root user should not be used for daily administration.

The preferred approach is:

  • Create a strong password for the root user.
  • Enable MFA on the root user.
  • Store the credentials securely.
  • Avoid using the root user except for tasks that specifically require it.
  • Use IAM users, IAM roles, or AWS IAM Identity Center for normal access.

For real production environments, AWS IAM Identity Center is generally preferred for workforce access because it supports centralized user management, federation, and permission sets across multiple AWS accounts.

IAM Users

An IAM user is an identity created inside AWS IAM. Unlike the root user, an IAM user starts with no permissions by default.

This is an important exam point: creating an IAM user does not automatically give that user access to AWS services.

Permissions must be explicitly granted through:

  • IAM policies attached directly to the user
  • IAM policies attached to a group the user belongs to
  • IAM roles assumed by the user or application

In this lesson, the IAM user is created for console access and then granted administrative permissions through an IAM group.

AWS Management Console Access

IAM users can be given access to the AWS Management Console by enabling console access and assigning a password.

To sign in as an IAM user, the user typically needs:

  • The AWS account ID or account alias
  • The IAM username
  • The IAM user password

AWS provides an IAM sign-in URL that includes the account alias or account ID. This makes it easier for users to access the correct AWS account login page.

Account Alias

An AWS account alias is a friendly name that can be used instead of the numeric AWS account ID during IAM user sign-in.

For example, instead of entering a long 12-digit AWS account ID, a user can enter a readable alias such as:

company-prod-aws

This is mainly a usability feature, but it can also help reduce confusion when users work across multiple AWS accounts.

IAM Groups

An IAM group is a collection of IAM users. Groups are commonly used to simplify permissions management.

Instead of attaching the same policy to each user individually, you can attach a policy to a group and then add users to that group.

For example:

  • Create a group named Admins
  • Attach the AdministratorAccess policy to the group
  • Add the IAM user to the group

The user then inherits the permissions assigned to the group.

This is easier to manage than assigning permissions directly to each user.

IAM Policies

IAM permissions are defined using IAM policies. Policies are written in JSON and define what actions are allowed or denied against specific AWS resources.

A basic IAM policy includes:

  • Effect – Allow or Deny
  • Action – The AWS API actions permitted or denied
  • Resource – The AWS resources the policy applies to
  • Condition – Optional logic that controls when the policy applies

The lesson uses the AWS-managed policy called AdministratorAccess.

This policy effectively allows all actions on all resources.

That means it grants full administrative control over the AWS account.

AWS Managed Policies

An AWS managed policy is a policy created and maintained by AWS.

Examples include:

  • AdministratorAccess
  • ReadOnlyAccess
  • PowerUserAccess
  • Service-specific policies such as AmazonS3ReadOnlyAccess

AWS managed policies are convenient, especially for labs and learning environments, but they are often broader than what should be used in production.

For the SAP-C02 exam, remember that broad managed policies may be acceptable for administrative groups in controlled scenarios, but production architectures should usually favor least privilege.

AdministratorAccess Policy

The AdministratorAccess policy grants full permissions to AWS services and resources.

It uses wildcard permissions, meaning:

  • All actions are allowed
  • All resources are included

This is powerful and dangerous if misused.

For a personal lab account, assigning AdministratorAccess to your primary IAM user is common. In a business or production environment, this should be limited to trusted administrators and protected with MFA, logging, and governance controls.

Identity Center vs IAM Users

The console may recommend using AWS IAM Identity Center instead of creating standalone IAM users.

That is an important design distinction.

IAM users are identities stored directly inside a single AWS account. IAM Identity Center is designed for centralized workforce identity across multiple AWS accounts and applications.

In modern AWS environments, IAM Identity Center is usually the better choice for human access, especially when integrated with an external identity provider such as Microsoft Entra ID, Okta, or another SAML/OIDC provider.

For a simple training lab, creating an IAM user is acceptable. For enterprise architecture, federation and centralized identity are preferred.

Exam-Relevant Takeaways

The AWS root user should not be used for daily administration. Secure it, enable MFA, and only use it for account-level tasks that require root privileges.

IAM users have no permissions by default. This is a core IAM concept and a common exam trap.

Permissions can be assigned directly to IAM users, but assigning permissions through IAM groups is usually cleaner and easier to manage.

IAM policies are JSON documents that define allowed or denied actions against AWS resources.

The AdministratorAccess AWS managed policy grants full access to the account. It is useful for lab environments but should be tightly controlled in production.

For enterprise workforce access, AWS IAM Identity Center is generally preferred over standalone IAM users.

Use the account alias or account ID when signing in as an IAM user.

For the SAP-C02 exam, think in terms of security, governance, operational scalability, and least privilege. The technically possible answer is not always the best architecture answer.

Architecture Decision Guide

ScenarioBest AWS ChoiceWhy
New AWS account createdSecure root user and create separate admin identityRoot user is too powerful for daily use
Personal lab or training environmentIAM user with AdministratorAccessSimple setup for hands-on learning
Enterprise workforce access across multiple AWS accountsAWS IAM Identity CenterCentralized access, federation, permission sets, and better governance
Managing permissions for several IAM usersIAM groupsEasier than attaching policies to users individually
Need full administrative permissions for a trusted adminAdministratorAccess policyProvides full access, but should be tightly controlled
Need limited access to specific AWS servicesCustom IAM policy or scoped managed policySupports least privilege
Need application or AWS service accessIAM roleAvoids long-term static user credentials
Need readable IAM sign-in experienceAWS account aliasEasier than using the 12-digit account ID

Common Exam Traps

One common trap is assuming that an IAM user has permissions immediately after being created. It does not. IAM users start with no access until policies are assigned.

Another trap is treating the root user like a normal admin account. The root user should be secured and rarely used.

A third trap is attaching permissions directly to individual users when a group-based or role-based approach would be easier to manage.

The exam may also present AdministratorAccess as an easy solution, but in production scenarios, AWS often expects least privilege instead of broad wildcard permissions.

Another common misunderstanding is confusing IAM users with IAM roles. IAM users are long-term identities. IAM roles are assumable identities and are preferred for AWS services, applications, cross-account access, and temporary credentials.

For workforce access in a multi-account environment, IAM Identity Center is usually a better design than manually creating IAM users in every AWS account.

Real-World Engineer Notes

In a real environment, the first thing I would do after creating an AWS account is secure the root user. That means a strong password, MFA, and storing the credentials in an approved password vault. The root user should not be used for normal administration.

For a small lab, creating an IAM admin user is fine. For a company, I would avoid creating standalone IAM users unless there is a specific reason. Instead, I would look at AWS IAM Identity Center and integrate it with the organization’s identity provider.

From an operations standpoint, group-based permissions are easier to audit than user-by-user permissions. If every user has policies attached directly, access reviews become harder and mistakes become more likely.

From a security standpoint, AdministratorAccess should be treated like domain admin or enterprise admin access in a Microsoft environment. It is useful, but it should be limited, monitored, and protected with MFA.

CloudTrail should be enabled so administrative actions are logged. In a production AWS account, identity activity should be part of the security monitoring strategy.

For governance, this topic connects directly to AWS Organizations, Service Control Policies, IAM Identity Center, permission boundaries, and least privilege design. The exam often expects you to think beyond “can this user access AWS?” and instead ask, “Is this the most secure and scalable access model?”

Quick Reference Summary

The AWS root user is created with the AWS account and has unrestricted access.

Do not use the root user for daily administration.

Create an IAM user, IAM role, or federated identity for normal access.

IAM users have no permissions by default.

Permissions are granted using IAM policies.

IAM groups are used to assign permissions to multiple IAM users more easily.

The AdministratorAccess policy allows all actions on all resources.

For enterprise environments, IAM Identity Center is usually preferred for human access.

For the SAP-C02 exam, prioritize least privilege, centralized identity, secure root user handling, and scalable permissions management.

Flashcards

Q: What is the AWS root user?
A: The root user is the original identity created with the AWS account email address and has unrestricted access to the account.

Q: Should the AWS root user be used for daily administration?
A: No. The root user should be secured with a strong password and MFA, then used only for tasks that require root access.

Q: What permissions does a new IAM user have by default?
A: None. IAM users start with no permissions until policies are assigned.

Q: What is the purpose of an IAM group?
A: An IAM group allows permissions to be assigned to multiple IAM users at once.

Q: What format are IAM policies written in?
A: IAM policies are written in JSON.

Q: What does the AWS-managed AdministratorAccess policy allow?
A: It allows all actions on all resources in the AWS account.

Q: What does a wildcard * mean in an IAM policy?
A: It represents all actions or all resources, depending on where it is used.

Q: What information is typically needed to sign in as an IAM user?
A: The account ID or account alias, the IAM username, and the password.

Q: What is an AWS account alias used for?
A: It provides a friendly name that can be used instead of the 12-digit AWS account ID during IAM user sign-in.

Q: When is IAM Identity Center preferred over IAM users?
A: IAM Identity Center is preferred for centralized workforce access, especially across multiple AWS accounts.

Q: Why should permissions usually be assigned through groups instead of directly to users?
A: Groups simplify management, auditing, and consistency across users.

Q: Is AdministratorAccess appropriate for production users by default?
A: Not usually. Production access should follow least privilege unless full admin access is specifically required.

Practice Questions

Question 1:
A company has just created a new AWS account. The solutions architect needs to recommend a secure access approach for daily administration. What is the best recommendation?

A. Use the root user for all administrative tasks
B. Create an IAM user or federated administrator identity and secure the root user
C. Share the root user password with the cloud operations team
D. Disable the root user after creating an IAM user

Correct Answer:
B. Create an IAM user or federated administrator identity and secure the root user

Explanation:
The root user should not be used for daily administration. It should be protected with a strong password and MFA. Normal administration should be performed using IAM or federated identities.


Question 2:
An IAM user was created for a new administrator, but the user cannot access any AWS services after logging in. What is the most likely reason?

A. IAM users cannot access the AWS Management Console
B. IAM users require root credentials to use AWS services
C. The IAM user has no permissions assigned
D. The AWS account alias has not been configured

Correct Answer:
C. The IAM user has no permissions assigned

Explanation:
IAM users have no permissions by default. Permissions must be granted through IAM policies attached directly, through groups, or through assumable roles.


Question 3:
A team wants to assign the same permissions to multiple IAM users. Which approach is most operationally efficient?

A. Attach the same policy directly to each user
B. Add the users to an IAM group and attach the policy to the group
C. Use the root user for shared administrative access
D. Create a separate AWS account for each user

Correct Answer:
B. Add the users to an IAM group and attach the policy to the group

Explanation:
IAM groups simplify permission management for multiple IAM users. Instead of managing each user individually, permissions can be managed at the group level.


Question 4:
Which statement best describes the AdministratorAccess AWS managed policy?

A. It grants read-only access to all AWS services
B. It grants full access to all actions and resources
C. It grants access only to IAM resources
D. It grants billing access but not service access

Correct Answer:
B. It grants full access to all actions and resources

Explanation:
The AdministratorAccess policy allows all actions on all resources. It is powerful and should be carefully controlled.


Question 5:
A company is designing access for employees across multiple AWS accounts and wants centralized identity management. Which AWS service is generally the best fit?

A. AWS IAM Identity Center
B. AWS CloudTrail
C. Amazon Cognito
D. AWS Config

Correct Answer:
A. AWS IAM Identity Center

Explanation:
AWS IAM Identity Center is designed for centralized workforce access across AWS accounts and applications. It is usually preferred over creating standalone IAM users in each account.