An application deployed on AWS Batch needs to retrieve two types of configuration values: database credentials that must be automatically rotated every 30 days, and non-sensitive application settings (such as logging levels and API endpoints) that do not require rotation. Which combination of actions should the developer take to retrieve these values securely, cost-effectively, and with minimal operational overhead? (Select TWO.)
- Store the database credentials in AWS Secrets Manager and configure automatic rotation using the built-in rotation templates.Answer
- Store the logging level and API endpoints in AWS Systems Manager Parameter Store.Answer
- CStore both the database credentials and the application configuration parameters in AWS Secrets Manager to centralize secrets storage.
- DStore the database credentials in AWS Systems Manager Parameter Store as standard parameters and write a custom scheduled script within the application container to handle password rotation.
- EEmbed the database credentials directly in the Dockerfile as environment variables to optimize startup times for the AWS Batch jobs.
Answer
Store the database credentials in AWS Secrets Manager with automatic rotation configured, and store the non-sensitive parameters (logging level and API endpoints) in AWS Systems Manager Parameter Store.
The correct strategy combines AWS Secrets Manager and AWS Systems Manager Parameter Store. Storing database credentials in AWS Secrets Manager allows utilizing its native automatic rotation feature to change passwords every 30 days without custom scripts. Storing non-sensitive configuration data, such as logging levels and API endpoints, in Parameter Store is highly cost-effective and avoids the monthly per-secret cost of Secrets Manager.
Step-by-Step Solution
Key Concept
Choosing between AWS Secrets Manager and Systems Manager Parameter Store based on security, rotation requirements, and cost optimization.
Estimated Time:1m 30s