Jeff’s Note #
Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Site Reliability Engineer (SRE).
For SOA-C02 candidates, the confusion often lies in how to manage rotation of customer master keys (CMKs) when the key material is manually imported, not generated by AWS. In production, this is about knowing exactly that AWS does not support automatic rotation for imported key material, and so rotation involves key material replacement rather than automated key regeneration. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
Acme DataOps Inc. relies heavily on AWS KMS to secure sensitive telemetry logs from their IoT device fleet in a remote region. They use a customer managed CMK with imported key material to meet strict compliance requiring control over cryptographic keys. The CMK is referenced in their Java-based ingestion pipeline through an alias.
Compliance mandates that the key material must be rotated every 6 months to maintain security. The SRE team needs to implement a secure, operationally sound key rotation process.
The Requirement: #
Determine the correct method for rotating the imported key material of the CMK every 6 months without disrupting service or violating compliance.
The Options #
- A) Enable AWS KMS automatic key rotation and specify a 6-month rotation schedule.
- B) Create a new CMK, import new key material into it, and update the alias in the application to point to the new CMK.
- C) Delete the current key material from the existing CMK and import new key material into the same CMK.
- D) Import a copy of the current key material into a new CMK as a backup, and set a 6-month rotation schedule.
Google adsense #
leave a comment:
Correct Answer #
B.
Quick Insight: The SysOps Imperative #
- AWS KMS does not support automatic rotation of CMKs when key material is imported manually by the customer.
- Rotation requires creating a new CMK and importing fresh key material, then redirecting alias usage to the new CMK.
- Attempting to delete and re-import key material in the same CMK is not supported and risks downtime or key state corruption.
- Backup copies inside new CMKs do not equate to rotation or proper key lifecycle management.
Content Locked: The Expert Analysis #
You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?
The Expert’s Analysis #
Correct Answer #
Option B
The Winning Logic #
AWS KMS handles automatic CMK rotation only for keys with AWS-generated key material. CMKs with imported key material require manual rotation. This means you cannot simply “rotate” the key material in place by deleting and re-importing it under the same CMK.
The recommended and supported approach is:
- Create a new CMK.
- Import new cryptographic key material into that new CMK.
- Update aliases and application references to point to the new CMK.
- Decommission the old CMK once data is re-encrypted or previous ciphertext is no longer needed.
This approach ensures a clean key lifecycle and meets the compliance requirement for rotation every 6 months.
The Trap (Distractor Analysis): #
- Why not A? Automatic key rotation is only supported for AWS-generated key material CMKs, not imported keys.
- Why not C? You cannot delete key material from an existing CMK and replace it; AWS KMS does not provide that functionality for imported keys.
- Why not D? Importing the same material into a new CMK is not rotation; it merely copies the key, which does not improve security or compliance posture.
The Technical Blueprint #
# Example CLI commands to import new key material into a new CMK and update alias
# Step 1: Create new CMK
aws kms create-key --description "Rotation key for telemetry data (imported material)"
# Step 2: Import key material process
# - Retrieve import token and public key from AWS KMS
# - Encrypt your key material using the provided public key
# - Use aws kms import-key-material CLI command to upload encrypted key material
aws kms get-parameters-for-import --key-id <new-key-id> --wrapping-algorithm RSAES_OAEP_SHA_1 --wrapping-key-spec RSA_2048
aws kms import-key-material --key-id <new-key-id> --encrypted-key-material fileb://encrypted_key_material.bin --import-token fileb://import_token.bin --expiration-model KEY_MATERIAL_EXPIRES --valid-to <ISO8601-date>
# Step 3: Update alias to point to the new CMK
aws kms update-alias --alias-name alias/TelemetryKey --target-key-id <new-key-id>
# Step 4: Deprecate or disable old CMK after re-encryption or data migration
The Comparative Analysis #
| Option | Operational Overhead | Automation Level | Impact on Service |
|---|---|---|---|
| A | Low (if supported) | Automatic rotation | Not supported for imported key material; will not rotate key material |
| B | Medium (manual CMK creation and alias update) | Manual process | Correct approach, no data loss, low risk when done carefully |
| C | Low complexity but unsupported | None | Not supported; risky, can cause key material loss or errors |
| D | High (backup via duplication) | None | Does not fulfill rotation requirements, merely backs up key material |
Real-World Application (Practitioner Insight) #
Exam Rule #
For the exam, always pick Option B when a question involves rotation of imported key material CMKs.
Real World #
In reality, many teams automate the creation of the new CMK and alias updates via Infrastructure as Code (IaC) or AWS SDK scripts to reduce human error and downtime during rotation. Manual deletion of key material in place is never done due to AWS KMS constraints.
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the AWS SOA-C02 exam.