DVA-C02 Deployment 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.

• ✗

  Enable detailed logging for the Elastic Beanstalk environment and filter out sensitive data.

  Why it's wrong here

  Detailed logging is an operational tool, not a secrets-control mechanism. If sensitive values appear in logs—via stack traces, configuration dumps, or startup messages—filtering them afterward is reactive and inevitably incomplete because log formats vary and data may already be persisted. It also does nothing to protect secrets in Elastic Beanstalk environment properties or source artifacts, leaving them accessible to anyone who can view logs or environment configuration.

• ✗

  Set environment variables using Elastic Beanstalk environment properties in the console.

  Why it's wrong here

  Setting Elastic Beanstalk environment properties in the console stores the values as plaintext in the environment’s configuration metadata, and they are visible through the Elastic Beanstalk console, AWS CLI, and API to anyone with DescribeConfigurationSettings permissions. These values are also passed into the instance as OS-level environment variables, so they can be read from the running process or instance metadata if an attacker compromises the EC2 instance. They provide no native encryption, rotation, or audit trail, making them unsuitable for sensitive credentials.

• ✓

  Store sensitive environment variables in AWS Systems Manager Parameter Store and retrieve them at runtime.

  Why this is correct

  Storing sensitive values in AWS Systems Manager Parameter Store as SecureString parameters encrypts them with a KMS key and keeps them out of both source code and Elastic Beanstalk environment properties. The Node.js application fetches each secret at runtime using the SSM GetParameter API, which is authorized via IAM roles attached to the Elastic Beanstalk instance profile. This approach supports per-environment separation, parameter versioning, and the ability to update credentials without redeploying or changing the environment configuration.

• ✓

  Use AWS Secrets Manager to manage secrets and reference them in the application code.

  Why this is correct

  AWS Secrets Manager is a purpose-built service for application credentials, encrypting secrets with KMS and providing built-in automatic rotation for services like Amazon RDS. The application references secrets by calling GetSecretValue, and access is controlled by IAM policies on the Elastic Beanstalk instance role. Besides rotation, it offers resource-based policies, cross-account sharing, and secret versioning, and it avoids exposing secrets in environment metadata or logs—making it a valid secure alternative to Parameter Store when managed rotation is needed.

• ✗

  Embed the environment variables in the application package as a .env file.

  Why it's wrong here

  An embedded .env file is packaged as part of the application source and deployment artifact, meaning it is plaintext and travels with your code into Elastic Beanstalk, any build pipeline, and potentially version control. If the bundle is downloaded, shared, or logged—or if the .env file is accidentally committed—the secrets are exposed with no access control, encryption, or audit trail. This violates the principle of separating configuration from code and provides no way to rotate credentials without modifying and redeploying the application.