SAP-C02 Practice Question 15: EKS Pod Level AWS Permissions
AWS Certified Solutions Architect – Professional (SAP-C02) · Test 2 · question 5 of 10
A company is building a platform on Amazon EKS. It will run about 30 clusters across several accounts, and clusters are routinely created and destroyed as part of blue/green cluster upgrades. All worker nodes are Linux Amazon EC2 instances in managed node groups. Hundreds of microservices call AWS services such as Amazon S3, Amazon SQS, and Amazon DynamoDB.
The security team has set these requirements. Each microservice gets only the IAM permissions of its own role, and a pod must not be able to use another pod's credentials or the node's role for application access. No long-lived access keys may be stored in Kubernetes secrets. The IAM team does not want to create an IAM OIDC identity provider for every cluster or edit role trust policies each time a cluster is replaced. The same application role must work unchanged in any cluster that runs that application.
Which approach should the solutions architect recommend?
Show answer and explanation
Answer:
EKS Pod Identity gives pods short-lived credentials scoped to an IAM role associated with their Kubernetes service account, so each microservice gets least privilege without stored keys. Its differentiator is the constraint that decides this question. It doesn't use OIDC identity providers. A role is made usable by adding the single service principal pods.eks.amazonaws.com to its trust policy. The documentation states that if the same application runs in multiple clusters, you can make identical associations in each cluster without modifying the role's trust policy. Replacing a cluster during a blue/green upgrade then means recreating associations in EKS, with no IAM work. Credential isolation holds as long as access to the node's instance metadata is restricted, as the scenario requires. The workload also fits Pod Identity's restrictions: it runs on Linux EC2 nodes, not on Fargate, where Pod Identity isn't supported.
Option B, IRSA, is the older answer and would satisfy least privilege, but it fails the stated IAM constraints. Every cluster has its own OIDC issuer that must be registered as an IAM identity provider. Each role's trust policy names specific issuers, so every new cluster in a blue/green rotation forces trust policy edits across hundreds of roles.
Option A is the anti-pattern that pod-level identity exists to remove. Every pod on a node can use the node role, so every microservice effectively holds the union of all permissions. Network policies control packet flows, not IAM authorization, and AWS API endpoints are shared by many services.
Option C reintroduces long-lived access keys, which the security team explicitly banned. Storing them in Secrets Manager and rotating them doesn't change that they are long-lived IAM user credentials.
Reference: Learn how EKS Pod Identity grants pods access to AWS services