Study guide
15.2 Cryptographic Controls & Key Management with AWS KMS & ACM
AWS Certified DevOps Engineer – Professional Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: CI/CD Pipeline Architecture & Source Integration
1.1 Multi-Stage & Multi-Account CodePipeline Design 1.2 CodeBuild Projects, Build Environments & Pipeline Secrets 1.3 Source Control Workflows, Webhooks & Branching Models
2 Chapter 2: Automated Testing, Test Gates & Quality Verification
2.1 Automated Unit, Integration & Acceptance Testing in Pipelines 2.2 Load Testing, Performance Benchmarking & Synthetic Canaries 2.3 Security Scanning, SAST/DAST & Approval Gates
3 Chapter 3: Artifact Management & Multi-Platform Deployment Strategies
3.1 Artifact Lifecycle Management with CodeArtifact, ECR & S3 3.2 Automated Image Baking with EC2 Image Builder 3.3 In-Place, Rolling & Immutable Deployments on EC2 3.4 Blue/Green & Canary Deployments for ECS, EKS & Lambda
4 Chapter 4: CloudFormation, CDK & Reusable IaC Components
4.1 Advanced CloudFormation: Nested Stacks, Change Sets & Custom Resources 4.2 Cross-Account & Multi-Region StackSets & Drift Detection 4.3 Modern IaC: AWS CDK, SAM & Service Catalog Governance
5 Chapter 5: Multi-Account Architecture, Organizations & Control Tower
5.1 AWS Organizations Hierarchy, OUs & Account Provisioning 5.2 Service Control Policies (SCPs) & Multi-Account Guardrails 5.3 AWS Control Tower, Account Factory & Landing Zone Automation
6 Chapter 6: Systems Manager & Large-Scale Fleet Configuration
6.1 SSM Agent, Hybrid Activation & Session Manager 6.2 Systems Manager Run Command, State Manager & Associations 6.3 Patch Manager, Parameter Store vs Secrets Manager & AppConfig
7 Chapter 7: High Availability & Multi-Region Resiliency
7.1 Designing Resilient Multi-AZ & Multi-Region Architectures 7.2 Route 53 Traffic Flow, Health Checks & DNS Failover 7.3 Data Replication: Aurora Global DB, DynamoDB Global Tables & S3 CRR
8 Chapter 8: Scalability, Auto Scaling & Disaster Recovery Automation
8.1 EC2 Auto Scaling Policies, Lifecycle Hooks & Warm Pools 8.2 Container & Serverless Scalability: ECS Capacity Providers, EKS & API Gateway 8.3 Disaster Recovery Strategies: RTO, RPO & Architecture Tiers 8.4 Automated Backup & Recovery with AWS Backup & Elastic Disaster Recovery
9 Chapter 9: CloudWatch Metrics, Agent Collection & Log Aggregation
9.1 CloudWatch Metrics, Dimensions, Metric Math & High Resolution 9.2 Unified CloudWatch Agent & Custom Metric Collection 9.3 Centralized Log Aggregation, Retention & Cross-Account Subscriptions
10 Chapter 10: Log Analysis, Dashboards & Distributed Tracing with X-Ray
10.1 CloudWatch Logs Insights, Filter Syntax & Query Optimization 10.2 CloudWatch Dashboards, Composite Alarms & Anomaly Detection 10.3 Distributed Tracing with AWS X-Ray & Service Maps
11 Chapter 11: Automated Observability & Event-Driven Monitoring
11.1 Application & Infrastructure Health Checks with Route 53 & ALB 11.2 Centralized Observability with Amazon OpenSearch & Athena 11.3 Synthetic Monitoring with CloudWatch Synthetics Canaries
12 Chapter 12: Event-Driven Incident Detection & Notification Pipelines
12.1 AWS Health, CloudTrail Events & Operational Notification 12.2 EventBridge Event Routing, Patterns & Multi-Account Buses 12.3 Asynchronous Event Processing: SNS, SQS Queues & Dead-Letter Handling
13 Chapter 13: Automated Remediation & Deployment Troubleshooting
13.1 AWS Config Managed Rules & Automated Remediation with SSM 13.2 Event-Driven Infrastructure Self-Healing with Lambda & Step Functions 13.3 Troubleshooting CI/CD Pipeline & Deployment Failures 13.4 Root Cause Analysis for Auto Scaling & Container Failures
14 Chapter 14: Identity, Access Management & Secrets at Scale
14.1 IAM Policy Evaluation Logic, NotAction & Explicit Denies 14.2 IAM Permissions Boundaries & Delegated Administration 14.3 IAM Identity Center, Cross-Account Roles & STS Session Policies 14.4 Automated Secrets Management & Secret Rotation with Secrets Manager
15 Chapter 15: Security Automation, Data Protection & Compliance Auditing
15.1 Network Security Automation: Security Groups, NACLs, Network Firewall & WAF 15.2 Cryptographic Controls & Key Management with AWS KMS & ACM 15.3 Automated Threat Detection: GuardDuty, Inspector & Security Hub 15.4 Continuous Compliance Auditing & Log Integrity with CloudTrail & Config
15.2 Cryptographic Controls & Key Management with AWS KMS & ACM
Key Takeaways Explain This Topic AI
AWS KMS manages three distinct key tiers: AWS owned keys (internal, free, invisible), AWS managed keys (service-default, free, immutable key policy, automatic 1-year rotation), and Customer Managed Keys (CMKs; full control, customizable policies, configurable 90-to-2560-day or on-demand rotation, cross-account sharing).
Key Policies represent the fundamental access control boundary for KMS keys; IAM policies cannot grant access to a KMS key unless the key policy explicitly delegates permission to the root principal (arn:aws:iam::account-id:root).
Envelope encryption handles arbitrary-size application data without exceeding the KMS Encrypt plaintext limit of 4,096 bytes: KMS protects a data-encryption key, while the client encrypts the payload locally and stores the encrypted data key with the ciphertext.
AWS Certificate Manager (ACM) provisions public SSL/TLS certificates with seamless, zero-touch automated renewal via DNS validation (CNAME records), whereas AWS Private CA enables centralized issuance and management of private certificates for microservice mutual TLS (mTLS) and internal VPC workloads.
Last updated: September 2026
AWS KMS Cryptographic Architecture & Key Tiers
AWS Key Management Service (AWS KMS) provides centralized, hardware security module (HSM)-backed cryptographic key generation and management validated under FIPS 140-2 Cryptographic Module Validation Program (FIPS 140-3 Level 3 for modern HSMs). Understanding the operational tiers of KMS keys is vital for DevOps engineers designing data protection pipelines.
KMS Key Categories Comparison
Dimension AWS Owned Keys AWS Managed Keys Customer Managed Keys (CMKs)
Naming Convention Internal AWS identifier aws/service-name (e.g., aws/s3 , aws/ebs ) Custom alias (e.g., alias/prod-payment-key )
Visibility in Account Invisible in KMS console/CLI Visible in KMS console/CLI Fully visible and manageable in console/CLI
Key Policy Modification Cannot view or modify Can view; cannot modify key policy Full control to edit key policies and grants
Key Rotation Managed internally by AWS Automatically rotated every 1 year (365 days) Configurable automatic rotation ( 90 to 2560 days , default 365 days) or manual on-demand
Cross-Account Access Unsupported Unsupported (restricted to originating account) Fully supported via cross-account key policies
- Pricing Free Free to create; pay per API call $1.00/month per key + API request costs
- Cryptographic Types Symmetric only Symmetric only Symmetric, Asymmetric (RSA/ECC), and HMAC
- KMS Key Policies, IAM Policies & Access Control
Unlike most AWS services where IAM policies alone can grant access, AWS KMS enforces a strict hierarchical authorization model: The Key Policy is the primary access control document . IAM policies are completely powerless unless the Key Policy explicitly delegates authority.
The Critical Root Principal Delegation Statement
For an IAM identity policy (attached to a role, user, or group) to grant permissions to a KMS key, the Key Policy must contain the following default delegation statement: {
- "Sid": "Enable IAM User Permissions",
- "Effect": "Allow",
- "Principal": {
- "AWS": "arn:aws:iam::111122223333:root"
- },
- "Action": "kms:*",
- "Resource": "*"
- }
Warning
DOP-C02 Exam Critical Warning : In this context, arn:aws:iam::111122223333:root does not refer to the root user account credentials; it represents the AWS Account entity . This statement delegates access control to the account's IAM service. If this statement is removed or omitted and no other IAM principal is explicitly allowed in the Key Policy, the key becomes orphaned : no IAM policy in the account can grant access, and only the AWS account root user credentials can restore the Key Policy.
Key Policies vs. KMS Grants
While Key Policies provide static access definitions, KMS Grants offer dynamic, programmatic, and fine-grained access delegation without requiring updates to the JSON Key Policy.
Use Cases for Grants : Used extensively by AWS services (e.g., Amazon EBS when attaching an encrypted volume to an EC2 instance, or Amazon RDS creating read replicas across regions). Grants can be scoped with an EncryptionContextEquals condition and revoked via kms:RevokeGrant or retired via kms:RetireGrant .
Operational Advantage : Prevents hitting Key Policy character limits (maximum 32 KB) when dozens of microservices or automated deployment workers require temporary cryptographic rights.
Key Rotation Mechanics: Automatic vs. On-Demand
AWS KMS provides two mechanisms for rotating the backing cryptographic key material of Customer Managed Keys.
1. Automatic Key Rotation
When automatic rotation is enabled on a symmetric CMK:
AWS KMS automatically creates a new version of the underlying cryptographic key material on the specified schedule (configurable between 90 and 2560 days ; defaults to 365 days).
The Key ID, Key ARN, Key Policy, and Aliases remain unchanged .
KMS retains all historical backing key material indefinitely. When an application calls kms:Encrypt , KMS uses the latest key material version. When an application calls kms:Decrypt on legacy data encrypted years earlier, KMS detects the backing key version stored in the ciphertext metadata and transparently decrypts it.
Zero operational overhead : No re-encryption pipelines, database migrations, or application configuration updates are needed.
2. Manual / On-Demand Key Rotation
Used when automatic rotation is unsupported (e.g., asymmetric keys) or when an organization must rotate keys immediately following a security incident.
The engineer generates a completely new CMK with a new Key ID and ARN.
The engineer updates the Key Alias ( alias/app-key ) to point to the new Key ID.
Previous CMKs must be preserved indefinitely to decrypt legacy ciphertext unless all historical datasets are re-encrypted using the new key.
Cross-Account KMS Key Sharing Pattern
Sharing KMS keys across AWS accounts is a standard requirement in multi-account enterprise architectures (e.g., CI/CD account deploying encrypted resources to production, or centralized S3 data lakes).
Two-Sided Authorization Architecture
Cross-account KMS access requires explicit permission on both sides of the trust boundary: Account A (Key Owner: 111122223333) Account B (Consumer: 444455556666)
- ┌──────────────────────────────────────┐ ┌──────────────────────────────────────┐
- │ KMS Customer Managed Key │ │ IAM Role: AppDeploymentRole │
- │ │ │ │
- │ Key Policy: │ │ Attached IAM Policy: │
- │ { │ │ { │
- │ "Effect": "Allow", │ │ "Effect": "Allow", │
- │ "Principal": { │◄────┼───│ "Action": [ │
- │ "AWS": "arn:aws:iam::4444..." │ │ │ "kms:Encrypt", │
- │ }, │ │ │ "kms:Decrypt", │
- │ "Action": [ │ │ │ "kms:GenerateDataKey" │
- │ "kms:Encrypt", │ │ │ ], │
- │ "kms:Decrypt", │ │ │ "Resource": "arn:aws:kms:..." │
- │ "kms:GenerateDataKey" │ │ │ } │
- │ ], │ │ } │
- │ "Resource": "*" │ └──────────────────────────────────────┘
- │ } │
- └──────────────────────────────────────┘
Account A (KMS Owner) : The KMS Key Policy must explicitly declare Account B (or the specific IAM role ARN in Account B) as a trusted principal for kms:Decrypt , kms:GenerateDataKey , and kms:DescribeKey .
Account B (Workload Account) : The IAM Role executing the operation must have an attached identity policy explicitly allowing kms:Decrypt and kms:GenerateDataKey targeting the Key ARN in Account A.
S3 Bucket Considerations : If writing cross-account to S3 with KMS encryption, the writer needs kms:GenerateDataKey on the key and s3:PutObject on the bucket. The bucket policy must permit the upload, and object ownership must be set to BucketOwnerEnforced to ensure the bucket owner can read the uploaded objects.
Envelope Encryption Deep Dive
The KMS Encrypt API accepts plaintext of up to 4,096 bytes . For symmetric ciphertext, the Decrypt API accepts a ciphertext blob of up to 6,144 bytes because the blob includes KMS metadata in addition to the encrypted plaintext. To encrypt multi-megabyte or gigabyte files (e.g., EBS volumes, S3 objects, database snapshots), AWS uses Envelope Encryption .
The Envelope Encryption Lifecycle
Key Generation : The client application calls kms:GenerateDataKey specifying the Customer Master Key (CMK) ARN and desired key spec ( AES_256 ).
KMS Response : KMS returns two representations of a newly generated symmetric key:
Plaintext Data Key : 256-bit symmetric key.
Encrypted Data Key (Ciphertext) : The data key encrypted under the CMK.
Local Payload Encryption : The application uses the Plaintext Data Key to encrypt the payload locally using an algorithm like AES-GCM or AES-CBC in memory.
Memory Purge : The application immediately zeroes out and purges the Plaintext Data Key from memory.
Storage : The application stores the Encrypted Data Key adjacent to the ciphertext (e.g., in S3 object user metadata headers or a database metadata column).
Decryption Phase : To decrypt, the application extracts the Encrypted Data Key and passes it to kms:Decrypt . KMS decrypts the data key using the CMK and returns the Plaintext Data Key. The application decrypts the data locally, then immediately wipes the plaintext key from memory. [ Application ] ──> kms:GenerateDataKey(CMK) ──> [ AWS KMS HSM ]
- │ │
- │◄── Plaintext Data Key + Encrypted Data Key ────┘
- ▼
- [ Encrypt Payload Locally with Plaintext Data Key ]
- │
- ├──> [ Zero Out Plaintext Data Key from RAM ]
- ▼
- [ Store: Payload Ciphertext + Encrypted Data Key in S3/EBS ]
- AWS Certificate Manager (ACM) & AWS Private CA
Securing data in transit requires managing SSL/TLS certificates across microservices, load balancers, and public entry points.
ACM Public Certificates: DNS vs. Email Validation
Feature DNS Validation Email Validation
Mechanism Adds a specific CNAME record containing a unique hash to the domain's DNS zone Sends automated approval emails to up to eight addresses: the three WHOIS contacts plus five common administrative mailboxes ( admin@ , administrator@ , hostmaster@ , postmaster@ , webmaster@ )
Automated Renewal Fully automated and perpetual as long as the CNAME record exists and the cert is in use Manual approval required annually via email link within a 45-day window
Automation Support Fully orchestratable via AWS Route 53 or external DNS APIs via Terraform/CloudFormation Requires manual human intervention or fragile mailbox scraping scripts
Exam Recommendation Always recommended for automated production CI/CD environments Legacy; avoid for automated infrastructure
ACM Regional Constraints
CloudFront Distributions : To attach an ACM certificate to an Amazon CloudFront distribution, the certificate must be created in the us-east-1 (N. Virginia) region .
Application Load Balancers & API Gateways : ACM certificates must be created in the same AWS Region as the load balancer or regional API Gateway.
AWS Private CA for Internal Microservices
Standard ACM public certificates are bound to integrated AWS services (ALB, CloudFront, API Gateway) and their private keys cannot be retrieved; ACM also offers an opt-in exportable public certificate option, selected at request time and separately priced, whose private key can be downloaded with a passphrase for use on EC2, on-premises, or multi-cloud hosts. For internal, non-public trust chains, AWS Private CA enables organizations to build a private hierarchical Public Key Infrastructure (PKI):
Issues private certificates with exportable private keys for internal EC2 instances, containers running on Amazon ECS/EKS, and supported service meshes (for example, Istio).
Supports mutual TLS (mTLS) authentication for zero-trust microservice architectures.
Automates renewal via IAM roles and Systems Manager agents without exposing endpoints to public internet DNS validation.
AWS CloudHSM vs. AWS KMS
Both services protect cryptographic key material with hardware security modules, but they assign control and operations differently:
Decision Point AWS KMS AWS CloudHSM
Service model Managed key service with AWS service integrations, key policies, grants, and audited API operations Dedicated single-tenant HSM instances in a customer-controlled cluster
Interfaces KMS APIs and integrated-service encryption Standard cryptographic interfaces such as PKCS #11, JCE, and Microsoft CNG
Operations AWS operates the HSM fleet; the customer manages keys, policies, and usage The customer manages cluster users, backups, high availability, client configuration, and crypto workloads
Typical choice Default for envelope encryption and AWS resource encryption Requirements for dedicated HSM control, custom cryptographic applications, or supported compliance constraints that KMS alone cannot meet
A KMS custom key store backed by CloudHSM combines KMS APIs and integrations with key material in a CloudHSM cluster that the customer controls. That extra control also adds failure modes: KMS cryptographic operations using the custom key store depend on a healthy, connected CloudHSM cluster. On the exam, do not choose CloudHSM merely because a question says “encryption”; identify a dedicated-HSM, direct-interface, or key-custody requirement that justifies its cost and operational burden.