Jeff’s Note #
Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.
For DVA-C02 candidates, the confusion often lies in how to properly implement encryption at rest with customer-generated keys in DynamoDB, rather than relying on application-layer encryption. In production, this is about knowing exactly how DynamoDB integrates with AWS KMS and the correct way to specify the encryption key during table creation and SDK usage. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
CodeCraft Inc., a fast-growing ecommerce startup, wants to store customer purchase orders in Amazon DynamoDB. Due to strict internal security policies, all customer data must be encrypted at rest using a symmetric key that the company itself manages. The lead developer needs to ensure that DynamoDB tables meet this requirement while minimizing application complexity and overhead.
The Requirement: #
Ensure that all customer order data in DynamoDB is encrypted at rest with a customer-generated key managed through AWS Key Management Service (KMS).
The Options #
- A) Create the DynamoDB table with encryption disabled. Implement client-side encryption in the application by using the company’s key to encrypt data before writing and decrypt data after reading.
- B) Store the key in AWS KMS as a customer managed key (CMK). Specify the Amazon Resource Name (ARN) of this CMK when creating the DynamoDB table to enable server-side encryption with the customer key.
- C) Store the key in AWS KMS as a customer managed key (CMK). Create the DynamoDB table with default encryption enabled. In the application, include a
kms:Encryptparameter specifying the ARN of the CMK in all DynamoDB SDK calls. - D) Store the key in AWS KMS as an AWS-managed key. Provide the ARN of this AWS-managed key when creating the DynamoDB table to enable default server-side encryption.
Google adsense #
leave a comment:
Correct Answer #
B
Quick Insight: The Developer Encryption Imperative #
- DynamoDB’s server-side encryption at rest supports specifying a customer managed CMK at table creation to meet compliance requirements without adding app-layer crypto complexity.
- Client-side encryption (Option A) adds significant complexity and potential performance penalty.
- The SDK does not accept a
kms:Encryptparameter to control encryption per request (Option C) — encryption is configured on the table itself.- Using AWS-managed keys (Option D) does not meet the requirement for customer-generated keys.
Content Locked: The Expert Analysis #
You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?
The Expert’s Analysis #
Correct Answer #
Option B
The Winning Logic #
DynamoDB supports server-side encryption (SSE) powered by AWS KMS. By default, DynamoDB uses an AWS-managed key. However, to comply with internal policies requiring customer-generated keys, you can specify a customer managed key (CMK) during table creation.
- When creating the DynamoDB table via the console, CLI, or SDK, you provide the ARN of the CMK that you manage.
- DynamoDB uses that CMK automatically to encrypt data at rest, abstracting encryption and decryption from the application layer.
- This approach simplifies development, as you do not implement client-side encryption manually (which is error-prone and increases latency).
- The SDK does not require any additional parameters to specify encryption per request; encryption is transparent once configured on the table.
The Trap (Distractor Analysis) #
- Why not A? Application-level client-side encryption is possible but not recommended due to complexity, higher latency, key rotation challenges, and risk of data format errors. The exam tests knowledge of built-in server-side encryption with KMS.
- Why not C? There is no
kms:Encryptparameter in DynamoDB SDK calls controlling encryption. Encryption keys are attached to the table, not individual API calls. This choice reflects misunderstanding of SDK capabilities and encryption processes. - Why not D? AWS-managed keys do AWS’s default encryption but do not satisfy the requirement to use a company-generated CMK.
The Technical Blueprint #
# AWS CLI example of creating a DynamoDB table encrypted with a customer managed key (CMK):
aws dynamodb create-table \
--table-name CustomerOrders \
--attribute-definitions AttributeName=OrderId,AttributeType=S \
--key-schema AttributeName=OrderId,KeyType=HASH \
--provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \
--sse-specification Enabled=true,SSEType=KMS,KMSMasterKeyId=arn:aws:kms:us-east-1:123456789012:key/abcd1234-56ef-78gh-90ij-klmnopqrstuv
The Comparative Analysis #
| Option | API Complexity | Performance Impact | Use Case Suitability |
|---|---|---|---|
| A | High | Higher latency | Client-side encryption; rarely needed |
| B | Low | Minimal overhead | Best practice for customer key encryption |
| C | Incorrect usage | N/A | Misunderstands SDK encryption parameters |
| D | Low | Minimal overhead | Uses AWS-managed keys; not customer keys |
Real-World Application (Practitioner Insight) #
Exam Rule #
For the exam, always pick server-side encryption with a customer managed CMK in DynamoDB when you see a requirement for company-generated keys.
Real World #
In production, you might choose client-side encryption only if you need end-to-end encryption control beyond AWS boundaries, but this adds enormous complexity and is rarely necessary.
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the DVA-C02 exam.