KMS Encryption, S3/Redshift Encryption, and Secrets Manager

KMS encryption and Secrets Manager are the foundation of every production data pipeline that handles sensitive data, and on the DEA-C01 exam Domain 4 Tasks 4.3 and 4.4 plant questions in roughly one out of every six scenarios that test whether the candidate knows how to encrypt at rest, encrypt in transit, manage credentials, and avoid the canonical KMS key policy traps. The trap is rarely about whether to encrypt — it is about choosing between SSE-S3, SSE-KMS, and DSSE-KMS, configuring KMS key policies that allow Glue and Redshift service principals correctly, deciding between Secrets Manager and Parameter Store for pipeline credentials, and avoiding the high KMS API bill that comes from skipping S3 Bucket Keys.

This guide covers KMS encryption and Secrets Manager through the Data Engineer / MLOps lens — what KMS keys exist and how they bill, S3 server-side encryption options and their trade-offs, Redshift cluster encryption, Glue security configurations for ETL job artifacts, Kinesis Data Streams encryption, TLS enforcement on Redshift connections, Secrets Manager versus Parameter Store, automatic rotation Lambdas for RDS and Redshift, KMS key policy patterns for cross-service access, and the canonical exam traps planted around bucket key cost optimization, default-encryption surprises, and rotation Lambda mechanics.

Encryption At Rest vs Encryption In Transit — Two Distinct Controls

Before talking about KMS, separate the two encryption concerns.

Encryption At Rest

Data sitting on disk in S3, EBS, RDS, Redshift, Kinesis stream payloads, DynamoDB tables, Glue ETL job temp storage. Encryption at rest is the protection against someone who steals the physical disk or reads the underlying storage layer. AWS storage services support encryption at rest via service-managed keys or customer-managed KMS keys.

Encryption In Transit

Data flowing over the network — client to S3, ETL job to Redshift, Kinesis producer to stream. Encryption in transit is the protection against network interception. AWS endpoints support TLS by default; the data engineer's job is to enforce TLS-only connections, configure VPC endpoints, and reject HTTP requests at the bucket policy or cluster parameter group level.

Why DEA-C01 Tests Both

The exam plants scenarios where a candidate enables encryption at rest but the data still leaks because the connection was unencrypted. Both controls are required for sensitive data; neither is sufficient alone.

AWS KMS Key Types And Hierarchy

KMS is the central service for encryption keys on AWS. The DEA-C01 exam expects fluency in the key types and the envelope encryption pattern.

AWS-Managed Keys

AWS-managed keys (formerly "AWS-managed CMKs") are KMS keys created and managed by AWS on your behalf — aws/s3, aws/redshift, aws/glue, aws/secretsmanager. You cannot rotate them on your own schedule, you cannot edit their key policy, and you cannot delete them. Free to use; key usage incurs only the per-API-call cost.

Customer-Managed Keys (CMK)

Customer-managed keys are KMS keys you create, control, and manage. You choose the key policy (who can use it), enable annual rotation, set up cross-account access, and delete with a 7-30 day waiting period. CMKs cost $1/month per key plus per-API-call costs. The DEA-C01 trap: candidates who default to AWS-managed keys for production miss that CMKs are required for cross-account access, custom key policies, and audit-grade rotation control.

AWS-Owned Keys

AWS-owned keys are used by AWS services for internal encryption — invisible to you, no cost, no control. DynamoDB defaults to AWS-owned keys for encryption at rest unless you explicitly choose SSE-KMS with a CMK.

Symmetric vs Asymmetric Keys

KMS supports symmetric keys (AES-256, the default for data encryption) and asymmetric keys (RSA, ECC for digital signing). Data engineering workloads almost always use symmetric keys; asymmetric keys are for signing scenarios that DEA-C01 rarely tests.

Multi-Region Keys

Multi-Region Keys are KMS keys that exist in multiple regions with the same key material, allowing decrypting in one region of data encrypted in another. Use cases: cross-region replication of S3 SSE-KMS data, DynamoDB Global Tables with encryption. The exam may plant this as the right answer for "DR pattern with encrypted data."

