AWS IAM Exam Cram: Users, Roles, Policies, and Security Best Practices – SAP-C02 Study Guide

Purpose of This Lesson

This exam-cram guide condenses the IAM facts and decision points most useful for AWS certification revision. It is intended as a refresher after studying the detailed IAM material, with emphasis on identity types, authorization models, temporary credentials, and security best practices.

Key Concepts

IAM is global and eventually consistent

AWS Identity and Access Management (IAM) is a global service rather than a Regional service. IAM users, groups, roles, and policies are not created separately in each AWS Region.

IAM changes are eventually consistent. After creating or modifying an identity or policy, an immediately subsequent request might not observe the change. Applications and automation should account for short propagation delays rather than assuming that every update is instantly visible.

IAM users and the root user

An IAM user represents a person, application, or service account that requires long-term access within an AWS account. A newly created IAM user has no permissions by default, even if the user can sign in to the AWS Management Console.

IAM users can authenticate with:

• A console password for human access.
• Access keys for programmatic access.
• Server certificates for services that support certificate-based authentication.

The AWS account root user is identified by the email address used to create the account and its associated password. The root user has unrestricted administrative authority; its permissions cannot be limited with IAM policies. Protect it with strong controls, enable MFA, and avoid using it for routine operations.

An account can contain up to 5,000 IAM users. For workloads running on AWS, prefer IAM roles rather than embedding IAM user access keys in applications.

IAM groups

Groups are collections of IAM users used to apply permissions consistently. A group is not an identity or principal, so it cannot be referenced as the principal in a resource-based policy. Users receive permissions from policies attached to their groups.

IAM groups cannot be nested. Use separate groups for functional access patterns, such as read-only auditors, application developers, and production operators.

IAM roles and temporary credentials

An IAM role is an identity with permissions and a trust policy that determines who or what may assume it. Roles are commonly used for:

• Applications running on Amazon EC2 through instance profiles.
• AWS services that need to act on behalf of a workload.
• Cross-account access.
• Federated human access.
• Temporary administrative or operational sessions.

When a trusted principal assumes a role, AWS Security Token Service (AWS STS) issues temporary security credentials. These credentials include an access key ID, secret access key, and session token, and they expire after a limited period.

A role has two important policy concerns:

1. Trust policy: Who or what can assume the role.
2. Permissions policy: What the role can do after it is assumed.

Confusing these two policies is a frequent exam mistake. A principal can have permission to call sts:AssumeRole, but the role’s trust policy must also trust that principal.

IAM policies and default behavior

IAM policies are JSON documents that describe permissions. Common elements include:

• Effect: Allow or Deny.
• Action: The API operations affected.
• Resource: The resources affected.
• Principal: The identity allowed or denied in a resource-based policy.
• Condition: Additional requirements for the request.

By default, access is implicitly denied. An explicit Deny overrides an Allow. If multiple policy layers apply, the effective permission is constrained by all applicable controls, and any applicable explicit deny takes precedence.

Policy types

#### Identity-based policies

Identity-based policies attach to IAM users, groups, or roles. They specify what actions the identity can perform against which resources.

#### Resource-based policies

Resource-based policies attach to resources such as Amazon S3 buckets, Amazon SQS queues, Amazon SNS topics, and AWS KMS keys. They specify which principals can access the resource and under what conditions.

Resource-based policies are especially important for cross-account access. The resource owner can grant access to a principal in another account, but the requesting principal may still require an identity-based permission depending on the service and access pattern.

#### Permissions boundaries

A permissions boundary defines the maximum permissions an IAM user or role can receive from identity-based policies. It does not grant permissions by itself.

The effective permissions are limited to the intersection of the identity-based policy and the permissions boundary, subject to other policy controls and explicit denies. This is useful for delegated administration, where teams can create roles but cannot grant permissions beyond an approved maximum.

#### Service control policies

AWS Organizations service control policies (SCPs) define the maximum available permissions for accounts or organizational units. An SCP does not grant permissions. The account must still have a matching identity-based or resource-based Allow.

For an action to succeed, the request must be allowed by the applicable authorization layers. An SCP can restrict an account even when an IAM administrator attaches AdministratorAccess within that account.

#### Session policies

Session policies can further restrict permissions for a role session or federated session. Like permissions boundaries and SCPs, a session policy limits permissions; it does not independently grant access.

