Key Management, Cross-Account Access, and CMK Design with KMS and Envelope Encryption for SCS-C03
_Category: Data Protection_
Encrypting your data means nothing if the encryption keys themselves are left unguarded. AWS KMS (Key Management Service) exists precisely to close that gap. On the SCS-C03 exam, KMS appears constantly — woven into multi-service scenarios involving S3, EBS, RDS, Secrets Manager, and more. Once you understand the key types, the permission model, and how Envelope Encryption actually works, most KMS questions become recognizable patterns you can solve with confidence.
---
The Problem KMS Solves: Why DIY Key Management Is Dangerous
Managing encryption keys yourself is a bit like storing valuables in a safe and then taping the safe's combination to the outside of the drawer. Common anti-patterns include hardcoding an AES-256 key in source code, storing it as a plaintext environment variable, or writing it to a server's local disk. Any of these approaches means a single compromised server can expose every secret that key ever protected.
AWS KMS addresses this in three concrete ways. First, all key material lives inside Hardware Security Modules (HSMs) — neither AWS employees nor customers can ever extract a plaintext master key. Second, every encrypt and decrypt operation goes through the KMS API, which means CloudTrail captures a complete, tamper-evident audit trail automatically. Third, fine-grained access control can be applied per-key and integrated directly with IAM.
On the exam, the moment you see phrases like "audit log", "track key access", or "centralized key management", KMS is the right direction. If the requirement shifts to "customer must have direct physical control of the HSM hardware", that's the signal to move toward CloudHSM instead.
---
Key Types: Customer Managed Key vs AWS Managed Key vs AWS Owned Key
KMS offers three distinct key types. Think of them like vehicle ownership: a Customer Managed Key is a car you bought outright — you decide where it goes and who drives it. An AWS Managed Key is a rental — convenient, but the rental company sets the rules. An AWS Owned Key is a taxi — you just get in and ride; you never see the keys at all.
| Attribute | Customer Managed Key (CMK) | AWS Managed Key | AWS Owned Key | |-----------|--------------------------|-----------------|---------------| | Who creates it | Customer | AWS (auto-created per service) | AWS | | Key Policy editable | Yes | No | No | | Key Rotation | Manual or automatic (annual) | Automatic (annual) | AWS-managed | | CloudTrail logging | Full detail | Logged | Not surfaced | | Cost | $1/month per key + API calls | Free | Free | | Typical use | Customer-specified CMK for S3, EBS | S3 SSE-KMS default key, RDS default encryption | S3 SSE-S3 internal key | | Cross-account sharing | Yes (via Key Policy) | No | No |
For the exam: whenever you see "I need to control the key policy directly", "a second account needs to use this key", or "I need to disable key access immediately", the answer is always a Customer Managed Key (CMK). AWS Managed Keys are convenient, but because customers cannot edit their Key Policy, they cannot satisfy those requirements.
!3 KMS key types
There is a classic trap around key rotation. A CMK created with Imported Key Material does not support automatic rotation. The recommended workaround is to create a new CMK and then reassign the KMS Alias to point at it — a manual rotation process. Redirecting the Alias is enough to switch applications to the new key with zero code changes.
---
How Envelope Encryption Works
Envelope Encryption is the conceptual heart of KMS. The name is evocative: imagine writing a password on a slip of paper, sealing it in an envelope, and then locking that envelope in a safe. The data itself is never sent to KMS. Instead, a short-lived Data Key (DEK) encrypts the data locally, and the CMK encrypts that DEK — a two-stage structure.
Encryption flow: call GenerateDataKey → KMS returns both a plaintext DEK and an encrypted DEK → use the plaintext DEK to encrypt data locally → immediately discard the plaintext DEK from memory → store the ciphertext alongside the encrypted DEK.
Decryption flow: send the encrypted DEK to the KMS Decrypt API → KMS returns the plaintext DEK → decrypt the data → immediately discard the plaintext DEK.
This design has two major practical benefits. Large payloads can be processed at full local speed (KMS handles direct encryption only for payloads under 4 KB), and disabling the CMK instantly renders every DEK it protected useless — effectively cutting off all access to that data in one action.
A common exam trap: for client-side encryption (CSE), kms:Encrypt and kms:Decrypt alone are not enough. You also need kms:GenerateDataKey to produce the DEK. There is a subtler variant with S3 multipart uploads using SSE-KMS: small files succeed with only kms:GenerateDataKey, but the CompleteMultipartUpload step for large files additionally requires kms:Decrypt. This means a Lambda function may work perfectly for small objects and fail silently on large ones — until you add that second permission.
---
The Three-Layer Permission Model: Key Policy, IAM Policy, and Grant
KMS access control works through three overlapping layers. Picture a corporate building: the Key Policy is the master building access policy etched in stone at the entrance. The IAM Policy is an individual employee badge. A Grant is a temporary visitor pass issued for a specific purpose and time window.
| Layer | Analogy | Characteristics | When applied | |-------|---------|-----------------|-------------| | Key Policy | Master building access policy | Resource-based policy attached directly to the key. IAM Policy has no effect unless Key Policy permits it | Always in effect | | IAM Policy | Employee badge | Identity-based policy (attached to role or user). Only effective if Key Policy delegates authority to the account root | Always in effect | | Grant | Temporary visitor pass | Delegates specific actions to a specific Principal temporarily. Used internally by AWS services (EBS, ECS, etc.) when they operate on a customer CMK | Effective immediately; can expire or be revoked |
The single most important rule: if the Key Policy does not include the account root principal (), then no IAM policy in that account can grant access to the key — no matter how permissive the IAM policy is. If this root delegation statement is missing, the key can become permanently unrecoverable. The KMS console adds it automatically, but when creating keys via API or infrastructure-as-code, you must include it explicitly.
The kms:ViaService condition allows key usage only when the request originates from a specified AWS service — like a building badge that only works when you swipe through the main entrance, not a side door. Adding to a Key Policy means that S3 in that region can use the key, but direct KMS API calls are blocked.
The kms:EncryptionContext condition binds decryption to the same context used during encryption. Data encrypted with in the context cannot be decrypted without providing that same context — a cryptographic guardrail that prevents production data from being decrypted in a staging environment.
Grants are the right tool when you need to delegate permissions temporarily without touching the Key Policy. AWS itself issues Grants internally when EBS volumes are attached to EC2 instances. For long-lived access control, stick with Key Policy or IAM Policy.
---
Cross-Account Key Access and Multi-Region Key Patterns
Cross-account KMS access requires explicit permission on both sides — this is the detail candidates most often miss. Account A's Key Policy must list Account B's Principal, and Account B's IAM Policy must grant the relevant role permissions like kms:Decrypt. Allowing Account B in the Key Policy is necessary but not sufficient; without the matching IAM Policy on Account B's side, access is denied.
For cross-account EBS snapshot copying, if you want to cut the dependency on the source account's CMK, re-encrypt the snapshot using the destination account's own CMK during the copy operation. After that, even if the source account is compromised, the backup snapshot remains independently governed by the destination account's key.
The aws:PrincipalOrgID condition key lets you grant access to all member accounts in an AWS Organization with a single condition — no need to update the Key Policy as new accounts are added to the org.
Multi-Region Key replicates a single primary key to additional regions. Replicated keys share the same key ID and key material, which means data encrypted in Region A can be decrypted in Region B using the replicated key — no re-encryption required. Combined with Secrets Manager multi-region replication, this eliminates the operational overhead of managing separate keys per region.
Imported Key Material lets you bring key material generated outside AWS (for example, from an on-premises HSM) into KMS. Because automatic rotation is not supported, meeting annual rotation requirements means creating a new CMK and manually reassigning the Alias. On the other hand, deleting Imported Key Material takes effect immediately — making it the right answer when an exam question demands that a key be rendered unusable within hours rather than the minimum 7-day Pending Deletion window.
---
Key AWS Service Integrations
KMS integrates with virtually every AWS storage, database, and compute service. Understanding the nuances of each integration is essential for the exam.
For S3 server-side encryption, there are three modes. SSE-S3 lets S3 generate and manage a unique AES-256 key per object — fully automatic, no KMS API calls. SSE-KMS uses a customer-specified CMK, generates CloudTrail log entries for every object access, and enables per-key access revocation. SSE-C requires the caller to supply the key on e