AWS Account and IAM Fundamentals – SAP-C02 Study Guide

Purpose of This Lesson

An AWS account is the primary boundary for resources, billing, security controls, and service usage. This lesson introduces how an account is created, why the root user must be protected, and how AWS Identity and Access Management (IAM) controls access through identities and policies.

For the SAP-C02 exam, these fundamentals provide the basis for designing secure account structures, applying least privilege, and selecting the correct authentication method for people, applications, and cross-account access.

Key Concepts

AWS account creation

Creating an AWS account requires an email address and a payment method. The email address becomes associated with the account’s root user and must be unique to that account. Organizations may create multiple AWS accounts, but each account has its own account identifier, root user, billing context, and regional resources.

Email aliases may be useful for testing or account administration when supported by the mail provider, but production account ownership should use durable, organization-controlled addresses rather than personal mailboxes.

The AWS account root user

The root user is created automatically with the AWS account. It authenticates with the account’s email address and password and has unrestricted authority over the account. Root access is not an IAM permission set, so normal IAM policies cannot be used to reduce the root user’s privileges.

Recommended controls include:

• Use a long, unique root password stored in an approved secrets-management process.
• Enable multi-factor authentication (MFA), preferably a hardware MFA device for highly sensitive environments.
• Do not create or use root access keys.
• Restrict routine administration to federated identities, IAM roles, or appropriately governed IAM users.
• Monitor and alert on root-user activity.

The root user should be used only for account-level tasks that explicitly require it. Examples can include changing certain account settings, closing an account, and managing some account-level credentials or support-related operations. The exact list of root-only tasks can change, so AWS documentation should be consulted when implementing procedures.

IAM identities and access control

IAM provides the control plane for authentication and authorization within an AWS account. Important IAM objects include:

• IAM users: Long-term identities representing people or workloads. They are generally less desirable for human access than federation and roles.
• IAM groups: Collections of IAM users. Permissions can be attached to a group, simplifying administration for users with similar responsibilities.
• IAM roles: Identities with temporary credentials that can be assumed by users, applications, AWS services, or principals in another account.
• IAM policies: JSON documents that define allowed or denied actions on specified resources, optionally constrained by conditions.

A common legacy pattern is to create an individual IAM user, place it in a group, and attach policies to the group. For modern workforce access, AWS IAM Identity Center with federation is usually preferred because it centralizes access across multiple accounts and avoids distributing long-term credentials.

Authentication versus authorization

These are separate decisions:

1. Authentication verifies who or what is making the request. Examples include a console password and MFA, temporary role credentials, or access keys used by the CLI.
2. Authorization determines whether the authenticated principal can perform an action on a resource. IAM policies and related controls provide this decision.

AWS can be accessed through:

• The AWS Management Console
• The AWS Command Line Interface (AWS CLI)
• AWS SDKs and service APIs

Each interface ultimately makes authenticated API requests. A console login does not bypass authorization; the resulting principal still needs permission for each requested operation.

IAM policy evaluation essentials

A request is allowed only when an applicable policy grants the action and no applicable explicit deny overrides it. Important policy types and controls include:

• Identity-based policies attached to users, groups, or roles
• Resource-based policies attached to supported resources, such as Amazon S3 buckets or AWS KMS keys
• Permissions boundaries that limit the maximum permissions an identity can receive
• Service control policies (SCPs) in AWS Organizations, which define maximum available permissions for accounts or organizational units
• Session policies that further restrict a role session

An explicit deny takes precedence over an allow. An SCP does not grant permissions by itself; it limits what IAM and resource policies can grant.

Single-account and multi-account models

A single account is simple to begin with, but larger organizations commonly use multiple accounts to isolate workloads, environments, teams, compliance boundaries, and billing. AWS Organizations can centrally manage accounts, apply SCPs, consolidate billing, and support governance capabilities.

A principal created in one account does not automatically gain access to resources in another account. Cross-account access normally requires a trusted role in the target account and a policy allowing the source principal to assume it. Resource-based policies can also support cross-account access for services that provide that capability.

