A company uses an Amazon Elastic Kubernetes Service (Amazon EKS) cluster to deploy its web...

Accessing a secret from AWS Secrets Manager that is encrypted with a customer managed KMS key requires two distinct permission layers to succeed:

Secrets Manager permissions (via IAM) such as secretsmanager:GetSecretValue for the IAM role assumed by the Kubernetes service account.

KMS key usage permissions in the KMS key policy , allowing the same IAM principal to perform kms:Decrypt (and possibly kms:GenerateDataKey ) on the customer managed key.

In this scenario, the service account assumes an IAM role explicitly created to access the secrets. The symptom is an HTTP 403 “Access Denied” when retrieving the secret. If the IAM role has Secrets Manager permissions but the call still fails, the typical root cause is that the KMS key policy does not trust or allow that IAM role , so the decrypt operation fails.

Option B correctly identifies that the KMS key policy must include the Kubernetes service account IAM role as a principal with the appropriate KMS actions.

Option A and C refer to the EKS cluster IAM role, which is not the principal making the call. Option D is unrelated: the role’s ability to “access the EKS cluster” does not affect its ability to call Secrets Manager or KMS. The missing KMS key policy permission is the underlying cause.