A company hosts its application on AWS. The application runs on an Amazon Elastic Container Service (Amazon ECS) cluster that uses AWS Fargate. The cluster runs behind an Application Load Balancer. Th

Question

Options

• AMigrate the secret credentials to Amazon RDS parameter groups. Encrypt the parameter by using
• BMigrate the credentials to AWS Systems Manager Parameter Store. Encrypt the parameter by
• CMigrate the credentials to ECS Fargate environment variables. Encrypt the credentials by using
• DMigrate the credentials to AWS Secrets Manager. Encrypt the credentials by using an AWS Key

• A
  31% (21)
• B
  7% (5)
• C
  13% (9)
• D
  48% (32)

Explanation

AWS Secrets Manager (Option D) is purpose-built for storing, encrypting, and automatically rotating secrets like database credentials - it integrates natively with Amazon Aurora and can rotate credentials on a configurable schedule with zero custom code, making it the lowest-overhead solution.

Option A (RDS Parameter Groups) is wrong because parameter groups store database configuration settings (like engine parameters), not application credentials - they have no rotation capability.

Option B (Systems Manager Parameter Store) can store secrets securely, but automatic credential rotation is not a built-in feature; you'd need to build and manage a custom Lambda-based rotation solution, adding significant operational overhead.

Option C (ECS environment variables) is the least secure option - environment variables are visible in task definitions, logs, and container metadata endpoints, and they offer no rotation mechanism at all.

Memory tip: Think of Secrets Manager as "set it and forget it" for secrets - if the exam mentions rotation + least overhead, Secrets Manager wins every time. Parameter Store is the budget-friendly sibling that requires you to wire up rotation yourself.

No community discussion yet for this question.