Free AWS SAA-C03 Actual Exam Questions – Solutions Architect Questions - Question 14 Discussion
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? (Select TWO.)
Makes sense to go with D and E here. D is key because it directly links the Kubernetes service accounts to specific IAM roles, giving that granular control. E is essential since without establishing the trust via the OIDC identity provider, those IAM roles won’t be assumable by the service accounts. Options A and C are too broad or don’t leverage the IRSA mechanism properly, and B is unrelated to IAM permissions. So, D plus E cover both the role definition and the trust setup needed for secure, fine-grained AWS access from the pods.
It’s D and E for me too. D ties the IAM role to the Kubernetes service account directly, and E sets up the trust with OIDC so the role can actually be assumed. Without E, IRSA just won’t function.
E imo, since without the OIDC provider trust, the IAM roles can’t be assumed by service accounts. D fits too because annotating service accounts links them to the right IAM roles for granular access.
E imo, because without setting up the OIDC provider, the service accounts can't assume the IAM roles securely. D also fits since annotating the service account with the IAM role ARN is how IRSA links them.
Maybe D and E. D covers attaching the specific IAM role to the Kubernetes service account, which is key for IRSA. E is necessary because without the OIDC provider set up and trusted by the IAM role, the whole IRSA mechanism won’t function. Options A and C are more about node roles or cluster roles, which don’t provide the fine-grained access tied specifically to service accounts. B is about network policies, which control network traffic but not AWS resource permissions. So, D and E fit best for secure, granular access using IRSA.
Probably D and E here. D matches what I know about annotating service accounts with IAM roles for IRSA, and E fits since you need that OIDC trust set up between the roles and the identity provider to make it all work. The rest seem off because IRSA is about giving specific roles per service account, not attaching policies directly to node roles or messing with cluster IAM roles. Network policies won’t help with AWS permissions either, they’re more for pod communication control.