IAM roles and policies: SAA-C03 study notes and practice questions
What to know about IAM roles and policies for the SAA-C03 exam, from the Design Secure Architectures domain (30% of the exam guide), then 3 free questions to test it. Part of the SAA-C03 study guide.
Almost every SAA-C03 security question has an IAM angle, and the exam has a clear favorite: an IAM role with temporary credentials beats long-term access keys in every scenario. If an option stores access keys on an instance, in code or in an environment variable, it is almost certainly wrong.
Key facts
Roles have two policies. The trust policy says who may assume the role (a service such as ec2.amazonaws.com, another account, or a federated identity). The permissions policy says what the role can do once assumed.
EC2 gets a role through an instance profile. The application picks up rotating credentials from the instance metadata service. Lambda, ECS tasks and other services have their own execution or task roles.
Cross-account access is a role in the account that owns the resource, trusted by the calling account, which uses sts:AssumeRole. For some services (S3, SQS, KMS) a resource-based policy can grant another account access directly instead.
Evaluation logic: an explicit deny anywhere wins. Otherwise the request needs an allow, and it must also fit within any SCP, permissions boundary or session policy that applies. Those three can only limit permissions, never grant them.
Permissions boundaries cap what a user or role can ever be granted, which is how you let developers create roles without letting them escalate their own access.
Root user: turn on MFA, don’t create access keys for it, and use it only for the handful of tasks that need it.
How to choose
The scenario says
Look for
An application on EC2, Lambda or ECS needs to call AWS
A role for that compute, with a policy scoped to the actions and resources it uses
Users in account A need access to resources in account B
A role in account B that trusts account A
Workforce users sign in with a corporate identity provider
IAM Identity Center (or SAML federation) to roles, not IAM users
Developers must create roles but not exceed their own rights
Permissions boundaries
Access only from a VPC, an IP range or with MFA
Condition keys such as aws:SourceVpce, aws:SourceIp or aws:MultiFactorAuthPresent
Common traps
Creating IAM users for applications. Users with access keys are long-term credentials. The exam treats them as the wrong answer whenever a role is possible.
Granting * to make it work. “Least privilege” questions want the specific actions on the specific resource ARN.
Thinking an SCP grants access. SCPs only set the maximum for member accounts; you still need an IAM policy that allows the action.
Forgetting the trust side. Cross-account access fails if the trust policy doesn’t name the caller, even with a perfect permissions policy.
A logistics company runs a nightly invoicing application on Amazon EC2 instances in an Auto Scaling group. The application reads delivery records from one Amazon S3 bucket and writes finished invoices to a second bucket.
Other applications run in the same VPC and must not be able to use either bucket. The security team bans long-term access keys on instances and in code, and wants permissions kept to the minimum the application needs.
Which solution meets these requirements MOST securely?
Choose one answer.
AA. Create an IAM user with a policy for both buckets, store its access key in AWS Secrets Manager, and have the application fetch the key at startup.
BB. Attach an instance profile to the launch template with an IAM role that allows s3:GetObject on the source bucket and s3:PutObject on the invoice bucket.
CC. Attach an instance profile to the launch template with an IAM role that has the AWS managed AmazonS3FullAccess policy, so the application can reach both buckets.
DD. Create an S3 gateway endpoint, and add bucket policies that allow any principal whose requests arrive through that endpoint, so the instances need no credentials.
Show the answer and explanation
Answer: B
A. Wrong: Secrets Manager protects the key at rest, but an IAM user access key is still a long-term credential that the application holds in memory and that someone must rotate. The security team has banned long-term access keys. An IAM role delivered through an instance profile gives temporary credentials instead. Learn more: Security best practices in IAM (opens in a new tab)
C. Wrong: The role removes long-term keys, so half of the requirement is met. However, AmazonS3FullAccess grants every S3 action on every bucket in the account, far more than the application needs. AWS recommends replacing broad managed policies with a customer managed policy scoped to the task. Learn more: Security best practices in IAM (opens in a new tab)
D. Wrong: The aws:SourceVpce condition checks only the network path, not who is calling. Any workload in the VPC that routes through the endpoint would get the same access, which breaks the rule that other applications must not use the buckets. Identity-based access with an IAM role is needed. Learn more: Controlling access from VPC endpoints with bucket policies (opens in a new tab)
Explanation
An IAM role attached through an instance profile is the standard way to give an EC2 application AWS permissions without long-term keys: the credentials are temporary and rotate automatically. Scoping the role's policy to s3:GetObject on the source bucket and s3:PutObject on the invoice bucket keeps permissions to the minimum and keeps other workloads in the VPC out, which a network-only condition cannot do.
A retail company runs an order service on Amazon ECS in its Production account.
The service must read customer records from an Amazon DynamoDB table that the data team owns in a separate Analytics account. The records change throughout the day, and the service must always see current data. The security team forbids long-term access keys for workloads, and the Analytics team wants to decide exactly which actions the service can perform on the table.
What should a solutions architect do?
Choose one answer.
AA. Create an IAM user in the Analytics account with read access to the table, and store its access keys in AWS Secrets Manager in the Production account with rotation.
BB. Create a role in the Analytics account that allows reads on the table and trusts the ECS task role, then let the service call sts:AssumeRole on it.
CC. Add a statement to the ECS task role in the Production account that allows DynamoDB read actions on the table's ARN in the Analytics account.
DD. Turn on point-in-time recovery and export the table every hour to an Amazon S3 bucket in the Production account, then have the service read the exports.
Show the answer and explanation
Answer: B
A. Wrong: An IAM user's access keys are long-term credentials, even when Secrets Manager stores and rotates them. The security team forbids long-term keys for workloads, so this fails the main constraint. A role that the service assumes gives temporary credentials instead.
B. Right: Correct. The role lives in the account that owns the table, so the Analytics team writes its permissions policy and decides which DynamoDB actions are allowed. Its trust policy names the Production task role, and the service gets short-lived credentials from AWS STS each time it assumes the role. Reads go to the live table, so the data is always current. Learn more: IAM tutorial: Delegate access across AWS accounts using IAM roles (opens in a new tab)
C. Wrong: For a cross-account request, the account that owns the resource must also allow it, through a resource-based policy or a role it trusts. A policy in the Production account alone is not enough, so the reads are denied. It would also leave the Analytics team with no say over the permissions. Learn more: Cross-account policy evaluation logic (opens in a new tab)
D. Wrong: DynamoDB can export a table to a bucket in another account without using read capacity, but each export is a snapshot. Between exports the service would see data up to an hour old, which breaks the need for current records. Reading the live table through an assumed role avoids the copy. Learn more: DynamoDB data export to Amazon S3: how it works (opens in a new tab)
Explanation
The standard pattern for cross-account access without long-term keys is an IAM role in the account that owns the resource. The owning account controls the role's permissions, the trust policy names the calling role, and the caller gets temporary credentials from AWS STS. An identity policy in the caller's account alone cannot grant access to another account's table, and an export would not give current data.
The Analytics account owns the role and its permissions, and the ECS task role uses temporary credentials, never stored keys.
A consultancy has just opened a standalone AWS account, not part of AWS Organizations, for a new client project.
The root user's email address and password were set during sign-up. Three engineers will administer the account day to day, and a CI/CD pipeline will deploy to it.
The client's security policy requires the account to follow AWS guidance for protecting the root user.
Which TWO actions should the consultancy take? (Choose two.)
Choose two answers.
AA. Register an MFA device for the root user, and keep the root credentials where only a small, named group of people can use them.
BB. Attach an IAM policy to the root user that denies everything except billing actions, so that its power is limited if it is misused.
CC. Make sure the root user has no access keys, and give the pipeline its own IAM role with only the permissions it needs to deploy.
DD. Create access keys for the root user, store them in AWS Secrets Manager with rotation, and let the pipeline read them when it deploys.
EE. Share the root password with the three engineers through a password manager so that each of them can sign in for daily administration.
B. Wrong: You cannot attach identity-based policies or a permissions boundary to the root user. In an account that belongs to an organization, an SCP can restrict it, but this account is standalone. Protect the root user with MFA and by not using it instead. Learn more: Policies and permissions in IAM (opens in a new tab)
D. Wrong: Storing and rotating the keys does not change what they are: long-term credentials with unlimited access to the account. AWS guidance is not to create root access keys at all. Give the pipeline a least-privilege IAM role instead. Learn more: AWS Secrets Manager (opens in a new tab)
AWS root user guidance includes turning on MFA, keeping the credentials tightly controlled, never creating root access keys, and using separate identities with temporary credentials for daily work and automation. Identity-based policies cannot be attached to the root user; only SCPs or RCPs can limit it, and only inside AWS Organizations.
Want more on IAM roles and policies? The 5 full-length practice sets have 10 more IAM roles and policies questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →