KMS key policies, grants, multi-Region keys and Private CA: SCS-C03 study notes and practice questions
What to know about KMS key policies, grants, multi-Region keys and Private CA for the SCS-C03 exam, from the Data Protection domain (18% of the exam guide), then 1 free question to test it. Part of the SCS-C03 study guide.
These questions describe a key that several accounts, services or Regions need. They ask how to grant the right use, revoke it when needed and keep the data recoverable. The key policy is the first place to look.
Key policy, grants and conditions
The key policy is required for every KMS key and is the primary access control. The default key policy lets the account’s IAM policies delegate access. Without that statement, IAM policies alone grant nothing.
Grants give a principal or service temporary, programmatic use of a key without changing the key policy. EBS uses grants this way. Grants can be retired or revoked.
Condition keys narrow use. kms:ViaService limits use to requests from one service. kms:CallerAccount and aws:PrincipalOrgID limit cross-account use. Encryption context limits use to matching context values, and it appears in CloudTrail.
Disabling a key blocks all use at once, which is the fast revocation. Scheduled deletion has a waiting period of 7 to 30 days, and you can cancel it during that period.
Multi-Region keys share key material and key ID across Regions, so data encrypted in one Region decrypts in a replica Region. Use them for disaster recovery or global data. A single-Region key is simpler for most workloads, and an existing single-Region key cannot be converted to multi-Region.
Organization guardrails: SCPs can deny kms:ScheduleKeyDeletion and kms:DisableKey for everyone except a security role.
Private CA
Private CA issues private certificates for internal names, devices and services. Build a hierarchy with a root CA and subordinate CAs, and limit daily issuing to the subordinate CAs so the root stays protected.
Private certificates are trusted only by clients that trust your CA. Public ACM certificates are trusted by browsers.
Short-lived certificates reduce how often revocation lists are needed.
How to choose
Scenario wording
Pick
Let a role in another account use a key
Key policy that names that account, plus the role’s IAM policy
Revoke use of a key immediately
Disable the key
Limit a key to one service, such as S3
kms:ViaService condition
Decrypt copies of data in another Region
Multi-Region key
Give a service temporary use of a key
Grant
Issue certificates for internal microservices and devices
Private CA
Common traps
An IAM policy with no key policy statement. The access is denied.
Deleting a key to revoke access. Deletion waits through a period and cannot be reversed afterward. Disable it instead.
Expecting an existing key to become multi-Region. Plan for it at creation.
A public certificate for internal names. Internal names need Private CA.
Issuing daily certificates from the root CA. Use subordinate CAs and keep the root restricted.
A small startup created a customer managed KMS key in its production account and wrote a key policy that lists only the security team role as a key administrator and key user. A developer role has an IAM policy that allows kms:Decrypt on that key, but the developer's application gets an AccessDenied error.
The developer role must be able to decrypt with that key, and the startup wants access to be managed through IAM policies rather than by editing the key policy for each person.
Which change should the security engineer make?
Choose one answer.
AA. Add a statement to the key policy that grants kms:Decrypt to the developer role by its ARN. The IAM policy alone is not enough, so the key policy must name the role directly.
BB. Change the key policy principal to an asterisk, so that every role with an IAM policy can decrypt with the key. This is the simplest way to clear the AccessDenied error for every application at once.
CC. Turn on automatic key rotation for the key, which refreshes the key policy and applies the developer's IAM policy the next time the key rotates.
DD. Add a statement to the key policy that allows the account root principal to perform KMS actions on the key. IAM policies in the account can then grant the developer role access to the key.
Show the answer and explanation
Answer: D
A. Wrong: This fixes the error for one role, but every new person would need a key policy edit. The startup wants IAM policies to manage access, so this option misses the second requirement.
B. Wrong: A wildcard principal lets any AWS principal use the key, which the startup should never allow. Access control on the key would be lost, so this creates serious exposure to fix a simple error.
C. Wrong: Rotation creates new key material for the same key and does not change the key policy or how IAM policies are evaluated. The AccessDenied error would continue until the key policy allows the account.
D. Right: Correct. A key policy that trusts the account root lets IAM policies in that account grant key permissions. The developer's existing kms:Decrypt policy then takes effect, with no key policy edit for each person. Learn more: Default key policy (opens in a new tab)
Explanation
A key policy must allow the account before IAM policies in that account can grant access to a KMS key, and the usual way is a statement that trusts the account root. Adding that delegation lets the developer's existing IAM policy take effect. Wildcard principals and rotation do not fix the cause, and per-person key policy edits conflict with the IAM-managed requirement.
Want more on KMS key policies, grants, multi-Region keys and Private CA? The 5 full-length practice sets have 5 more KMS key policies, grants, multi-Region keys and Private CA questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →
Study KMS key policies, grants, multi-Region keys and Private CA