Jeff’s Note #
Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.
For AWS DVA-C02 candidates, the confusion often lies in the difference between client-side encryption and service-side encryption of CloudWatch Logs. In production, this is about knowing exactly how to enable managed encryption without rewriting application code or re-creating resources. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
A fintech startup, MonetaSoft, has an application that continuously writes critical log data to an existing Amazon CloudWatch Logs log group created two months ago. Due to a recent internal audit, MonetaSoft’s security team mandates that all future log entries must be encrypted with a customer-managed AWS KMS key to comply with their data protection policy.
The Requirement: #
Without modifying the application’s code or re-creating the log group, implement the encryption so that all new log events are encrypted using the specified KMS key. Choose the solution that requires the least development effort.
The Options #
- A) Use the AWS Encryption SDK in the application to encrypt and decrypt log data before writing to CloudWatch Logs.
- B) Use the AWS KMS console to associate the KMS key directly with the existing log group.
- C) Use the AWS CLI command
aws logs create-log-groupwith the KMS key ARN to create a new encrypted log group. - D) Use the AWS CLI command
aws logs associate-kms-keywith the KMS key ARN to associate encryption with the existing log group.
Google adsense #
leave a comment:
Correct Answer #
D) Use the AWS CLI command aws logs associate-kms-key with the KMS key ARN to associate encryption with the existing log group.
Quick Insight: The Developer Imperative #
- For developers, understanding how to enable KMS encryption on existing CloudWatch Logs without downtime or rewriting code is critical. Option D uses a direct API/CLI method to apply encryption to an already created log group, which is the cleanest and simplest approach.
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 D
The Winning Logic #
The associate-kms-key command in the AWS CLI or the corresponding API call allows you to link an existing CloudWatch Logs log group to a customer-managed AWS KMS key. This modifies the log group’s encryption setting and ensures all subsequent logs are encrypted transparently. It requires no code changes on the producer side and does not require recreating the resource.
- No code-level encryption (unlike Option A) is necessary, avoiding developer overhead.
- It targets the existing log group, so no need to create a new log group (ruling out Option C).
- The AWS KMS console does not support directly associating a KMS key with CloudWatch Logs log groups (eliminating Option B).
This API-level approach is exactly what a lead developer managing existing infrastructure would use for minimal disruption and maximum security compliance.
The Trap (Distractor Analysis): #
-
Why not Option A?
Client-side encryption with the AWS Encryption SDK requires modifying code to encrypt and decrypt all log data, increasing complexity and potential errors. It is unnecessary since CloudWatch Logs supports managed encryption. -
Why not Option B?
The AWS KMS console does not provide an option to associate KMS keys with existing CloudWatch Logs groups. The UI does not support this feature. -
Why not Option C?
Creating a new log group with encryption is valid but violates the “least effort” requirement because it involves creating new resources, and existing logs will not be encrypted retrospectively.
The Technical Blueprint #
aws logs associate-kms-key \
--log-group-name MonetaSoftAppLogs \
--kms-key-id arn:aws:kms:region:account-id:key/key-id
This CLI command attaches the specified customer-managed KMS key to the existing MonetaSoftAppLogs log group. After this, all new log events written to this group will be encrypted server-side by CloudWatch Logs.
The Comparative Analysis #
| Option | API Complexity | Development Overhead | Use Case |
|---|---|---|---|
| A | High (SDK integration) | High (code changes) | Custom client-side encryption before logs |
| B | None (Console action) | None | Not supported for CloudWatch Logs groups |
| C | Medium (new resource) | Medium | Encrypted logs but requires re-creating log group |
| D | Low (CLI/API call only) | None | Best for enabling encryption on existing log group |
Real-World Application (Practitioner Insight) #
Exam Rule #
For the exam, always pick aws logs associate-kms-key when you see enabling KMS encryption on an existing CloudWatch Logs group with minimal code or operational changes.
Real World #
In production, client-side encryption (Option A) might be used if you want end-to-end encryption with key management outside AWS. But for typical managed CloudWatch Logs encryption, the service-side association (Option D) is simpler and less error-prone.
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the AWS DVA-C02 exam.