SAA-C03 practice question: IAM roles and policies (2 of 3)
Design Secure Architectures A free question from our original SAA-C03 practice exam. Try it, then open the answer to see why each option is right or wrong.
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.
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 →