AWS Cloud Architect & Developer · AWS Cloud Architecture

Security, KMS and Encryption

Data protection with KMS, encryption in transit and at rest, and the shared responsibility model.

Six concepts on the SAA-C03 security pillar: where AWS's job ends and yours begins, how KMS keys and envelope encryption protect data at rest, TLS for data in motion, and where Secrets Manager beats Parameter Store.

AWS Cloud Architect & Developer
Hard level
6 concepts
5 practice questions

1Shared responsibility model

AWS is responsible for security of the cloud — the physical data centres, the hardware, the hypervisor and the managed-service infrastructure underneath RDS or Lambda. You are responsible for security in the cloud — your data, IAM policies, network configuration, guest-OS patching on EC2, and the choice to turn encryption on. The exam phrasing is fixed: match the wording exactly, because distractors swap the two halves.

The dividing line moves with the service model. On EC2 you patch the guest OS; on RDS AWS patches the host OS while you manage database users and security groups. On S3 AWS runs the storage fleet; you choose bucket policies, block public access, and pick SSE-S3 or SSE-KMS. Map the task to who controls the layer, not who you wish were responsible.

Figure. AWS secures the cloud; you secure what you put in it — the line moves up the stack for managed services.

How it works

Name the layerIdentify whether the task touches physical infrastructure, the hypervisor, the managed service, or something you configure above that line.
Draw the lineHardware, facilities and the hypervisor sit on AWS's side; data classification, IAM, encryption settings and guest-OS maintenance sit on yours.
Apply to the serviceEC2 pushes OS patching to you; RDS and Lambda push it to AWS. Encryption of your objects is always your configuration choice even when AWS provides the keys.

Who owns which task
Task	AWS (of the cloud)	Customer (in the cloud)
Physical data-centre access	Yes	No
Hypervisor and host patching for managed services	Yes	No
Guest OS patching on EC2	No	Yes
IAM users, roles and resource policies	No	Yes
Choosing to encrypt S3 objects and which key to use	No	Yes

On an EC2 instance you launched, who is responsible for installing security patches on the guest operating system?

AWS, because it runs the data centre
The customer, under security in the cloud
AWS, because it maintains the hypervisor

EC2 is infrastructure as a service: AWS secures the hardware and hypervisor, but guest-OS patching is explicitly the customer's job. Choosing AWS because it runs the data centre confuses security of the cloud with security in the cloud; hypervisor patching is AWS's work, not guest-OS patching.

2KMS key types and control

AWS Key Management Service holds symmetric and asymmetric keys and integrates with S3, EBS, RDS, Secrets Manager and dozens of other services. A customer-managed key (CMK) is a KMS key you create, whose key policy and IAM grants you edit, and whose automatic yearly rotation you enable. An AWS-managed key is created automatically for a service — aws/s3 when you choose SSE-KMS with the AWS-managed key, aws/ebs for volumes — and you cannot edit its policy or disable it. That aws/s3 key is not S3's default encryption: new objects default to SSE-S3 with S3-managed keys, which never touch KMS. CloudTrail logs Encrypt, Decrypt and GenerateDataKey against both KMS key types; the CMK advantage is that you control the key policy, cross-account grants and rotation schedule.

The exam trap is control versus convenience: choose a CMK when compliance needs an editable key policy, cross-account access or your own rotation schedule; accept an AWS-managed key when you only need KMS encryption with minimal overhead. For imported key material or a hardware boundary, CloudHSM sits beside KMS — keys never leave the HSM — but ordinary SAA questions stop at CMK versus AWS-managed.

Figure. Customer-managed CMKs give rotation/policy control; AWS-managed and AWS-owned reduce ops with less control.

How it works

