DVA-C02 Troubleshooting and Optimization 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 Secrets Manager to store and retrieve the credentials at runtime.

  Why this is correct

  AWS Secrets Manager is the recommended service for storing and retrieving credentials at runtime. It encrypts secrets at rest with AWS KMS keys, integrates with IAM for fine-grained access control, and supports automatic rotation to reduce the risk of compromised credentials. The application can fetch the secret on startup or on demand using the AWS SDK, eliminating hardcoded values from the codebase and ensuring that the secret is not visible in configuration files or logs.

• ✗

  Store the credentials in a configuration file within the application source code.

  Why it's wrong here

  Putting credentials in a configuration file inside the application source code exposes sensitive values to anyone with access to the code repository, including past commits and build artifacts. Configuration files are often copied to multiple environments and containers, making credential leakage more likely. This approach also lacks encryption at rest, automatic rotation, and audit logging, and it is a direct violation of the principle of least privilege. As a result, this option is fundamentally insecure and not suitable for production workloads.

• ✓

  Use Elastic Beanstalk environment properties to set the credentials.

  Why this is correct

  Elastic Beanstalk environment properties can be set via the EB console or CLI and are surfaced as environment variables to the application, so they are technically a functional way to pass credentials. However, these values are stored as plaintext in the environment configuration and are visible to anyone with access to the Beanstalk environment or its configuration. While convenient for non-sensitive settings, they do not provide encryption, fine-grained IAM restrictions, or automatic rotation, whereas AWS Secrets Manager offers all of these features. Hence, this approach is less secure and not the best answer for managing credentials in a microservice.

• ✗

  Store the credentials in an encrypted file on an EC2 instance.

  Why it's wrong here

  Storing the credentials in an encrypted file on an EC2 instance is fragile because the instance is ephemeral in Elastic Beanstalk—it can be terminated, replaced, or scaled down at any time, causing the file to be lost. It also requires manual management of encryption keys, and if the decryption key or the instance is compromised, the credentials are exposed. Elastic Beanstalk does not provide a native mechanism to manage such files across instances, making this option impractical and not secure for a managed service environment.

• ✗

  Store the credentials in an S3 bucket with a public read policy.

  Why it's wrong here

  An S3 bucket with a public read policy makes the credentials accessible to anyone on the internet, which completely defeats the purpose of securing them. Even if the bucket policy were restricted, S3 objects do not offer native secret rotation or a single secret-management lifecycle, and it would require you to build custom access controls. Publicly exposing a bucket is a severe misconfiguration that can lead to immediate credential theft and data breaches. Therefore, this option is both insecure and non-compliant with AWS security best practices.

Go deeper

Related to this question