A company is building a secure solution that relies on an AWS Key Management Service (AWS KMS) customer managed key. The company wants to allow AWS Lambda to use the KMS key. However, the company…

Question

Options

• AUse IAM explicit deny for EC2 instance profiles and allow for Lambda roles.
• BUse a KMS key policy with kms:ViaService conditions to allow Lambda usage and deny EC2
• CUse aws:SourceIp and aws:AuthorizedService condition keys in the KMS key policy.
• DUse an SCP to deny EC2 and allow Lambda.

• A
  9% (3)
• B
  74% (25)
• C
  15% (5)
• D
  3% (1)

Explanation

AWS KMS access control is primarily enforced through key policies (and optionally grants), and AWS recommends using key policy condition keys to restrict how keys can be used. The kms:ViaService condition key is specifically designed to restrict KMS API usage to requests that come through a particular AWS service endpoint in a specific Region. This is the most robust way to ensure a key can be used only via AWS Lambda (for example, lambda.<region>.amazonaws.com) and not via Amazon EC2 (ec2.<region>.amazonaws.com), even if IAM permissions exist elsewhere. By writing a key policy that uses the Lambda execution role as the principal and conditions on kms:ViaService, the company can tightly bind key usage to Lambda-originated cryptographic operations while preventing use through EC2 service paths. Option A is weaker because EC2 is not the only way an IAM principal might use KMS, and relying on attaching explicit deny policies broadly is harder to manage and can miss principals. Option C is incorrect because aws:AuthorizedService is not the typical mechanism for KMS service restriction, and SourceIp is unreliable for service-to-service calls. Option D is not ideal because SCPs do not provide fine-grained service-path restrictions for KMS usage and cannot "allow" beyond IAM; key policy controls still apply.

No community discussion yet for this question.