What's changed: Deepened SCS-C02 Chapter 5 (added comparison tables, scenarios, FAQs, exam traps, deep-dive paragraphs to each section; localized figures to Japanese)
5.1KMS and Encryption
Understand at-rest encryption core—KMS, CMK (customer-managed keys), envelope encryption, key policies, key rotation, and CloudHSM. Manage keys securely and encrypt data.
KMS is central to data protection. Understand key management, access control, and encryption mechanics precisely.
5.1.1How KMS works
- Envelope encryption: a CMK encrypts a data key; data is encrypted by the data key.
- CMK types: AWS-managed and customer-managed (CMK); the latter controls policy/rotation.
- Access control: the key policy is the root of trust. IAM alone is never enough, and where the key policy delegates to IAM an IAM allow is required too.
- CloudHSM: use for strict requirements needing FIPS 140-2 Level 3 / dedicated HSM.
Common on SCS-C02: key management/at-rest encryption = KMS, CMK encrypts data key = envelope encryption, KMS access = key policy + IAM, dedicated HSM/FIPS Level 3 = CloudHSM, automatic rotation. Note: without an explicit key-policy allow, even an IAM admin cannot use the key.
SCS-C02 key management precisely probes "KMS access control, key types, rotation, and grants." In envelope encryption, KMS GenerateDataKey returns a plaintext and an encrypted data key; the app encrypts data with the plaintext key, discards the plaintext, and stores the ciphertext plus the encrypted data key (to decrypt, send the encrypted data key to KMS for the plaintext). Key types: AWS-managed keys (auto-created/managed by services, policy not editable), customer-managed keys (CMKs) (you control key policy/rotation/aliases), and AWS-owned keys (invisible). CMKs can be symmetric/asymmetric and serve different uses (encrypt/sign/HMAC), and multi-region keys replicate to other regions. Access control is both "key policy + IAM," with the key policy as the root of trust—without a key-policy allow, IAM allows nothing (conversely, if the key policy delegates to IAM, IAM can control). For temporary, fine-grained delegation, use grants. Rotation: CMKs support automatic rotation—annual (~365 days) by default, or a custom 90–2560 day period since 2024 (old versions retained to decrypt)—and deletion goes through a waiting period (7–30 days) before disablement (prevents accidental deletion). For stricter FIPS 140-3 Level 3 (CloudHSM current hsm2m), dedicated keys, or a custom key store, use CloudHSM. The key is to nail the envelope-encryption flow, the two-part key policy + IAM, CMK controllability, rotation/deletion waiting, and when to use CloudHSM.
| Item | AWS-managed key | Customer-managed (CMK) |
|---|---|---|
| Key policy control | No (automatic) | Yes (you control) |
| Rotation | Automatic (default) | Default annual; customizable 90–2560 days |
| Cross-account share | No | Yes (via key policy) |
| Use | Simple; service default | When strict control/audit needed |
Scenario: Encrypt another account’s S3 bucket with your CMK and audit/control key usage. → Create a customer-managed key (CMK), allow the other account/role kms:Decrypt/kms:GenerateDataKey in the key policy (cross-account share), and allow the same in the other side’s IAM. Set S3 to SSE-KMS with that CMK. Key usage is logged to CloudTrail for audit, enable annual automatic rotation, and deletion uses a waiting period to prevent accidents.
FAQ: KMS vs CloudHSM? Most encryption needs are met by KMS (managed, integrated with AWS services, low ops). Use CloudHSM for strict requirements—a dedicated single-tenant HSM, FIPS 140-2 Level 3, your own key hierarchy, or regulations mandating physical key custody—optionally as a KMS custom key store. The rule: KMS first, CloudHSM only for special requirements.
Exam trap: Assuming "an IAM admin can always use a KMS key" is wrong—KMS’s key policy is the root of trust; unless the key policy allows (or delegates to IAM), an IAM allow does nothing. Also, a CMK cannot be deleted instantly—there is a waiting period to prevent accidents, and deletion makes encrypted data undecryptable (usually disable instead).
5.1.2Section summary
- Keys = KMS (CMK + envelope encryption + rotation)
- Access = key policy as root of trust (+ IAM when delegated) / dedicated HSM = CloudHSM
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. What is the root of trust for whether you can use a KMS key?
Q2. Requirements demand a dedicated HSM and FIPS 140-2 Level 3. What?
Q3. Which KMS mechanism efficiently encrypts large data?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.