Security
Encryption, Certificates, KMS Keys, and Cross-Account Use
CoreImplement transport, storage, client-side, server-side, certificate, key-use, cross-account, and rotation controls at the correct cryptographic boundary.
Aligned to AWS Certified Developer - Associate (DVA-C02) Version 2.1, verified August 23, 2026.
Why this matters
“Encrypt the data” is incomplete. Developers must identify whether data is moving or stored, where plaintext may exist, which principal can use the key, how trust is established, and what rotation changes.
Must Know
- Encryption in transit protects data over a connection, commonly with TLS. Encryption at rest protects stored data; many workloads require both independently.
- Server-side encryption lets the receiving AWS service encrypt data after it arrives. Client-side encryption transforms plaintext before it leaves application control.
- Envelope encryption uses a data key for application data and protects that data key with a KMS key; do not store a plaintext data key with the ciphertext.
- KMS authorization can involve IAM policies, key policies, and grants. The workload needs the required cryptographic operation on the intended key.
- Cross-account KMS use requires the key-owning account to authorize the external principal and the external account to allow the principal to call KMS.
- With an approved private CA, issue a development certificate by generating and protecting the private key, creating a certificate signing request, selecting the intended CA, template, signing algorithm, and validity, then retrieving and validating the issued certificate.
- For an EC2 development SSH need, choose a key type and private-key format supported by the target and client. EC2 can create the pair and retain the public key, or a developer can generate a pair and import only the public key; the private key must remain protected.
- KMS rotation changes key material while retaining older material needed to decrypt existing ciphertext. It does not automatically re-encrypt data or rotate a database password.
Compare and Distinguish
- At rest vs in transit: one protects persisted bytes; the other protects bytes crossing a connection.
- Client-side vs server-side encryption: the decisive boundary is where plaintext becomes ciphertext and who controls that operation.
- KMS key vs data key: a KMS key commonly protects data keys; a data key performs encryption on application data.
- Key policy/grant vs IAM permission: key-side and principal-side authorization have different scope, especially across accounts.
- TLS certificate vs SSH key pair: a certificate participates in a certificate trust chain for TLS identity; an SSH key pair authenticates an SSH principal.
- KMS rotation vs Secrets Manager rotation: KMS rotates cryptographic key material; Secrets Manager rotation updates the secret and the target service credential.
Scenario examples
- Scenario: Data must be encrypted before upload to S3. Encrypt in the client, protect the data key with KMS, and store the encrypted data key with the ciphertext.
- Scenario: A development endpoint needs a private certificate. Generate a protected private key and CSR, request an end-entity certificate from the approved private CA with the required identity and validity, retrieve it, and verify its trust chain.
- Scenario: A developer needs SSH authentication to an approved EC2 instance. Create a target-compatible key pair or import its public key, protect the only private-key copy, and use the client-compatible key format.
- Scenario: A role in another account must decrypt with a customer managed KMS key. Add the required key-side authorization and caller-side IAM permission.
- Scenario: Automatic rotation is disabled but existing ciphertext must remain readable. Retain the KMS key; disabling rotation does not erase older key material.
Exam traps
- A private subnet does not replace encryption in transit.
- Server-side encryption does not meet a requirement that plaintext never leave the application process.
- Access to ciphertext does not imply permission to use its KMS key.
- Base64 encoding, hashing, masking, and encryption solve different problems.
- Rotating a KMS key does not rotate the credential stored in Secrets Manager.
- Do not export, embed, or broadly authorize key material merely to solve an access-denied error.
Key takeaways
- Name the data state and the plaintext boundary before choosing encryption.
- Keep cryptographic key use and identity authorization coupled but conceptually separate.
- Use certificate and SSH artifacts only for their intended trust protocols.
- Authorize both sides of cross-account KMS access.
- Understand rotation consequences before enabling, disabling, or replacing keys.
How it works
- The application establishes TLS for the transport path and applies any required client-side encryption.
- A data key encrypts the payload and a KMS key protects the data key under an authorized principal context.
- The storage service can also apply supported server-side encryption for its at-rest boundary.
- KMS retains the material needed for authorized decryption across supported rotations.
When to use it
- Use TLS for protected service and client connections.
- Use client-side encryption when plaintext must not cross the client boundary.
- Use AWS KMS to control and audit supported cryptographic key operations.
- Use AWS Private CA when private certificate issuance and a managed private trust hierarchy are required.
- Use SSH keys only for an approved SSH authentication workflow.
Security and governance implications
- Grant only required KMS actions and constrain key use by principal, resource, service, and encryption context where appropriate.
- Protect private keys and plaintext data keys from source control, logs, and deployment artifacts.
- Use trusted certificate chains and validate peer identity, not merely an encrypted socket.
- Monitor key policy, rotation, disablement, and deletion changes because availability and confidentiality depend on them.
Failure signals and diagnosis
- For KMS denial, identify the key ARN, caller principal, key policy, IAM policy, grant, Region, and encryption context.
- For TLS failures, separate certificate trust, hostname, expiry, chain, endpoint support, and network reachability.
- For undecryptable data, verify the encrypted data key, KMS key state, caller authorization, and encryption context before re-encrypting anything.
- For rotation confusion, determine whether the requirement concerns KMS key material or an application credential.
More detail
- KMS key policies are a primary control over a KMS key; IAM policies and grants can participate according to the key and account path.
- Automatic and on-demand KMS rotation support depends on the key type and origin; use current documentation rather than memorizing a universal rule.
- Certificate generation requires a private key and CSR plus the intended issuer, identity, template, signing algorithm, and validity; development SSH key generation requires a target-supported key type and client-compatible format, with only the public key registered at the target.
- Encryption does not replace access control, masking, sanitization, or classification.
Ready for the quiz?
- What requirement makes client-side encryption necessary?
- What does envelope encryption store beside the ciphertext?
- Why can an IAM Allow still be insufficient for cross-account KMS use?
- How does a TLS certificate differ from an SSH key pair?
- What remains decryptable after KMS automatic rotation is disabled?
Related objectives
- D2.2 — Implement encryption by using AWS services
- 2.2.1 — Define encryption at rest and in transit
- 2.2.2 — Describe certificate management (for example, AWS Private CA)
- 2.2.3 — Describe differences between client-side encryption and server-side encryption
- 2.2.4 — Use encryption keys to encrypt or decrypt data
- 2.2.5 — Generate certificates and SSH keys for development purposes
- 2.2.6 — Use encryption across account boundaries
- 2.2.7 — Enable and disable key rotation