EKS IRSA Pod Access Control with IAM Roles

SAA-C03 By islever Editorial Last updated Oct 11, 2026

Short answer

C Create separate Kubernetes service accounts for the UI and data services to assume an IAM role, attaching DynamoDB access to the UI account and S3 access to the data account.

Question

A company has an application that runs on an Amazon Elastic Kubernetes Service (Amazon EKS) cluster on Amazon EC2 instances. The application has a UI that uses Amazon DynamoDB and data services that use Amazon S3 as part of the application deployment. The company must ensure that the EKS Pods for the UI can access only Amazon DynamoDB and that the EKS Pods for the data services can access only Amazon S3. The company uses AWS Identity and Access Management (IAM). Which solution meals these requirements?

Create separate IAM policies for Amazon S3 and DynamoDB access with the required permissions. Attach both IAM policies to the EC2 instance profile. Use role-based access control (RBAC) to control access to Amazon S3 or DynamoDB for the respective EKS Pods.
Create separate IAM policies for Amazon S3 and DynamoDB access with the required permissions. Attach the Amazon S3 IAM policy directly to the EKS Pods for the data services and the DynamoDB policy to the EKS Pods for the UI.
Create separate Kubernetes service accounts for the UI and data services to assume an IAM role. Attach the AmazonS3FullAccess policy to the data services account and the AmazonDynamoDBFullAccess policy to the UI service account. Correct Answer
Create separate Kubernetes service accounts for the UI and data services to assume an IAM role. Use IAM Role for Service Accounts (IRSA) to provide access to the EKS Pods for the UI to Amazon S3 and the EKS Pods for the data services to DynamoDB.

Key Takeaways

The core concept tested is IAM Role for Service Accounts (IRSA) in EKS, with the common trap being a deliberate swap of resource permissions between options C and D.

This question tests the implementation of fine-grained access control for Amazon EKS pods using IAM Roles for Service Accounts (IRSA). It establishes that correct mapping of service accounts to specific IAM policies is critical for least privilege security.

Common mistake: Many candidates select Option D because it correctly describes the mechanism but fails by assigning S3 access to the UI pods instead of DynamoDB, violating the requirement.

Expert Analysis

Why the Answer Is Correct

Option C is the correct solution because it leverages IAM Roles for Service Accounts (IRSA), which allows Kubernetes service accounts to assume IAM roles directly. This enables fine-grained, least-privilege access where the UI pods are mapped to a role with DynamoDB access, and data service pods are mapped to a role with S3 access. Although 'FullAccess' policies are broad, the option correctly assigns the types of access requested (DynamoDB to UI, S3 to Data) via distinct service accounts.

Why the Other Options Are Wrong

Option A attaches both policies to the EC2 instance profile, granting all pods on the node access to both services, which violates the isolation requirement. Option B suggests attaching IAM policies directly to EKS Pods, which is not a valid AWS mechanism; IAM identities must be attached to nodes or roles assumed by service accounts. Option D uses the correct IRSA mechanism but swaps the permissions, giving the UI pods S3 access and data pods DynamoDB access, which contradicts the prompt's requirements.

Community Comment Notes

Community consensus heavily favored C, noting that D was a trick answer due to the swapped resources. As user LeonSauveterre noted, "A - This is a major security flaw... D - This option mixes up the permissions." Another commenter, BugsyWarribwoy, emphasized, "D is sneakily WRONG because it swaps the services incorrectly." Several users pointed out that while FullAccess is not ideal, C is the only option that maps the correct services to the correct pods.

Official Reference

https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html

This link opens the official vendor documentation in a new tab.

Exam Strategy

Always read the resource assignment carefully in IRSA questions. If an option describes the correct technology (like IRSA) but assigns the wrong permission to the wrong workload, it is incorrect. Prioritize the logical mapping of identity to resource over the granularity of the policy when choosing between similar technical implementations.

Frequently Asked Questions

Why is Option A insecure for EKS pod isolation?

Attaching multiple policies to the EC2 instance profile grants all pods on that node access to all associated AWS resources, violating least privilege.

Does IRSA support direct pod-to-IAM attachment?

No. IRSA works by binding a Kubernetes Service Account to an IAM Role, which the pod then assumes via the OIDC provider.

More SAA-C03 FAQ →

Community Votes

69%

31%

69% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 8 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 8

jingen11 👍 8 Answered D

https://docs.aws.amazon.com/eks/latest/userguide/service-accounts.html#service-accounts-iam
LeonSauveterre 👍 4 Answered C

A - This is a major security flaw. All Pods running on the EC2 instances would inherit both the S3 and DynamoDB permissions. B - Directly attaching IAM policies to Pods is not a valid AWS mechanism. You should use roles. C - Not recommended unless we throw least privilege principles to the wind. BUT this is the only feasible option here, so. D - This option mixes up the permissions. It gives UI Pods access to S3 and data service Pods access to DynamoDB, which is the OPPOSITE of the requirement.
BugsyWarribwoy 👍 4 Answered C

D is sneakily WRONG because it swaps the services incorrectly. Pay attention. UWC.
GOTJ 👍 3 Answered C

Even though there are a couple of comments rightfully discarding "D" because the UI --> S3/DataServices --> DynamoDB swap, I found an AWS document claiming that Kubernetes Service accounts and IAM Role for Service Accounts combination should be the right answer: https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html Having this in mind, I'm also discarding "D" (right reasoning, wrong scenario), as well "A" and "B". I didn't like the "full access" policy, but is technically correct, so my vote goes to "C"
trinh_le 👍 3 Answered C

A. Attach both IAM policies to the EC2 instance profile. Does not separate each EKS Pod B. Aws does not support Attach the Amazon S3 IAM policy directly to the EKS Pods D. provide access “UI to Amazon S3” and “data services to DynamoDB” => it does not meet requirements

Show 3 more comments

FlyingHawk 👍 2 Answered C

IRSA allows Kubernetes service accounts to assume IAM roles, enabling fine-grained access control for EKS Pods. This ensures that each Pod can access only the AWS resources it needs. Attach the AmazonDynamoDBFullAccess policy to the service account for the UI Pods, allowing them to access only DynamoDB. Attach the AmazonS3FullAccess policy to the service account for the data services Pods, allowing them to access only S3.
rosanna 👍 2 Answered C

The answer is C as they're switching data pods with DynamoDB service and vice versa (configure the wrong resources)
tm1000000 👍 1

answer is D

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Practice All SAA-C03 Questions

Access 120 questions with complete answers and detailed explanations.

View Full SAA-C03 Practice Test →

← Back to SAA-C03 Study Guide