Conditions and context-aware access

The Condition element can add security requirements to a policy. Examples include restricting access based on:

• Source IP address or VPC endpoint.
• Requested AWS Region.
• Encryption requirements.
• Resource tags.
• MFA authentication context.
• Specific principal or account attributes.

Conditions are useful for enforcing controls such as requiring MFA for sensitive actions or allowing S3 access only through a designated VPC endpoint.

Exam-Relevant Takeaways

• IAM is a global service and is eventually consistent.
• New IAM users have no permissions by default.
• The root user’s permissions cannot be restricted by IAM policies.
• Groups organize users and receive policies, but groups are not policy principals and cannot be nested.
• Use IAM roles and temporary STS credentials for applications and delegated access.
• A role’s trust policy controls who can assume it; its permissions policy controls what the assumed role can do.
• Explicit denies override allows.
• Identity policies grant permissions to identities; resource policies grant permissions on resources.
• Permissions boundaries limit the maximum permissions an identity can receive but do not grant access.
• SCPs limit maximum permissions across AWS accounts or OUs but do not grant permissions.
• Session policies further restrict an assumed-role or federated session.
• Follow least privilege, use MFA, avoid shared access keys, rotate credentials, and remove unused credentials.
• Prefer customer-managed policies over inline policies when reusable, centrally managed permissions are required.

Architecture Decision Guide

Requirement	Preferred IAM approach	Important consideration
Human access to the AWS console	Federated identity or IAM user where appropriate	Require MFA and individual identities; avoid shared accounts
EC2 application access to AWS APIs	IAM role attached through an instance profile	Do not store long-term access keys on the instance
Cross-account access	IAM role assumed through AWS STS	Configure both the caller’s permission and the target role’s trust policy
Consistent permissions for several users	IAM group with managed policy	Groups cannot be nested or used as resource-policy principals
Limit what delegated administrators can grant	Permissions boundary	A boundary limits permissions but does not grant them
Restrict an entire account or OU	Organizations SCP	The SCP is a maximum-permission guardrail, not an access grant
Limit one role or federation session	Session policy	Further restricts the session’s effective permissions
Grant access directly to an AWS resource	Resource-based policy	Confirm the service’s cross-account and principal behavior
Add network, MFA, encryption, or tag restrictions	Policy Condition	Ensure the condition matches the actual request context

Common Exam Traps

• Assuming an IAM user can do nothing because it cannot access the console: Console authentication and authorization are separate. A user may sign in but still have no service permissions.
• Treating the root user like a normal IAM administrator: Root access cannot be restricted through IAM policies and should be reserved for tasks that require it.
• Using an IAM group as a principal: Groups can receive permissions, but they cannot be directly named in a resource-based policy’s Principal element.
• Confusing role trust and role permissions: The trust policy answers “who may assume this role?” The permissions policy answers “what may the role do?”
• Thinking an SCP grants access: An SCP only sets the maximum permissions available to an account or OU.
• Thinking a permissions boundary grants access: The identity still needs an applicable Allow from another policy.
• Ignoring explicit denies: An explicit deny from an applicable policy layer overrides an allow.
• Embedding access keys in EC2 code: Use an instance role so the SDK obtains and refreshes temporary credentials.
• Expecting IAM updates to be immediately visible everywhere: IAM is eventually consistent; account for propagation delays.
• Using inline policies by default: Inline policies can be appropriate for tightly coupled, one-off permissions, but customer-managed policies are generally easier to reuse, audit, and manage at scale.

Real-World Engineer Notes

• Create separate identities for people and workloads. Shared users make attribution, rotation, and incident response difficult.
• Use federation for workforce access where possible, with centralized identity lifecycle management and MFA.
• Apply least privilege incrementally. Begin with a narrow managed policy, observe CloudTrail activity, and refine permissions rather than granting broad administrator access indefinitely.
• Use conditions to reduce blast radius, such as requiring a specific encryption context, source VPC endpoint, or MFA for destructive actions.
• Treat access-key rotation as a control, not a substitute for role-based access. Long-lived credentials should be minimized and removed when no longer required.
• Monitor IAM and authorization activity with services such as AWS CloudTrail and review unused permissions and credentials regularly.
• When debugging AccessDenied, inspect every applicable layer: identity policy, resource policy, SCP, permissions boundary, session policy, trust policy, key policy where relevant, and explicit denies.