Create or inheritYou create a CMK in KMS, or AWS creates an aws/service-name key the first time a service uses SSE-KMS (or the service's KMS integration) on your behalf — not when S3 applies default SSE-S3.
Attach policyA CMK's key policy names who can administer the key and who can use it; AWS-managed keys ship with a fixed policy you cannot change.
Rotate and auditEnable automatic rotation on a CMK and KMS rotates the backing material every 365 days while keeping the same key ID. CloudTrail logs cryptographic API calls for both CMKs and AWS-managed keys; only the CMK lets you tighten the key policy around that audit trail.

CMK versus AWS-managed key
Property	Customer-managed CMK	AWS-managed key
Who creates it	You	AWS, on first use
Key policy editable	Yes	No
Automatic yearly rotation	Optional, you enable it	AWS handles it
Per-request CloudTrail audit	Yes — KMS API calls logged; you control the key policy	Yes — KMS API calls logged; key policy is not editable
Cross-account sharing via key policy	Yes	No

A regulated workload must encrypt S3 data with a key whose policy the security team edits and that supports cross-account grants. Which key type fits?

The aws/s3 AWS-managed KMS key used with SSE-KMS
A customer-managed CMK
An IAM user access key stored in Parameter Store

Only a CMK gives you an editable key policy and cross-account sharing. The aws/s3 AWS-managed key also logs KMS calls in CloudTrail when you use SSE-KMS, but you cannot edit its policy or share it across accounts. An IAM access key is not an encryption key at all.

3Envelope encryption

Large objects on S3 or EBS are not encrypted with the customer master key (CMK) directly — shipping every byte through KMS would throttle and cost. Instead you call KMS GenerateDataKey: KMS returns a one-time 256-bit plaintext data key and the same key encrypted under your CMK. Your application encrypts the object locally with AES-256 using the plaintext data key, then discards that plaintext and stores only the ciphertext plus the encrypted data key beside the object.

The exam trap is persistence: the plaintext data key exists only in memory for the duration of the encrypt call and must never be written to disk. What survives is the encrypted object and the encrypted data key — two blobs, neither of which is the CMK itself.

Figure. Two outputs leave GenerateDataKey: a plaintext data key you use once in memory, and an encrypted copy KMS wrapped under the CMK. Only the encrypted object and the encrypted data key are written — the plaintext branch ends at discard.

How it works

GenerateCall KMS GenerateDataKey against your CMK; KMS returns a 256-bit plaintext data key and the same key encrypted under the CMK.
Encrypt locallyUse the plaintext data key with AES-256 to encrypt the object on your side — S3, EBS, or your app — without sending the object through KMS.
Store the envelopeDiscard the plaintext data key from memory and persist only the encrypted object plus the encrypted data key as metadata beside it.
Decrypt laterTo read back, pass the encrypted data key to KMS Decrypt; KMS returns a fresh plaintext data key under IAM and key policy, you decrypt the object, then discard the plaintext again.

After envelope encrypting a 10 GB S3 object with SSE-KMS, which material is stored alongside the ciphertext?

The CMK itself, so decrypt can run without calling KMS
The plaintext data key, encrypted again with a second CMK
The encrypted data key only — the plaintext key lived in memory and was discarded

Envelope encryption never persists the plaintext data key. KMS wraps a one-time data key under your CMK; you encrypt the object locally, throw away the plaintext, and store the encrypted data key with the object. Decrypt later means KMS unwraps that encrypted data key on demand — the CMK itself never leaves KMS.

4Encryption at rest on S3

Encryption at rest protects stored bytes on S3, EBS and RDS so a leaked disk or misconfigured bucket still yields ciphertext. Every new S3 object is encrypted by default with SSE-S3 (AES-256 keys owned entirely by AWS — not the aws/s3 KMS key). SSE-KMS uses a KMS key — AWS-managed aws/s3 or your CMK — and logs each cryptographic operation in CloudTrail, which is what auditors ask for. SSE-C lets you supply your own key on every request; AWS never stores it. Client-side encryption means you encrypt before upload and you alone hold the key.

The exam trap is picking SSE-S3 when the stem mentions audit, compliance or a specific CMK — SSE-S3 encrypts silently with no per-object KMS trail. Reach for SSE-KMS when audit is named; reach for a customer-managed CMK when the stem also needs an editable key policy, cross-account grants or a named key you control.

Figure. With SSE-KMS every upload triggers a KMS call; CloudTrail records which KMS key wrapped the data key (aws/s3 or a CMK). SSE-S3 skips the KMS node entirely.

How it works

Default on uploadS3 applies bucket default encryption — SSE-S3 unless you override — on every new object without a client-side call.
Upgrade for auditSet the bucket default to SSE-KMS (aws/s3 or your CMK), or pass x-amz-server-side-encryption: aws:kms on a PutObject — both paths create a KMS CloudTrail trail.
Verify in CloudTrailKMS logs Encrypt and GenerateDataKey against the key in use (aws/s3 or your CMK); combine with S3 server access logs for a full object-and-key trail.

S3 server-side encryption modes
Mode	Who holds the key	Audit trail	Typical exam cue
SSE-S3	AWS	None per object	Default encryption, no compliance keyword
SSE-KMS	KMS CMK or AWS-managed	CloudTrail on KMS API calls	Audit/compliance → SSE-KMS; editable key policy → CMK
SSE-C	You, per request	Your responsibility	Customer-provided key material
Client-side	You, off AWS	Your responsibility	Encrypt before upload

A security team must prove which KMS key encrypted each object and must edit that key's policy. Which default encryption setting satisfies that?

SSE-S3 with AES-256
SSE-KMS with a customer-managed CMK
SSE-C with a key uploaded once to KMS

SSE-KMS routes each encrypt through KMS so CloudTrail logs the key used; a customer-managed CMK also gives an editable key policy. SSE-S3 uses S3-managed keys with no KMS audit. SSE-KMS with aws/s3 would audit but not let the team edit the key policy. SSE-C means you supply the key on every request and AWS never stores it — it does not produce the KMS audit-plus-policy control the stem asks for.

5Encryption in transit

Encryption in transit protects bytes while they move — browser to load balancer, service to service inside a VPC, or client to S3 over HTTPS. TLS (still called SSL in exam stems) negotiates a session key, presents a certificate proving the server's identity, and encrypts the channel. AWS enforces TLS on public endpoints: S3, API Gateway and CloudFront expect HTTPS; you terminate TLS on an ALB or CloudFront distribution with an ACM certificate.

At rest and in transit are independent switches — an encrypted S3 bucket still needs HTTPS on download, and TLS on an ALB does not encrypt the EBS volume underneath. Exam questions that say data must be protected end-to-end need both.

Figure. In-transit protection is TLS (or equivalent) on the wire — separate from at-rest KMS/SSE on stored bytes.

How it works

Terminate TLSAttach an ACM certificate to the ALB, CloudFront distribution or API Gateway stage so clients connect over HTTPS.
Force HTTPSRedirect HTTP to HTTPS and set S3 bucket policies or CloudFront viewer policies to reject plain HTTP.
Layer with at-restTLS covers the wire; SSE-KMS or SSE-S3 covers the stored object — compliance stems often require both.

A web app must protect user credentials while they travel from the browser to an Application Load Balancer. Which control applies?

Enable SSE-KMS on the S3 bucket holding static assets
Terminate TLS on the ALB with an ACM certificate
Enable automatic rotation in Secrets Manager

Credentials in flight need encryption in transit — TLS on the ALB. SSE-KMS protects objects already stored in S3, not bytes on the network. Secrets Manager rotation protects stored credentials, not the HTTP session carrying them.

6Secrets Manager versus Parameter Store

Never hardcode database passwords or API keys in source. AWS Secrets Manager stores credentials as encrypted secret strings — always wrapped by a KMS key — and can rotate them automatically on a schedule using a Lambda rotation function; RDS, Redshift and DocumentDB ship ready-made rotation templates. Systems Manager Parameter Store also holds configuration and secrets, encrypting SecureString parameters with KMS, but it has no built-in rotation — you would build and schedule that yourself.

The exam keyword is automatic rotation: if the stem says credentials must rotate every 30 days with no application redeploy, choose Secrets Manager. Parameter Store fits static config, feature flags and secrets you rotate manually or rarely.

Figure. Secrets Manager is built for rotating credentials; Parameter Store is hierarchical config with optional encryption.

How it works

Store centrallyCreate a Secrets Manager secret or a Parameter Store SecureString; both encrypt with KMS at rest.
Fetch at runtimeThe application's IAM role calls GetSecretValue or GetParameter instead of reading environment variables baked into the image.
Rotate on scheduleIn Secrets Manager enable rotation — e.g. every 30 days with the RDS template — so the database password updates and the secret version changes without a redeploy.

Secrets Manager versus Parameter Store
Capability	Secrets Manager	Parameter Store (SecureString)
KMS encryption at rest	Yes	Yes
Built-in automatic rotation	Yes, with Lambda templates	No — build your own
Native RDS credential rotation	Yes	No
Cost model	Per secret per month	Standard tier free for many use cases
Best exam cue	Automatic credential rotation	Static config and non-rotating secrets

An RDS-backed app must fetch its database password from AWS and rotate it automatically every 30 days without redeploying code. Which service fits?

Systems Manager Parameter Store (SecureString)
AWS Secrets Manager with RDS rotation enabled
AWS KMS with a customer-managed CMK

Secrets Manager stores the credential, integrates with RDS, and rotates on a schedule via Lambda. Parameter Store can hold a SecureString but lacks built-in rotation. KMS manages encryption keys, not application passwords.

Notes

Shared Responsibility Model: AWS secures the cloud (hardware, facilities, managed service infrastructure); the customer secures what is in the cloud (data, IAM, OS patching, encryption config).
KMS Keys: AWS KMS manages symmetric and asymmetric keys; a customer-managed key (CMK) allows control over rotation, policies, and grants, while AWS-managed keys are simpler but less controllable.
Envelope Encryption: KMS encrypts a data key that then encrypts the actual data; the plaintext data key is never stored, only the encrypted version alongside the data.
Encryption in Transit vs at Rest: TLS/SSL protects data in transit; SSE-S3, SSE-KMS, or client-side encryption protect data at rest.
Secrets Management: Secrets Manager stores and automatically rotates credentials/API keys; Parameter Store holds configuration and secrets, integrating with KMS for encryption.

Formulas

KMS automatic rotation: customer-managed symmetric keys rotate yearly (365 days) when enabled.
KMS request throttling: default 5,500-10,000+ cryptographic requests/sec per Region depending on operation (raiseable).
KMS data key size: generates 256-bit (AES-256) symmetric data keys for envelope encryption.
Secrets Manager rotation: supports scheduled automatic rotation via Lambda (e.g., every 30 days).
S3 default encryption: all new objects are encrypted at rest with SSE-S3 (AES-256) by default.

Exam traps & shortcuts

If the question needs automatic credential rotation, choose Secrets Manager, not Parameter Store (which lacks built-in rotation).
For full control over key rotation and cross-account key policies, choose a customer-managed KMS key over an AWS-managed key.
Map responsibilities: patching the guest OS is the customer's job; patching the RDS/Lambda underlying host is AWS's job.
For compliance requiring your own key material or a hardware boundary, consider KMS with imported key material or CloudHSM.

Reference tables

When the stem uses one of these phrases, the answer is usually fixed.

Exam keyword map
Stem keyword	Reach for
Security of the cloud vs in the cloud	Shared responsibility table — match the layer
Manage encryption keys / KMS	KMS — CMK if editable policy, cross-account or rotation control is named (audit alone is not the differentiator)
Encrypt data at rest / compliance audit	SSE-KMS (aws/s3 or CMK); CMK when key policy or a named key is required
Data in transit / HTTPS	TLS on ALB, CloudFront or API Gateway with ACM
Automatically rotate credentials	Secrets Manager, not Parameter Store
Imported key material / hardware boundary	CloudHSM beside KMS

Recap

Read this before an SAA security drill.

Responsibility: AWS: security of the cloud — hardware, hypervisor, managed-service host. You: security in the cloud — data, IAM, guest OS on EC2, encryption settings.
KMS keys: CMK when you need editable key policy, cross-account access or your rotation schedule. AWS-managed keys also log in CloudTrail but you cannot edit their policy.
Envelope: GenerateDataKey returns a plaintext data key and an encrypted copy. Encrypt locally, discard the plaintext, store only the envelope.
At rest: SSE-S3 is default and silent. Audit → SSE-KMS (aws/s3 or CMK); editable key policy or named key → CMK. TLS does not replace either.
In transit: TLS with ACM on the load balancer or CloudFront. At rest and in transit are separate toggles — compliance wants both.
Secrets: Automatic rotation keyword → Secrets Manager. Parameter Store for static SecureStrings without built-in rotation.

Practise Security, KMS and Encryption

Reading is free and needs no account. Practice, mocks and progress live in the app.

5 exam-style questions on this topic, with explanations
A 6-question practice set that ends the chapter
Timed mocks scored with the real marking scheme
Readiness tracked per topic, kept on your device

Continue with Google — freeNo card, no trial. Works offline once installed.