Redshift Encryption with Customer Managed KMS Key and Automatic Rotation
A company uses Amazon Redshift for data warehousing. The security team requires that all data stored in Redshift be encrypted at rest using a customer-managed KMS key. How should the data engineer configure this?
⚠ Common exam trap
DEA-C01 often tests the misconception that Redshift encryption can be enabled after cluster creation or via parameter groups, when in reality it is an immutable creation-time setting requiring cluster recreation or snapshot restore.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Enable encryption using a KMS key when creating the Redshift cluster
Redshift encryption at rest with a customer-managed KMS key must be specified at cluster creation time via the 'Encrypted' and 'KmsKeyId' parameters (console: 'KMS' encryption option). Once a cluster is created unencrypted, it cannot be converted in place — you must create a new encrypted cluster and migrate data. This satisfies the security team's requirement of a CMK rather than the default AWS-managed key.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Enable encryption using a KMS key when creating the Redshift cluster
Why this is correct
Specifying a customer-managed KMS key at cluster creation makes Redshift encrypt all data at rest with that key, satisfying the requirement for customer-managed encryption. Redshift cannot retroactively swap the key type, so this must be set during provisioning.
- ✗
Configure S3 SSE-KMS on the underlying S3 storage
Why it's wrong here
SSE-KMS on underlying S3 storage encrypts S3 objects, not Redshift cluster data blocks or snapshots, so the requirement is unmet. It is tempting because Redshift uses S3 internally, but S3 encryption settings are correct for securing S3 buckets, not Redshift at rest.
- ✗
Use the AWS KMS console to encrypt the Redshift cluster after creation
Why it's wrong here
Redshift encryption at rest must be specified at cluster creation; the KMS console cannot retroactively encrypt an existing cluster. It is tempting because KMS manages the keys, but key management is separate from enabling cluster encryption, which requires a new encrypted cluster.
- ✗
Set a cluster parameter group with encryption enabled
Why it's wrong here
Cluster parameter groups tune database behaviour such as query settings; they contain no encryption-at-rest switch, so this cannot apply a customer-managed KMS key. Parameter groups are the right tool for runtime configuration changes, not storage encryption.
Go deeper
Related to this question
About these practice questions
Courseiva writes every DEA-C01 question from scratch — 1,321 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Amazon Web Services exam blueprint
This DEA-C01 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DEA-C01 exam.