Envelope Encryption

KMS uses envelope encryption: the data is encrypted with a data encryption key (DEK), the DEK is encrypted by the KMS key, and the encrypted DEK is stored alongside the data. To decrypt, the encrypted DEK is sent to KMS for decryption, then the cleartext DEK decrypts the data locally. This pattern lets KMS handle billions of bytes of data with one API call per ~64KB encryption operation, not per byte.

S3 Server-Side Encryption — The Five Options

S3 supports five encryption options. The DEA-C01 exam tests every choice.

SSE-S3 — S3-Managed Keys

S3 generates and manages the encryption keys. Free, simple, no KMS interaction, no fine-grained control. Default for new buckets since January 2023. Right answer when: encryption is required for compliance but no cross-account or customer-key requirement exists.

SSE-KMS — KMS-Managed Keys

S3 uses a KMS key (AWS-managed or customer-managed) to encrypt data. Adds key access logging via CloudTrail, supports cross-account access via KMS key policy, supports key rotation. Costs more per request because every PUT and GET hits KMS unless Bucket Keys are enabled. Right answer when: regulated data, audit logging of decryption, or cross-account scenarios.

DSSE-KMS — Double Server-Side Encryption

DSSE-KMS encrypts data twice with two independent layers — designed for FedRAMP High and other workloads requiring layered cryptographic controls. Higher latency and cost. Right answer when: regulatory mandate explicitly requires double encryption.

SSE-C — Customer-Provided Keys

The client sends the encryption key on every PUT and GET; AWS uses it to encrypt and discards it. AWS never stores the key, so if the client loses the key, the data is unrecoverable. Use case: workloads that must keep keys off AWS. Rarely the right DEA-C01 answer; CSE-KMS or SSE-KMS is more typical.

CSE — Client-Side Encryption

The client encrypts data before sending to S3; S3 stores ciphertext only. The encryption key may come from KMS (CSE-KMS) or be customer-supplied (CSE-C). Use case: workloads that require encryption to happen on the client side, often for end-to-end encryption guarantees. The DEA-C01 exam plants CSE-KMS as the right answer for "encrypt sensitive data before upload."

Default Bucket Encryption And Bucket Keys

S3 supports default bucket encryption — every PUT to the bucket is encrypted with the configured option even if the client did not specify. For SSE-KMS, enable S3 Bucket Keys to cache one DEK per bucket per day, dramatically reducing per-object KMS API calls. Bucket Keys can reduce KMS costs by 99 percent on high-volume buckets.

Redshift Encryption At Rest

Redshift encryption is configured at cluster creation and cannot easily be changed afterward.

Cluster-Level Encryption

When creating a Redshift cluster, choose encryption with KMS (AWS-managed or CMK) or HSM. The cluster encrypts all data at rest — disk blocks, backups, automated snapshots. Encryption uses a hierarchical key model: cluster key → database key → table key → block key. Only the cluster key is in KMS; the rest are managed by Redshift internally.

Re-Encrypting An Existing Cluster

If you change encryption settings on an existing cluster, Redshift creates a new cluster, copies data, and switches DNS — a multi-hour to multi-day operation depending on cluster size. Cannot be done in place. The DEA-C01 trap: scenarios that suggest "enable encryption on an existing cluster" without acknowledging the downtime cost.

Snapshot Encryption

Manual and automated snapshots inherit cluster encryption. Cross-region snapshot copies use a separate KMS key in the destination region — for cross-region DR with encryption, set up a destination KMS key and configure snapshot copy with that key.

Spectrum And External Tables

Redshift Spectrum reads S3 data; the underlying S3 encryption (SSE-KMS, SSE-S3) governs scan-time decryption. The Spectrum role needs kms:Decrypt on the data's KMS key.

Redshift Serverless

Redshift Serverless uses encryption by default (cannot be disabled). You can choose AWS-managed keys or a CMK. Same key-rotation behavior as provisioned.

Glue Security Configurations