Quick Reference Summary

• IAM scope: Global; eventually consistent.
• Default authorization: Implicit deny.
• Highest-priority restriction: Any applicable explicit deny.
• User: Long-term identity for a person or service account.
• Group: Collection of users for permission assignment; not a principal.
• Role: Assumable identity that provides temporary credentials.
• STS: Issues temporary credentials for assumed-role and federated sessions.
• Trust policy: Controls who can assume a role.
• Identity policy: Grants permissions to a user, group, or role.
• Resource policy: Grants permissions on a resource to specified principals.
• Permissions boundary: Maximum permissions for a user or role.
• SCP: Maximum permissions for an AWS account or OU.
• Session policy: Additional restriction on a temporary session.
• Core practices: MFA, least privilege, individual identities, no shared keys, credential rotation, and activity monitoring.

Flashcards

1. Q: Is IAM Regional or global?

A: IAM is a global AWS service, although some IAM-related resource interactions occur through Regional services.

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

A: None. The user may authenticate if configured, but access must be explicitly granted.

1. Q: Can an IAM group be specified as a resource-policy principal?

A: No. Groups organize users and receive policies but are not principals.

1. Q: What does an IAM role provide to an application?

A: Temporary AWS credentials issued through AWS STS, avoiding embedded long-term access keys.

1. Q: What is the difference between a role trust policy and a permissions policy?

A: The trust policy defines who can assume the role; the permissions policy defines what the role can do.

1. Q: Do permissions boundaries grant permissions?

A: No. They limit the maximum permissions an identity-based policy can grant.

1. Q: Do SCPs grant permissions?

A: No. They restrict the maximum permissions available to accounts or OUs.

1. Q: Which wins when an allow and explicit deny both apply?

A: The explicit deny.

1. Q: Why should applications on EC2 use roles?

A: Roles provide automatically delivered, temporary credentials and avoid storing long-term access keys on the instance.

1. Q: Can IAM groups be nested?

A: No. IAM does not support group nesting.

Practice Questions

Question 1

A company runs an application on Amazon EC2. Developers currently store an IAM user’s access key and secret access key in the application’s configuration file. The security team wants to eliminate long-term credentials without changing the application’s AWS API calls. What should an architect recommend?

Correct answer: Create an IAM role with the required permissions and attach it to the EC2 instance through an instance profile.

Explanation: The AWS SDK can obtain temporary credentials from the instance role and refresh them automatically. Storing an IAM user’s long-term access keys increases the risk of credential exposure and complicates rotation.

Question 2

A security administrator creates an IAM role with an identity-based policy allowing access to an Amazon S3 bucket. An application in another AWS account receives AccessDenied when attempting to assume the role. The application identity has permission to call sts:AssumeRole. What is the most likely missing configuration?

Correct answer: The role’s trust policy does not allow the application’s principal or source account to assume the role.

Explanation: Permission to call sts:AssumeRole is only one side of role assumption. The target role must also trust the calling principal in its trust policy.

Question 3

An IAM role has an identity-based policy allowing an action. The role’s permissions boundary does not allow that action, and no explicit deny exists. What is the result?

Correct answer: The action is denied.

Explanation: Effective permissions are constrained by the permissions boundary. A boundary does not grant access and prevents the identity policy from granting permissions outside the boundary.

Question 4

An organization attaches an SCP to an OU that denies access to a particular AWS Region. An administrator in an account within that OU has AdministratorAccess. The administrator tries to create a resource in the denied Region. What happens?

Correct answer: The request is denied by the SCP.

Explanation: An SCP defines the maximum permissions available to member accounts. Even an account administrator cannot perform an action prohibited by an applicable SCP.

Question 5

A company wants to grant several IAM users access to a shared set of resources. It also needs to grant a separate external AWS account access directly to an S3 bucket. Which combination is appropriate?

Correct answer: Attach an identity-based policy to an IAM group for the internal users and use an S3 bucket policy for the external account’s principal.

Explanation: Groups are useful for assigning common permissions to users, but groups cannot be resource-policy principals. An S3 bucket policy can identify the external account or its role as a principal, subject to the relevant cross-account authorization requirements.