SCS-C02 Data Protection Practice Question
A company uses AWS KMS to encrypt EBS volumes. They want to ensure that the key used for EBS encryption is not shared across different AWS accounts. Which feature should they use?
⚠ Common exam trap
It's easy for candidates to confuse key rotation (Option C) or aliases (Option B) with access control, or assume that CloudHSM (Option A) inherently isolates keys across accounts, when in fact only the key policy can enforce account-level restrictions.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Configure the key policy to deny access to any principal from another AWS account.
AWS KMS key policies can explicitly deny access to principals from other AWS accounts by using the `aws:SourceAccount` or `aws:SourceArn` condition keys, or by specifying a `Deny` statement with a condition that checks the account ID. This ensures that the KMS key used for EBS encryption cannot be used by any IAM principal or role from a different AWS account, preventing cross-account key sharing.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use a CloudHSM custom key store.
Why it's wrong here
A CloudHSM custom key store generates and stores KMS key material in a CloudHSM cluster under your control, but it does not change how KMS authorizes use of the key. Access decisions are still made by the key policy and IAM policies, and those policies can still grant cross-account principals access. Thus it protects cryptographic material at the hardware level, not the AWS account boundary.
- ✗
Use the key's alias to restrict access.
Why it's wrong here
Key aliases are human-friendly display names that map one-to-one to a KMS key; they are not principals and are not evaluated as part of access control. You cannot scope a key policy to an alias, and changing an alias does not revoke permissions already granted to a principal. Restricting an alias therefore does nothing to prevent another account from using the underlying key.
- ✗
Enable automatic key rotation.
Why it's wrong here
Automatic key rotation for a customer managed key creates new backing key material every year while preserving the same key ID, key policy, and grants. Rotation is a cryptographic control that merely limits the amount of data encrypted with one key version; it has no effect on who can call KMS operations. A cross-account principal with existing permissions continues to have those permissions after rotation.
- ✓
Configure the key policy to deny access to any principal from another AWS account.
Why this is correct
Configure the key policy with a Deny statement that uses the aws:PrincipalAccount condition to block any principal whose account ID does not match the expected account. Since the key policy is the authoritative resource-based policy for the KMS key, an explicit deny overrides any IAM permissions in another account and prevents cross-account EBS volume or snapshot sharing. This directly enforces the desired account boundary.
Go deeper
Related to this question
About these practice questions
One of 1,205 original SCS-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SCS-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SCS-C02 exam.