DVA-C02 Development with AWS Services 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.

• ✗

  Use AWS KMS to generate a data key and store it in the Lambda environment variable.

  Why it's wrong here

  Using AWS KMS to generate a data key and storing it in a Lambda environment variable is insecure and misuses KMS's intended purpose. While KMS provides cryptographic keys for encryption, it is not a secret storage service itself. Storing a data key directly in an environment variable exposes it, and KMS's primary function is to manage Customer Master Keys (CMKs) for encrypting data, not to securely store application secrets or their derived keys, lacking robust secret lifecycle management.

• ✓

  Store the password in AWS Secrets Manager and retrieve it in the Lambda function using the AWS SDK.

  Why this is correct

  AWS Secrets Manager is the most appropriate and secure solution for storing and retrieving sensitive credentials like passwords in Lambda functions. It is purpose-built for secret management, offering features such as automatic rotation of secrets, fine-grained access control, and comprehensive auditing. Lambda functions can securely retrieve these secrets at runtime using the AWS SDK, ensuring credentials are never hardcoded or exposed in environment variables.

• ✗

  Store the password in AWS Systems Manager Parameter Store and reference it in the Lambda function.

  Why it's wrong here

  Storing the password in AWS Systems Manager Parameter Store, even as a SecureString, is a viable option for general configuration but falls short for passwords requiring robust lifecycle management. While Parameter Store encrypts SecureStrings using KMS, its primary limitation for passwords is the lack of built-in automatic rotation capabilities. This means developers would need to implement custom rotation logic, adding operational overhead and increasing the risk of stale or compromised credentials.

• ✗

  Encrypt the password using AWS KMS and store it in Amazon DynamoDB.

  Why it's wrong here

  Encrypting a password with AWS KMS and storing it in Amazon DynamoDB is an anti-pattern for secret management. While KMS can encrypt data, DynamoDB is a NoSQL database designed for data storage, not for managing the lifecycle of application secrets. This approach lacks critical features inherent to dedicated secret management services, such as automatic rotation, granular access policies specifically for secrets, and comprehensive auditing of secret access, making it less secure and more complex to maintain.

Go deeper

Related to this question