A Glue Security Configuration is a reusable bundle of encryption settings applied to Glue ETL jobs.

What It Encrypts

A security configuration covers three things: S3 outputs (encrypts data Glue writes to S3 targets), CloudWatch logs (encrypts the job's log group), and job bookmarks (encrypts the bookmark state stored by Glue). Each can be configured with SSE-S3, SSE-KMS, or disabled.

Why It Matters

Without a security configuration, a Glue ETL job that writes to a curated S3 zone may write unencrypted objects (or use SSE-S3 by default), and the CloudWatch log group may store unencrypted logs containing sensitive data. The security configuration enforces consistent encryption across the job's outputs.

Attaching To A Job

When creating a Glue ETL job, choose a security configuration. The job applies the configuration to all outputs without per-statement encryption parameters. The DEA-C01 exam plants this as the right answer for "Glue ETL writes must be encrypted with a customer-managed key."

KMS Permissions Required

The Glue job's IAM role must have kms:Encrypt, kms:Decrypt, kms:GenerateDataKey on the KMS key. The KMS key policy must also grant the role access — both directions of the trust relationship are required.

Kinesis Data Streams Encryption

Kinesis Data Streams supports server-side encryption with KMS to encrypt stream payloads at rest.

How It Works

Each record written to the stream is encrypted with a data key derived from the configured KMS key. Consumers automatically decrypt records on read if they have kms:Decrypt on the key. Encryption is transparent to producer and consumer code; only the IAM permissions on the KMS key are required.

Default vs Customer-Managed

Streams support an AWS-managed key (aws/kinesis) for free or a customer-managed key for cross-account or audit-grade scenarios. The DEA-C01 exam plants CMK as the right answer when "auditable key access" or "cross-account stream sharing" is in the scenario.

Cost

Server-side encryption on Kinesis streams adds a small cost per shard-hour and per KMS API call. For high-throughput streams, consider whether the data sensitivity warrants it; for unsensitive aggregated metrics, plain streams may be sufficient.

Encryption In Transit — TLS Enforcement

Every AWS endpoint supports TLS by default; the engineer's job is to enforce TLS-only.

S3 Bucket Policy For TLS-Only

Add a Deny statement on the bucket policy with condition aws:SecureTransport=false. The denies any plain-HTTP request and forces TLS:

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": ["arn:aws:s3:::bucket/*", "arn:aws:s3:::bucket"],
  "Condition": {"Bool": {"aws:SecureTransport": "false"}}
}

The DEA-C01 exam plants TLS-only S3 as a Domain 4 staple.

Redshift TLS Enforcement

Set the require_ssl parameter on the cluster parameter group to true. Connections without SSL are rejected. JDBC and ODBC clients must specify ssl=true and trust the Redshift CA bundle.

VPC Endpoints For Private Connectivity

VPC endpoints (Gateway for S3 and DynamoDB; Interface for everything else) keep traffic on the AWS backbone, never traversing the public internet. Combined with TLS, this is the defense-in-depth pattern for sensitive data engineering pipelines.

Glue And Redshift VPC Configuration

Glue ETL jobs and Redshift clusters can be configured with VPC connections that route through VPC endpoints, keeping data flow private. The DEA-C01 exam plants this as the right answer for "ETL job must not traverse the public internet."

AWS Secrets Manager — Credentials And Rotation

Secrets Manager stores and rotates database credentials, API keys, and connection strings used by data pipelines.

What It Stores

Database credentials (username + password), API keys, OAuth tokens, arbitrary JSON or text secrets up to 64 KB. Secrets are encrypted at rest with KMS (AWS-managed or CMK) and accessed via API.

Automatic Rotation

The headline feature: Secrets Manager can rotate credentials on a schedule (e.g., every 30 days) by invoking a Lambda function. AWS provides pre-built rotation Lambdas for RDS MySQL, RDS PostgreSQL, Aurora, Redshift, DocumentDB. For other secrets you write a custom Lambda. The rotation Lambda is the heart of the feature — without it, Secrets Manager is just a fancier Parameter Store.

How RDS Rotation Works

The rotation Lambda creates a new password, updates the database to accept the new password, updates the secret to the new value, and tests the new credential. The four-step pattern (createSecret, setSecret, testSecret, finishSecret) prevents the application from seeing a broken credential during rotation.

Cross-Account Access

A secret in account A can be accessed by a role in account B if the resource policy on the secret and the KMS key policy both allow it. The DEA-C01 exam plants this for centralized credential management scenarios.

Cost

Secrets Manager bills $0.40 per secret per month plus $0.05 per 10,000 API calls. Higher than Parameter Store but the rotation feature justifies it for production database credentials.

Secrets Manager vs Systems Manager Parameter Store

Two services that look similar; the DEA-C01 exam tests when each is appropriate.

Secrets Manager

Cost: $0.40/secret/month + API calls. Auto-rotation: yes, via Lambda. Cross-region replication: yes. Designed for: database credentials, API keys requiring rotation, cross-account secret sharing. Encryption: always with KMS.

Parameter Store (Standard)

Cost: free for standard parameters. Auto-rotation: no. Cross-region replication: manual. Designed for: configuration values, non-rotating secrets, application config. Encryption: optional with KMS via SecureString.

Parameter Store (Advanced)

Cost: $0.05/parameter/month. Higher limits (8KB value, 100K parameters per account), parameter policies (expiration, no-change notifications). Still no native rotation.

Decision Rule

If the secret needs rotation, Secrets Manager. If the secret is static config or a non-rotating value, Parameter Store with SecureString. If the workload has thousands of parameters at scale, Parameter Store wins on cost. The DEA-C01 exam plants this as a cost-versus-feature trade-off — the right answer for production database credentials is always Secrets Manager.

KMS Key Policies — The Cross-Service Trap

KMS key policies control who can use the key. Misconfigured policies cause silent failures across data pipelines.

Key Policy Structure

A KMS key policy is a JSON document attached to the key (similar to an S3 bucket policy). It controls which principals can perform key operations — kms:Encrypt, kms:Decrypt, kms:GenerateDataKey. Without a key policy grant, even an IAM identity-based policy granting KMS access does NOT work — KMS keys require explicit key-policy permission unless kms:ViaService allows it.

Service Principals In Key Policies

To let Glue, S3, Redshift, or Kinesis use the key on a user's behalf, the key policy must grant the service principal access — glue.amazonaws.com, s3.amazonaws.com, redshift.amazonaws.com. The DEA-C01 trap: a Glue ETL job fails to write to an SSE-KMS bucket because the bucket's KMS key policy does not grant the Glue service principal kms:Decrypt and kms:GenerateDataKey.

Cross-Account Key Access

Sharing a KMS key with another account requires (1) the key policy in the producer account grants the consumer account principal, AND (2) the consumer account's IAM identity policy grants the same. Both must allow.

Default Key Policy

When you create a CMK via the console, the default key policy grants the AWS account root access plus delegating to IAM identity policies. This means any IAM principal in the account with kms:Decrypt permission can use the key. For tighter control, write a custom key policy that explicitly enumerates allowed principals.

Plain-Language Explanation: KMS Encryption And Secrets Manager

Three concrete analogies make the encryption story intuitive.

Analogy 1 — The Bank Vault With Master Keys And Daily Combinations

KMS is the bank's master vault that holds all the master keys (KMS keys) — the master keys never leave the vault, but they can stamp out daily combinations (data encryption keys / DEKs) that the tellers use to lock individual safety deposit boxes. Envelope encryption is exactly this pattern: the data is locked with a daily combination, the daily combination is locked by the master key, and to unlock the data you bring the encrypted daily combination to the vault, the vault decrypts it, and you use the cleartext combination locally. AWS-managed keys are master keys the bank chose for you — convenient but you cannot inspect them. Customer-managed keys are master keys you commissioned — you control access, you set rotation, you delete with a waiting period. S3 Bucket Keys are when the teller batches a thousand boxes under one daily combination instead of stamping a fresh combination per box, dramatically reducing the master-vault visit rate (and bill). Secrets Manager is the bank's automated password-changer — every 30 days a robot generates a new password for your database, updates the database to accept it, tests the new password, and rotates the secret value, all without you intervening. Parameter Store is the bank's general-purpose safe-deposit-box for non-rotating items like documents and configs.

Analogy 2 — The Postal System With Tamper-Evident Envelopes And Lock-Box Keys

KMS keys are the lock-box keys at the postal facility. Every piece of sensitive mail is sealed in a tamper-evident envelope locked with a daily lock-and-key combination (data key); the daily combination itself is locked away in a master key cabinet (KMS key). When mail arrives at the destination, the recipient brings the locked envelope to the post office, the master key cabinet unlocks the daily combination, the daily combination unlocks the envelope, and the recipient reads the contents. SSE-S3 is the postal service handling the entire lock-and-key scheme transparently, including the master key — convenient and free but you cannot audit who unlocked anything. SSE-KMS is the postal service handling daily combinations but you control the master key cabinet — every unlock is audited, you can revoke access, and you can delete the master key (after a waiting period) which permanently destroys all encrypted mail. SSE-C is when you bring your own daily combination to every transaction, and if you lose it the mail is permanently lost. CSE is when you lock the envelope yourself before handing it to the post office. Secrets Manager is the postal facility's tenant key system — every 30 days the facility generates new tenant keys for your mailboxes, distributes them, and invalidates the old ones, automatically.

Analogy 3 — The Theme Park With Wristbands, Locker Keys, And Daily Reset

KMS keys are the master locker keys at a theme park. You rent a locker (S3 object), the park gives you a daily wristband (DEK) that opens the locker, and the wristband itself is encoded by the park's master ring (KMS key). Many rentals can share one wristband (S3 Bucket Key) to reduce the master-ring authentication rate at the gate. AWS-managed keys are the park's standard master rings; customer-managed keys are corporate rings the company commissioned with custom branding and audit logs. DSSE-KMS is the high-security wing where lockers are double-locked with two independent ring systems for FedRAMP-grade compliance. Redshift cluster encryption is the park's locker hierarchy — your individual locker key is locked by a section key, the section key by a row key, the row key by the master ring, all managed inside the park's lock infrastructure with only the master ring exposed to KMS. Secrets Manager is the daily wristband refresh system — every morning a robot generates new wristbands for your group, the park's gate readers accept the new ones, and the old ones are deactivated, all without you visiting the desk. Parameter Store is the basic info-board where you post non-secret notices like "meeting at noon" — free and accessible but no rotation.

Common Exam Traps For KMS And Secrets Manager

Memorize all five.

Trap 1 — KMS API Cost Explosion Without Bucket Keys

A scenario describes a high-volume SSE-KMS bucket with unexpectedly high KMS bills. Wrong answer: switch to SSE-S3 (loses KMS audit logs). Right answer: enable S3 Bucket Keys to reuse one DEK per bucket per day, reducing KMS calls by 99 percent.

Trap 2 — IAM Role Policy Without KMS Key Policy

A scenario describes a Glue ETL job that has kms:Decrypt in its role but cannot read SSE-KMS data. Wrong answer: broaden the role policy. Right answer: add the Glue service principal (or the role ARN) to the KMS key policy.

Trap 3 — Parameter Store For Rotating Database Credentials

A scenario describes RDS database credentials that need 30-day rotation. Wrong answer: Parameter Store SecureString. Right answer: Secrets Manager with the AWS-provided RDS rotation Lambda.

Trap 4 — Default Encryption On New Buckets

A scenario describes objects appearing unencrypted in a bucket. Since January 2023, S3 defaults to SSE-S3 on new buckets — but older buckets may not have default encryption. Right answer: explicitly configure default bucket encryption to SSE-KMS with a CMK.

Trap 5 — In-Place Re-Encryption Of Redshift Cluster

A scenario asks to "enable encryption on an existing Redshift cluster overnight." Wrong answer: change the encryption setting in place. Right answer: Redshift creates a new cluster, copies data, and switches DNS — a multi-hour to multi-day operation, not overnight on a large cluster.

Key Numbers And Must-Memorize Facts

KMS

• $1/month per customer-managed key
• $0.03 per 10,000 KMS API calls
• 64KB max plaintext per encrypt operation
• Annual automatic rotation (CMK only)
• 7-30 day deletion waiting period
• Symmetric (AES-256) and asymmetric (RSA, ECC) key types

S3 Encryption

• SSE-S3: free, S3-managed, default since Jan 2023
• SSE-KMS: per-API-call cost, audit logs, cross-account
• DSSE-KMS: double encryption for FedRAMP High
• SSE-C: customer-provided keys, AWS does not store
• CSE-KMS / CSE-C: client-side, ciphertext-only in S3
• S3 Bucket Keys: 99% reduction in KMS API calls

Redshift Encryption

• Cluster-level KMS encryption at create time
• Re-encryption requires cluster recreation
• Snapshots inherit cluster encryption
• Cross-region snapshot copy needs separate destination key
• Serverless: encrypted by default, cannot disable

Secrets Manager

• $0.40/secret/month + $0.05/10K API calls
• 64KB max secret size
• AWS-provided rotation Lambdas: RDS MySQL/PostgreSQL/Aurora/Redshift/DocumentDB
• Custom Lambda required for non-AWS-managed secrets
• Four-step rotation: createSecret, setSecret, testSecret, finishSecret

Parameter Store

• Standard: free, 4KB value, no rotation
• Advanced: $0.05/parameter/month, 8KB value, parameter policies
• SecureString: KMS-encrypted parameter value

FAQ — KMS Encryption And Secrets Manager Top Questions

Q1 — When should I use SSE-S3, SSE-KMS, or DSSE-KMS for an S3 bucket?

Use SSE-S3 when encryption is required for compliance but you do not need KMS audit logs, cross-account access, or customer key control — it is free, simple, and now the default for new buckets. Use SSE-KMS when you need decryption logs in CloudTrail (regulated workloads), cross-account access (data sharing patterns), or customer-managed keys for key rotation control. Use DSSE-KMS only when a regulatory mandate explicitly requires double-layer encryption (FedRAMP High, certain healthcare or financial workloads). For SSE-KMS at scale, always enable S3 Bucket Keys to avoid KMS cost explosion. The DEA-C01 exam plants SSE-KMS with Bucket Keys as the right answer for "encrypted data lake with audit and cost control."

Q2 — Why does my Glue ETL job fail to write to an SSE-KMS bucket even though the role has kms:Decrypt?

Because KMS keys require BOTH IAM identity policy and KMS key policy permission. The Glue ETL job's IAM role has kms:Decrypt in its identity policy, which is necessary but not sufficient. The KMS key policy must also grant access — either by listing the role ARN explicitly or by granting the Glue service principal (glue.amazonaws.com). Add the role ARN (or the service principal) to the KMS key policy as a principal allowed to perform kms:Decrypt, kms:GenerateDataKey, and kms:Encrypt. The same trap applies to Redshift, Athena, EMR, and Firehose accessing SSE-KMS data. Always check key policy first when troubleshooting cross-service KMS access denied errors.

Q3 — What is the difference between AWS-managed keys and customer-managed keys?

AWS-managed keys are KMS keys created and managed by AWS for service integration — aws/s3, aws/redshift, aws/glue. They are free to use (only per-API-call cost), automatically rotated by AWS, and have a fixed key policy you cannot modify. Customer-managed keys are KMS keys you create yourself, costing $1/month per key plus per-API-call cost. You control the key policy (who can use it), enable annual rotation, configure cross-account access, and delete with a 7-30 day waiting period. Use AWS-managed keys for simple in-account encryption where service integration is sufficient. Use customer-managed keys when you need cross-account access, custom key policies, audit-grade rotation control, or regulatory compliance that requires customer-controlled keys. The DEA-C01 exam plants CMK as the right answer for cross-account scenarios and audit requirements.

Q4 — When should I use Secrets Manager versus Systems Manager Parameter Store?

Use Secrets Manager for credentials that need automatic rotation — RDS, Aurora, Redshift database passwords, third-party API keys with periodic rotation policies. Secrets Manager provides AWS-managed rotation Lambdas for the major databases and supports custom Lambdas for other secrets. Use Parameter Store for static configuration values, application-level config, non-rotating secrets where SecureString encryption is sufficient. Parameter Store is free for standard parameters and supports SecureString for KMS-encrypted values. The decision is rotation: if the secret rotates, Secrets Manager; if it does not, Parameter Store. For workloads with thousands of static parameters, Parameter Store wins on cost; for production database credentials with rotation requirements, Secrets Manager is the right answer despite the higher per-secret cost.

Q5 — How does Secrets Manager auto-rotation work for an RDS database?

Secrets Manager invokes a Lambda function on a schedule (e.g., every 30 days) following a four-step pattern: createSecret generates a new password and stores it as the AWSPENDING version of the secret, setSecret applies the new password to the RDS database (alters the user with the new password), testSecret verifies that the new password works by attempting a connection, finishSecret promotes AWSPENDING to AWSCURRENT and demotes the old version to AWSPREVIOUS. The four-step pattern ensures the application sees a working credential at all times — even mid-rotation, both old and new credentials work briefly. AWS provides pre-built rotation Lambdas for RDS MySQL/PostgreSQL/MariaDB/Oracle/SQL Server, Aurora MySQL/PostgreSQL, Redshift, and DocumentDB; you select the right template at secret creation. For non-AWS-managed secrets, write a custom Lambda implementing the same four steps.

Q6 — How do I encrypt a Glue ETL job's outputs and CloudWatch logs consistently?

Create a Glue Security Configuration that specifies SSE-KMS (with a CMK or AWS-managed key) for three components: S3 outputs (data the job writes to target buckets), CloudWatch logs (the job's log group), and job bookmarks (the bookmark state Glue stores). Attach the security configuration to every Glue ETL job and crawler that handles sensitive data. The configuration is reusable across jobs in the account, so one configuration can govern the entire data engineering team's encryption stance. The Glue role must have KMS permissions on the key, and the KMS key policy must grant the Glue service principal access. The DEA-C01 exam plants this as the right answer for "Glue ETL must encrypt all artifacts with a customer-managed key."

Q7 — How do I enforce TLS-only access to an S3 bucket?

Add a Deny statement to the bucket policy with the condition aws:SecureTransport=false. The statement denies any S3 request that arrives over plain HTTP, forcing all clients to use HTTPS. The policy looks like: {"Effect":"Deny","Principal":"*","Action":"s3:*","Resource":["arn:aws:s3:::bucket/*","arn:aws:s3:::bucket"],"Condition":{"Bool":{"aws:SecureTransport":"false"}}}. Apply this to every production bucket containing sensitive data. For Redshift, set require_ssl=true in the cluster parameter group; for RDS, configure SSL/TLS in the DB parameter group. The DEA-C01 exam plants TLS enforcement as a Domain 4 staple — the answer to "ensure encryption in transit" always includes the TLS-only deny statement plus VPC endpoints for private network paths.

Further Reading — Official AWS Documentation

The authoritative AWS sources are the AWS KMS Developer Guide (key types, key policies, envelope encryption, multi-region keys), the S3 User Guide encryption sections (SSE-S3, SSE-KMS, DSSE-KMS, Bucket Keys), the Redshift Cluster Management Guide encryption chapter, the Glue Developer Guide security configurations chapter, the Secrets Manager User Guide rotation chapter, the Systems Manager Parameter Store documentation, and the AWS Big Data Blog series on encryption patterns. The AWS Security Blog publishes case studies on data lake encryption and key rotation patterns that illustrate real-world deployments. The Skill Builder DEA-C01 Exam Prep Standard Course has dedicated modules for Domain 4 covering encryption and credential management. The AWS Well-Architected Security Pillar documents the broader encryption and key management best practices that DEA-C01 surfaces in scenario form.