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.
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.
Explanations:
Attaching both IAM policies to the EC2 instance profile is not ideal for fine-grained access control for EKS Pods. RBAC controls access at the Kubernetes level, but it does not manage IAM permissions to AWS resources like DynamoDB or S3.
IAM policies cannot be directly attached to EKS Pods. IAM roles for service accounts (IRSA) are the correct method for granting specific IAM permissions to EKS Pods.
While creating separate Kubernetes service accounts is part of the solution, IAM roles should be used via IRSA. Attaching IAM policies directly to the service accounts is incorrect as service accounts themselves do not assume IAM roles.
This option correctly uses Kubernetes service accounts with IAM roles for service accounts (IRSA) to grant the appropriate permissions for EKS Pods. It ensures that the UI Pods access only DynamoDB and the data service Pods access only S3.