Exam-Relevant Takeaways

• The root user is distinct from IAM users and cannot be governed like a normal IAM principal with IAM policies.
• Protect the root user with a strong password and MFA, and avoid using it for routine operations.
• Never use root access keys for normal administration or application access.
• Prefer temporary credentials from IAM roles for EC2 instances, Lambda functions, containers, and cross-account access.
• Prefer federation or IAM Identity Center for workforce access, especially in multi-account environments.
• IAM groups organize users; they are not a substitute for roles or federation.
• Authentication proves identity; authorization evaluates permissions.
• Explicit denies override allows.
• An SCP limits permissions but does not grant permissions.
• Cross-account access requires an explicit trust and permission design; accounts are separate security boundaries.
• Policies should follow least privilege and restrict actions, resources, and conditions wherever practical.

Architecture Decision Guide

Requirement	Preferred approach	Why
Human access to one or many AWS accounts	IAM Identity Center with federation	Centralized workforce access, temporary credentials, and simpler offboarding
EC2, Lambda, or container access to AWS APIs	IAM role attached through the service’s supported mechanism	Avoids embedding long-term access keys
Access from the AWS CLI or SDK by an automated external system	Federated identity or short-lived role credentials, such as OIDC-based role assumption	Reduces credential leakage and rotation overhead
Grouping permissions for legacy IAM users	IAM group with managed or customer-managed policies	Centralizes permissions for similarly situated users
Account-wide governance across many accounts	AWS Organizations, organizational units, and SCPs	Centralized guardrails and account isolation
Emergency or account-level operation requiring root	Protected root-user procedure with MFA and auditing	Limits exposure of the unrestricted principal
Access to a resource in another account	Target-account role with a trust policy and source permissions	Makes the cross-account trust explicit

Common Exam Traps

• Treating the root user like an IAM user: IAM policies do not meaningfully constrain root access.
• Using an IAM user for an EC2 application: Attach an IAM role to the instance instead of storing access keys on disk.
• Assuming an SCP grants access: The principal still needs an identity-based or resource-based allow.
• Assuming an account boundary automatically permits cross-account access: A trust relationship and appropriate permissions are required.
• Confusing authentication with authorization: Valid credentials do not imply permission to call every AWS API.
• Using the root account for daily administration: This increases blast radius and weakens accountability.
• Believing a group can be assumed: IAM groups contain users; roles are assumed and provide temporary credentials.
• Relying only on a password: MFA is a critical control for the root user and privileged human access.
• Assuming every resource supports resource-based policies: Cross-account design depends on the specific service and resource policy capabilities.

Real-World Engineer Notes

• Establish a dedicated account-vending and governance process before creating many production accounts. Define ownership, logging, billing, networking, and security responsibilities.
• Store root credentials under controlled break-glass procedures and test that the organization can access them when necessary without using them routinely.
• Enable centralized CloudTrail and security monitoring, including alerts for root-user activity, unusual API calls, and IAM policy changes.
• Use separate accounts for security tooling, log archiving, networking, and workloads when the organization benefits from stronger isolation.
• Avoid broad policies such as AdministratorAccess for ordinary users. Use job-based roles and permission boundaries where delegated administration is required.
• Treat access keys as secrets. Prefer short-lived credentials and automate rotation or replacement when long-lived credentials cannot be avoided.
• Document which account owns shared services and how application teams obtain access. This prevents informal cross-account permissions from becoming an operational dependency.

Quick Reference Summary

• Every AWS account has a root user created during registration.
• Root has unrestricted authority and should be tightly protected, monitored, and rarely used.
• IAM users, groups, roles, and policies provide account access control.
• Roles and temporary credentials are preferred for workloads and cross-account access.
• Federation or IAM Identity Center is generally preferred for human access at scale.
• Console, CLI, and SDK requests all require authentication and authorization.
• Explicit denies override allows.
• SCPs constrain permissions across AWS Organizations; they do not grant permissions.
• Multi-account architectures improve isolation and governance but require deliberate cross-account access design.

Flashcards

1. Q: What is the AWS account root user?

