SCS-C02 Data Protection Practice Question
A company uses Amazon S3 to store sensitive documents. The security policy requires that all objects be encrypted using server-side encryption with customer-provided keys (SSE-C). An application fails when trying to read an object with the error 'The request includes an invalid header.' What is the MOST likely cause?
⚠ Common exam trap
The trap is mixing up SSE-C with SSE-KMS — candidates pick 'encryption context' or 'KMS key disabled' because they forget SSE-C requires the customer key headers on every request, not KMS.
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
✓
The application did not include the x-amz-server-side-encryption-customer-key header in the GET request.
With SSE-C, the customer provides the encryption key on every request, and S3 does not store it. For a GET request, the client must include the same key headers used during PUT: x-amz-server-side-encryption-customer-algorithm, x-amz-server-side-encryption-customer-key, and x-amz-server-side-encryption-customer-key-MD5. If the key header is missing, S3 returns an 'invalid header' error because it cannot decrypt the object.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The application did not specify an encryption context in the request.
Why it's wrong here
Encryption context is an optional set of key-value pairs used exclusively with AWS KMS-based encryption (SSE-KMS) to bind cryptographic operations to specific context data; SSE-C does not use or accept an encryption context. Because the object is protected with SSE-C, the absence of an encryption context in the GET request is not the cause of the failure. The request instead fails because the customer-provided key itself is not being sent, not because of any context mismatch.
- ✗
The KMS key used for encryption has been disabled.
Why it's wrong here
A disabled KMS key would only cause access failures for objects encrypted with SSE-KMS, because that method relies on a KMS customer master key to generate and decrypt data keys. With SSE-C, S3 has no involvement with AWS KMS; the customer supplies the raw encryption key on every request. Therefore, whether the KMS key is disabled or active is entirely irrelevant to retrieving an SSE-C encrypted object.
- ✓
The application did not include the x-amz-server-side-encryption-customer-key header in the GET request.
Why this is correct
For an SSE-C encrypted object, S3 does not store or possess the actual encryption key; it only stores a one-way HMAC-derived verification value. Accordingly, every GET request must include the `x-amz-server-side-encryption-customer-key` header, along with `x-amz-server-side-encryption-customer-algorithm` and optionally the MD5 header, so S3 can verify the key and decrypt the object. Omitting the key header in the GET causes S3 to return a 400 Bad Request because it cannot authenticate the customer-supplied key.
- ✗
The S3 bucket does not have versioning enabled.
Why it's wrong here
Bucket versioning is an independent object-storage feature that controls whether new versions are created on overwrites; it has no bearing on SSE-C encryption. SSE-C works identically in versioned and non-versioned buckets, and a GET request will succeed without versioning enabled. The inability to retrieve the object stems from the missing customer-supplied encryption key header, not from version configuration, so this is not the cause.
Quick reference
Symmetric Encryption Algorithm Comparison
| Algorithm | Key Size | Block Size | Status | Notes |
|---|---|---|---|---|
| AES-128 | 128-bit | 128-bit | Current standard | NIST approved; WPA3, TLS |
| AES-256 | 256-bit | 128-bit | Current standard | Preferred for sensitive / govt data |
| 3DES | 112-bit effective | 64-bit | Deprecated (2023) | Replaced by AES |
| DES | 56-bit | 64-bit | Broken | Cracked in < 24 h; never deploy |
| ChaCha20 | 256-bit | Stream cipher | Current | TLS 1.3, WireGuard |
Go deeper
Related to this question
About these practice questions
Courseiva writes every SCS-C02 question from scratch — 1,205 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 SCS-C02 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 SCS-C02 exam.