AWS IAM: Roles, Policies, and Users — What the SAA-C03 Exam Actually Tests

AWS Identity and Access Management (IAM) is a core service on the SAA-C03 exam. You need to understand not just what IAM does, but how its components interact in specific scenarios. This post breaks down IAM roles, managed vs. inline policies, permission boundaries, and the exact patterns the exam tests.

IAM Users and Groups

An IAM user is a permanent identity with long-term credentials (password or access keys). Users are placed in groups for easier management. Key exam point: groups cannot be nested — a group can contain only users, not other groups. Attach policies to groups to grant permissions to all members.

IAM Roles: Temporary Credentials

An IAM role is an identity that can be assumed by trusted entities. Unlike a user, a role has no permanent credentials; it issues temporary security credentials via AWS Security Token Service (STS). The exam tests three main use cases:

1. EC2 instances – assign a role to an EC2 instance to access other AWS services (e.g., S3, DynamoDB). Use aws sts assume-role or instance profile credentials.
2. Cross-account access – allow a user in Account A to assume a role in Account B.
3. Federation – allow external identities (e.g., SAML 2.0, OIDC) to assume a role.

Exam tip: When an EC2 instance needs to access S3, never store access keys on the instance. Always use an IAM role attached to the instance profile.

Managed Policies vs. Inline Policies

• Managed policies – standalone policies you can attach to multiple users, groups, or roles. AWS managed policies (e.g., AmazonS3ReadOnlyAccess) are maintained by AWS. Customer managed policies are created by you.
• Inline policies – policies embedded directly in a user, group, or role. They are tightly coupled and cannot be reused.

Exam scenario: If you need to enforce a specific policy for a single user that must not be accidentally attached elsewhere, use an inline policy. For reusable permissions, use managed policies.

Permission Boundaries

A permission boundary is an advanced feature that sets the maximum permissions an IAM entity can have. It uses a managed policy to define the boundary. The effective permissions are the intersection of the identity-based policy and the permission boundary.

Example: An IAM user has an identity-based policy granting s3:* but a permission boundary allowing only s3:GetObject. The user can only get objects, even though the identity policy is broader.

Exam tip: Permission boundaries are often tested with service-linked roles or when delegating admin tasks. If a user can create roles, a permission boundary on the user limits the permissions they can grant to those roles.

Policy Evaluation Logic

AWS evaluates policies in a specific order:

1. Explicit deny – if any policy denies an action, the request is denied.
2. Explicit allow – if any policy allows the action, and no explicit deny, the request is allowed.
3. Default deny – if no policy allows or denies, the request is denied.

Key exam point: An explicit deny overrides any allow. This is why a deny statement in an S3 bucket policy can block access even if an IAM policy allows it.

Resource-Based Policies and IAM Roles

Some services (S3, SQS, SNS, Lambda) support resource-based policies that grant access to principals. When a principal (user or role) accesses a resource, the effective permissions are the union of the identity-based policy and the resource-based policy.

Cross-account access pattern: To allow a user in Account A to access an S3 bucket in Account B:

• Attach a resource-based policy to the bucket allowing the Account A user.
• Attach an identity-based policy to the user allowing s3:GetObject on that bucket.

Exam scenario: This is often contrasted with using a role. With a role, the user assumes a role in Account B and then accesses the bucket. With a resource-based policy, the user stays in Account A and accesses the bucket directly.

STS and Temporary Credentials

When a role is assumed, AWS STS returns:

• AccessKeyId
• SecretAccessKey
• SessionToken
• Expiration

These credentials are valid for a configurable duration (15 minutes to 12 hours). The exam may ask about sts:AssumeRole, sts:AssumeRoleWithSAML, or sts:GetFederationToken.

Exam tip: Remember that temporary credentials cannot be revoked immediately; they remain valid until expiration. To revoke, you must change the role's trust policy or use aws sts:RevokeOldSessions.

IAM Best Practices for the Exam

• Least privilege – grant only required permissions.
• Use roles for EC2 – never use access keys on instances.
• Use groups – assign permissions to groups, not users.
• Enable MFA – especially for privileged users.
• Use conditions – restrict access based on IP, time, or MFA status.

What to Watch for on the Exam

• Difference between role and resource-based policy – know when to use each.
• Permission boundary vs. service control policy (SCP) – SCP applies at the account level, boundary at the entity level.
• Inline vs. managed policy – scenario where you must use inline.
• STS endpoints – sts.amazonaws.com for global, regional endpoints for latency.
• PassRole – a permission that allows a user to pass a role to an AWS service. Without iam:PassRole, you cannot launch an EC2 instance with a role even if you have ec2:RunInstances.

Conclusion

IAM is fundamental to AWS security and appears in nearly every SAA-C03 domain. Focus on understanding the interplay between identity-based policies, resource-based policies, and permission boundaries. Practice with scenarios involving cross-account access, EC2 roles, and policy evaluation.

To solidify your knowledge, work through practice questions that ask you to choose between a role and a resource-based policy, or to identify why an access is denied. Hands-on labs with IAM policies and roles will also help you retain the concepts.