A: The unrestricted identity created with an AWS account that authenticates using the account’s registration email address and password.

1. Q: Can an IAM policy restrict the root user?

A: No. Root is not governed like a normal IAM principal, so it must be protected operationally with MFA, credential controls, and monitoring.

1. Q: What is the recommended credential type for an EC2 workload?

A: Temporary credentials obtained through an IAM role attached to the instance.

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

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

1. Q: What does an IAM group contain?

A: IAM users. Groups help apply shared permissions but cannot themselves be assumed like roles.

1. Q: Why are IAM roles preferred for applications?

A: They provide temporary credentials and avoid embedding long-term access keys in application configuration.

1. Q: What happens when an explicit deny and an allow both apply?

A: The explicit deny wins.

1. Q: Does an SCP grant permissions to an account?

A: No. It sets a maximum permissions boundary for affected accounts or organizational units.

1. Q: What is normally required for cross-account role access?

A: The target role’s trust policy must trust the source principal, and the source principal must be allowed to assume the role.

1. Q: What should be enabled on the root user?

A: MFA, preferably using a hardware device for high-value or highly regulated environments.

Practice Questions

Question 1

A company has deployed an application on Amazon EC2. The application must read objects from an Amazon S3 bucket, and the security team prohibits storing access keys in the instance’s file system. What is the best solution?

A. Create an IAM user and store its access keys in AWS Systems Manager Parameter Store.
B. Create an IAM role with least-privilege S3 permissions and attach it to the EC2 instance through an instance profile.
C. Use the AWS account root user credentials from the application.
D. Add the EC2 instance’s private IP address to an S3 bucket policy.

Correct answer: B

An EC2 instance profile provides the application with temporary credentials from an IAM role. This avoids long-lived keys and supports least privilege.

Question 2

A security architect is designing governance for 50 AWS accounts. The organization must prevent all accounts from disabling required security services, while workload teams retain their normal IAM administration within their accounts. Which control is most appropriate?

A. Attach an administrator policy to the root user in every account.
B. Apply an SCP to the appropriate AWS Organizations organizational units.
C. Create an IAM group in the management account and add all workload users to it.
D. Use a security group rule to block access to the security services.

Correct answer: B

An SCP provides an organization-level guardrail that limits what account principals can do. It does not grant permissions, so the necessary IAM permissions must still exist in the account.

Question 3

An engineer in Account A must access a DynamoDB table in Account B. The organization wants short-lived credentials and does not want to create a user in Account B. What should the architect recommend?

A. Share the root credentials for Account B with the engineer.
B. Create an IAM role in Account B with a trust policy for the approved principal in Account A and attach the required DynamoDB permissions.
C. Create an IAM group in Account A and attach the DynamoDB policy to it.
D. Add the engineer’s console password to the DynamoDB table policy.

Correct answer: B

A role in the target account can be assumed by a trusted principal from the source account and can provide temporary credentials with narrowly scoped permissions.

Question 4

A company wants employees to access multiple AWS accounts using their corporate identities. Employees must receive permissions based on job function, and access must be revoked centrally when they leave the company. Which approach best fits these requirements?

A. Create a separate IAM user in every AWS account for each employee.
B. Use IAM Identity Center integrated with the corporate identity provider and assign permission sets to accounts and groups.
C. Give every employee the root-user email address and a unique password.
D. Create one shared IAM user per department.

Correct answer: B

IAM Identity Center supports centralized workforce federation and assignment of permission sets across accounts, reducing long-term credentials and simplifying lifecycle management.

Question 5

An IAM role has an identity-based policy allowing s3:GetObject. A bucket policy contains an explicit deny for the same role when requests originate outside an approved VPC endpoint. The role makes a request from the public internet. What is the result?

A. The request succeeds because the identity policy allows it.
B. The request succeeds because resource policies always override identity policies.
C. The request is denied because the explicit deny overrides the allow.
D. The request succeeds only if the role belongs to the root account.

Correct answer: C

An applicable explicit deny takes precedence over an allow, regardless of whether the allow appears in an identity-based policy.