DVA-C02 Security Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Encrypt the messages client-side before sending to SQS.

  Why it's wrong here

  Client-side encryption would protect data in transit and at rest outside SQS, but the requirement is specifically for encryption at rest *within SQS*. SQS’s server-side encryption (SSE) using KMS handles this automatically; client-side encryption is unnecessary and adds complexity. It is tempting because client-side encryption is a valid approach for end-to-end confidentiality when the service itself cannot be trusted to encrypt, but here SQS supports native at-rest encryption, making client-side encryption an overengineered solution that does not satisfy the stated requirement.

• ✗

  Store the messages in an S3 bucket with default encryption instead of using SQS.

  Why it's wrong here

  Storing messages in an S3 bucket fundamentally alters the application's architecture from a message queueing system to an object storage solution. Amazon SQS provides managed queueing semantics like message visibility timeouts, FIFO ordering, and dead-letter queues, which are essential for decoupling microservices and reliable asynchronous communication. S3, while offering default encryption for objects at rest, lacks these queueing features and would require significant custom development to replicate SQS's functionality, making it an unsuitable replacement for a messaging application.

• ✓

  Configure the SQS queue to use a customer managed KMS key.

  Why this is correct

  Configuring an SQS queue to use a Customer Managed Key (CMK) from AWS Key Management Service (KMS) is a correct approach to enable server-side encryption (SSE) for messages at rest. This option provides enhanced control over the encryption key, allowing developers to define specific key policies, manage key rotation schedules, and audit all key usage through AWS CloudTrail. SQS will then use this CMK to encrypt messages upon receipt and decrypt them automatically when consumers retrieve them, meeting the requirement for encryption at rest.

• ✓

  Enable server-side encryption (SSE) for the SQS queue using AWS KMS.

  Why this is correct

  Enabling server-side encryption (SSE) for an SQS queue using AWS KMS is the primary and most straightforward method to ensure messages are encrypted at rest within the SQS service. When SSE is activated, SQS transparently integrates with AWS KMS to handle the encryption of message bodies and metadata before they are persisted, and automatically decrypts them for authorized consumers. This built-in capability protects sensitive data stored in the queue without requiring any application-level encryption logic, simplifying development and enhancing security.

• ✗

  Use AWS CloudHSM to generate and store the encryption keys.

  Why it's wrong here

  AWS CloudHSM provides dedicated hardware security modules (HSMs) for generating and storing encryption keys, offering FIPS 140-2 Level 3 validated security. However, Amazon SQS Server-Side Encryption (SSE) is natively integrated with AWS Key Management Service (KMS) for key management, not directly with CloudHSM. While KMS can optionally use CloudHSM as a custom key store, SQS's direct SSE integration is with KMS itself. Therefore, attempting to use CloudHSM directly for SQS message encryption at rest is not a supported or feasible configuration.

Go deeper

Related to this question