In AWS, every action against every resource is an API call, and every API call must be authorized. IAM is the system that decides whether that call is allowed. Get IAM wrong and you either lock users out of the resources they need or leave sensitive data accessible to anyone with an internet connection. The SAA-C03 exam treats IAM as foundational: it appears in architecture questions, security questions, and cost optimization questions. You need to understand users, groups, roles, and policies, the difference between identity-based and resource-based policies, and the mechanics of how AWS evaluates whether to allow or deny a request.
Practice this topic
IAM users are long-term identities that represent individual people or applications. Each user has permanent credentials: a password for console access and access keys for programmatic access. Because these credentials are long-term, they should be secured carefully with MFA and rotated regularly. The root account user has unlimited access to everything in the AWS account and should only be used for tasks that specifically require it, such as changing billing settings or enabling AWS services.
IAM groups are collections of users that share the same permissions. Assign a policy to a group and every member inherits those permissions. Groups do not have credentials and cannot assume roles themselves. They are purely a management tool for applying policies to multiple users simultaneously.
IAM roles are temporary identities assumed by AWS services, applications, or users from other accounts. When an EC2 instance needs to read from S3, you attach a role to the instance rather than embedding access keys in the code. When the instance assumes the role, it receives temporary credentials that expire automatically. Roles are the correct way to grant permissions to AWS services, cross-account access, and federated identities from external providers.
IAM policies are JSON documents that define what actions are allowed or denied on which resources under which conditions. Identity-based policies are attached to IAM users, groups, or roles and define what that identity can do. Resource-based policies are attached to the resource itself (like an S3 bucket policy or a KMS key policy) and define who can access that resource.
The key difference matters for cross-account access. If Account A's user wants to access Account B's S3 bucket, Account B needs a bucket policy that allows Account A's user, and Account A's user needs an identity-based policy that allows the S3 action. Both sides must permit the access.
The IAM policy evaluation order is: explicit deny wins over everything. If any policy, anywhere, explicitly denies an action, that action is denied regardless of how many policies allow it. After checking for explicit denies, AWS looks for an explicit allow. If no explicit allow exists, the default is deny. This means the absence of an allow is a deny.
Least privilege is the operating principle: grant only the minimum permissions required to perform the task. Start with no permissions and add as needed rather than starting with broad access and trying to restrict later. Managed policies (AWS-maintained) provide a starting point. Inline policies are specific to one identity and are appropriate for unique requirements.
Never embed access keys in application code. Use IAM roles for EC2, Lambda, and other AWS services. For applications running outside AWS, use AWS IAM Identity Center (formerly SSO) or OIDC federation to provide temporary credentials rather than long-term keys.
Policy evaluation: explicit deny beats explicit allow. If no explicit deny and an explicit allow exists, allow. If no explicit allow, implicit deny.
IAM role vs IAM user: role = temporary credentials, assumed by services or external identities. User = long-term credentials, for specific humans. EC2, Lambda, ECS all use roles, not embedded user credentials.
Permission boundaries: an advanced feature that sets the maximum permissions an identity can have, even if their policies allow more. Used to safely delegate permission management to developers without letting them grant themselves more access than the boundary allows.
| Identity type | Credentials | Used for | Best practice |
|---|---|---|---|
| Root user | Email + password (permanent) | Account-level tasks only | Enable MFA, do not use daily |
| IAM user | Password + access keys (permanent) | Individual humans | Enable MFA, rotate keys, use least privilege |
| IAM group | None (management only) | Apply policies to multiple users | Assign policies to groups, not users directly |
| IAM role | Temporary credentials (assumed) | AWS services, cross-account, federated users | Preferred over access keys for services |
Adding a user to a group gives that user the group's credentials.
Groups have no credentials. Adding a user to a group attaches the group's policies to the user, expanding the user's permissions. The user still authenticates with their own credentials.
An explicit allow somewhere means the action is permitted.
An explicit deny anywhere overrides any number of explicit allows. This applies across identity policies, resource policies, and service control policies. Always check for deny rules before assuming an allow is sufficient.
IAM users are the correct way to give EC2 instances access to other AWS services.
You should never embed IAM user access keys on an EC2 instance. If the instance is compromised, those long-term credentials are exposed. Attach an IAM role to the EC2 instance instead. The instance receives temporary credentials automatically.
These questions are representative of what you will see on AWS SAA-C03 exams. The correct answer and explanation are shown immediately below each question.
An EC2 instance needs to read objects from an S3 bucket in the same AWS account. What is the MOST secure way to grant this access?
Explanation: IAM roles attached to EC2 instances provide temporary credentials automatically rotated by AWS. The instance receives credentials through the instance metadata service without any embedded keys. Storing access keys on EC2 (environment variables, credential files) creates long-term credentials that can be exposed if the instance is compromised. Public S3 buckets expose data to everyone.
A developer adds an IAM policy that allows s3:GetObject on all S3 buckets to a user. A separate SCP (Service Control Policy) at the organization level explicitly denies s3:GetObject for all principals. What is the effective permission?
Explanation: AWS policy evaluation: an explicit deny at ANY level wins over all allows. SCPs, resource policies, permission boundaries, and identity policies all apply. If any policy explicitly denies an action, the action is denied regardless of how many policies allow it. The IAM policy allow cannot override an SCP deny.
Which IAM identity type provides temporary credentials that expire automatically and is the recommended way to grant AWS services access to other AWS services?
Explanation: IAM roles provide temporary credentials through STS (Security Token Service). When an EC2 instance, Lambda function, or ECS task assumes a role, it receives temporary credentials valid for a limited time (default 1 hour, configurable). These expire automatically without manual rotation. IAM users have permanent credentials. Groups have no credentials. Root account should never be used for service access.
An organization's security team wants to allow a developer team to manage IAM permissions for their own applications but prevent them from granting themselves administrator access. Which IAM feature accomplishes this?
Explanation: Permission boundaries set an upper limit on what permissions an identity can have, regardless of what identity-based policies are attached. A developer with permission to manage IAM policies is still limited by their permission boundary — they cannot grant themselves (or others) permissions that exceed that boundary. This allows safe delegation of IAM management.
Account A wants to allow a user in Account B to access Account A's S3 bucket. What must be configured?
Explanation: Cross-account S3 access requires both sides to permit the action. Account A's S3 bucket policy must explicitly allow Account B's principal (user or role). Account B's IAM user must have an identity-based policy that allows the S3 actions on Account A's bucket. Without both policies, access is denied. VPC peering is for network connectivity, not IAM permissions.
IAM users are permanent identities for individual people with long-term credentials (password, access keys). IAM groups are collections of users that share permissions — groups have no credentials themselves. IAM roles are temporary identities assumed by AWS services, cross-account users, or federated identities. Roles provide temporary credentials that expire automatically. Best practice: use roles for services, users for humans with MFA, groups for permission management.
AWS evaluates policies in this order: (1) Check for explicit deny in any applicable policy — if found, DENY. (2) Check for explicit allow in any applicable policy — if found, ALLOW. (3) Default: IMPLICIT DENY. An explicit deny anywhere (identity policy, resource policy, SCP, permission boundary) overrides any number of explicit allows. The absence of an allow is also a deny.
Identity-based policies are attached to IAM users, groups, or roles and define what that identity can do. Resource-based policies are attached to the resource itself (S3 bucket policy, KMS key policy, Lambda resource policy) and define who can access that specific resource. For cross-account access, you typically need both: a resource policy on the target resource allowing the cross-account principal, and an identity policy in the source account allowing the action.
Access keys are long-term credentials that don't expire automatically. If an EC2 instance is compromised, hardcoded or stored access keys give attackers persistent access to your AWS account until the keys are manually rotated. IAM roles provide temporary credentials through the EC2 instance metadata service — they rotate automatically and expire. Even if stolen, they are only valid for a short window. This is the fundamental principle of using temporary credentials over long-term ones.
SAA-C03 tests IAM roles for services (EC2, Lambda), policy evaluation logic (explicit deny wins), cross-account access mechanics (both trust policy and identity policy required), the difference between managed and inline policies, permission boundaries, IAM conditions (aws:RequestedRegion, aws:SourceIP), and when to use IAM Identity Center vs IAM users for human access. The exam heavily favors roles over access keys in all service scenarios.
Try free AWS IAM practice questions with explanations, topic links and progress tracking.