DOP-C02 Question #254: Real Exam Question with Answer & Explanation

Question

A company uses an Amazon Elastic Kubernetes Service (Amazon EKS) cluster to deploy its web applications on containers. The web applications contain confidential data that cannot be decrypted without specific credentials. A DevOps engineer has stored the credentials in AWS Secrets Manager. The secrets are encrypted by an AWS Key Management Service (AWS KMS) customer managed key. A Kubernetes service account for a third-party tool makes the secrets available to the applications. The service account assumes an IAM role that the company created to access the secrets. The service account receives an Access Denied (403 Forbidden) error while trying to retrieve the secrets from Secrets Manager. What is the root cause of this issue?

Options

• AThe IAM role that is attached to the EKS cluster does not have access to retrieve the secrets from
• BThe key policy for the customer managed key does not allow the Kubernetes service account IAM
• CThe key policy for the customer managed key does not allow the EKS cluster IAM role to use the
• DThe IAM role that is assumed by the Kubernetes service account does not have permission to

Explanation

Explanation

Option B is correct because when AWS KMS encrypts secrets in Secrets Manager, both the IAM role policy and the KMS key policy must explicitly grant permission to the principal (in this case, the Kubernetes service account's IAM role) - if the key policy doesn't allow kms:Decrypt for that IAM role, AWS will return an Access Denied error even if the IAM role policy appears correct.

Why the distractors are wrong:

• Option A is incorrect because the issue involves the service account's IAM role, not the EKS cluster's node IAM role - these are separate roles with different purposes.
• Option C is incorrect for the same reason as A; the EKS cluster's IAM role is not the entity making the API call - the service account's assumed IAM role is.
• Option D is a plausible distractor, but since the IAM role is able to reach Secrets Manager (it gets a 403 from KMS decryption, not a general permissions failure), the missing piece is specifically the KMS key policy, not the IAM role permissions.

Memory Tip: Think of KMS encryption as a double lock 🔐🔐 - you need both the IAM policy AND the KMS key policy to grant access; missing either one results in Access Denied, even if the other is correctly configured.

No community discussion yet for this question.