IRSA for EKS: IAM Role and OIDC Trust Setup

SAA-C03 By islever Editorial Last updated

Design secure access to AWS resources.

Short answer

DE Define an IAM role with necessary permissions, annotate Kubernetes service accounts with its ARN, and set up a trust relationship with an OIDC identity provider.

Question

A company is using an Amazon Elastic Kubernetes Service (Amazon EKS) cluster. The company must ensure that Kubernetes service accounts in the EKS cluster have secure and granular access to specific AWS resources by using IAM roles for service accounts (IRSA). Which combination of solutions will meet these requirements? (Choose two.)
  1. Create an IAM policy that defines the required permissions Attach the policy directly to the IAM role of the EKS nodes.
  2. Implement network policies within the EKS cluster to prevent Kubernetes service accounts from accessing specific AWS services.
  3. Modify the EKS cluster's IAM role to include permissions for each Kubernetes service account. Ensure a one-to-one mapping between IAM roles and Kubernetes roles.
  4. Define an IAM role that includes the necessary permissions. Annotate the Kubernetes service accounts with the Amazon ResourceName (ARN) of the IAM role. Correct Answer
  5. Set up a trust relationship between the IAM roles for the service accounts and an OpenID Connect (OIDC) identity provider. Correct Answer

Key Takeaways

The core trap is confusing node-level IAM roles with pod-level IRSA; correct implementation requires both defining the IAM role permissions (Option D) and configuring the OIDC trust relationship (Option E).

This question examines the configuration of IAM Roles for Service Accounts (IRSA) in Amazon EKS to grant granular AWS permissions to Kubernetes workloads. It establishes that creating an IAM role with specific permissions and establishing a trust relationship via an OpenID Connect (OIDC) provider are the essential steps.

Common mistake: Candidates often select Option A, believing that attaching policies directly to the node's IAM role provides secure access. This fails because it grants broad, least-privilege-violating permissions to all pods on the node rather than specific service accounts.

Expert Analysis

Why the Answer Is Correct

To implement IAM Roles for Service Accounts (IRSA), two critical components must be configured. First, you must define an IAM role with the specific permissions required by the application (Option D). Second, you must establish a trust relationship between this IAM role and the Kubernetes service account using an OpenID Connect (OIDC) identity provider (Option E). The OIDC provider allows the EKS cluster to authenticate the service account, enabling the pod to assume the IAM role dynamically.

Why the Other Options Are Wrong

Option A is incorrect because attaching policies to the EC2 instance profile (node role) grants permissions to every pod on that node, violating the principle of least privilege. Option B is incorrect because Kubernetes network policies control traffic flow, not AWS API access or IAM authentication. Option C is incorrect because modifying the cluster's own IAM role does not enable granular per-service-account access; the cluster role is used for the control plane, not workload authentication.

Community Comment Notes

Community consensus strongly supports options D and E, with multiple users citing official AWS documentation as proof. One user noted that IRSA is specifically designed to eliminate over-permissive configurations found in Option A. Another commenter highlighted that AWS resource access is managed by IAM, not Kubernetes network policies, ruling out Option B immediately.

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

When asked about securing pod access to AWS resources in EKS, always look for the combination of an IAM Role definition and an OIDC provider trust relationship. Avoid options involving node instance profiles unless the question explicitly asks for broad, non-granular access.

Frequently Asked Questions

Why can't I attach the IAM policy directly to the EKS node?

Attaching to the node grants permissions to all pods on that node, violating least privilege. IRSA scopes permissions to specific service accounts.

What is the role of the OIDC provider in IRSA?

The OIDC provider enables the IAM role to trust tokens issued by the EKS cluster's Kubernetes service account, allowing dynamic assumption of the role.

More SAA-C03 FAQ →

Community Votes

DE
100%

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

Discussion 6 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 6

  1. spoved 👍 4
    https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html => DE
  2. [Removed] 👍 2
    chatgpt: D. Define an IAM role that includes the necessary permissions. Annotate the Kubernetes service accounts with the Amazon Resource Name (ARN) of the IAM role: Granular Access Control: By defining an IAM role with the necessary permissions and annotating the Kubernetes service accounts with the ARN of this IAM role, you can achieve fine-grained access control for specific AWS resources. This allows each service account to have only the permissions it needs. E. Set up a trust relationship between the IAM roles for the service accounts and an OpenID Connect (OIDC) identity provider: IRSA Integration: To enable IRSA, your EKS cluster must be associated with an OpenID Connect (OIDC) identity provider. This trust relationship allows Kubernetes service accounts to assume IAM roles, enabling secure and granular access to AWS resources.
  3. mooondooo 👍 2
    probably D and E https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-enable-IAM.html
  4. LeonSauveterre 👍 1
    A - Attaching policies to the IAM role of the EKS nodes provides broad permissions to all pods running on the nodes. IRSA is designed to eliminate such over-permissive configurations. B - AWS resource access is managed by IAM, not Kubernetes network policies. C - EKS cluster’s IAM role is not meant to handle granular access for service accounts. D - Ensures fine-grained access control at the service account level. E - Allows Kubernetes service accounts to assume IAM roles securely.
  5. Dantecito 👍 1
    This was in my Exam today. Good Luck!!!!!!!!!!!!
Show 1 more comment
  1. 744fdad 👍 1
    my educated guess C, E

Reader comments & corrections

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

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

S3 Multi-Region Access Point and Replication Strategy

S-grade

Securing NLB with Security Groups for Minimal Change

S-grade

Most Cost-Effective 7-Year Retention for EBS Snapshots?

S-grade

AWS Forecast vs SageMaker for Time-Series Prediction

S-grade

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