DOP-C02 Security and Compliance Practice Question
A DevOps engineer needs to store database credentials for an application running on Amazon ECS. The credentials must be automatically rotated every 30 days and encrypted at rest. Which solution meets these requirements with the LEAST operational overhead?
⚠ Common exam trap
DOP-C02 often tests the distinction between Parameter Store and Secrets Manager — candidates pick Parameter Store because it is cheaper, forgetting that only Secrets Manager has native automatic rotation.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Store credentials in AWS Secrets Manager and configure automatic rotation.
AWS Secrets Manager is purpose-built for storing and managing secrets such as database credentials, and it natively supports automatic rotation via Lambda functions on a schedule (e.g., every 30 days). It encrypts secrets at rest using KMS by default and integrates directly with ECS task definitions via the secrets parameter, so credentials are injected at runtime without hardcoding. This delivers the required rotation and encryption with minimal operational overhead.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Store credentials in AWS Systems Manager Parameter Store as SecureString.
Why it's wrong here
AWS Systems Manager Parameter Store SecureString parameters are encrypted with KMS and can be referenced by ECS task definitions, but they do not support automatic rotation of the underlying secret value. You would need to implement a custom rotation solution, such as a scheduled Lambda to invoke an RDS password update and then write the new parameter, adding operational complexity and still lacking many Secrets Manager features like secret versioning for retrieval during rotation. While inexpensive, Parameter Store is intended for configuration data, not as a fully managed credentials rotation service.
- ✗
Encrypt credentials with AWS KMS and store them in a versioned S3 bucket.
Why it's wrong here
Encrypting credentials with AWS KMS and placing them in a versioned S3 bucket is not a purpose-built secrets-management solution: you must build custom logic to read the object, decrypt it, and rotate credentials manually by writing a new version and updating clients. S3 versioning does provide historical rollback, but retaining old credential versions in the bucket poses a residual security risk, and there is no native integration with ECS for secure injection into a container. Managing IAM policies for S3 plus KMS adds ongoing overhead compared to Secrets Manager's managed rotation and secret lifecycle.
- ✗
Embed credentials as environment variables in the ECS task definition.
Why it's wrong here
Storing database credentials as environment variables in the ECS task definition exposes them in plaintext through the task definition JSON, container metadata, and AWS APIs such as DescribeTaskDefinition, making them accessible to anyone with read access. Environment variables are not encrypted at rest, cannot be automatically rotated without redeploying a new task definition revision, and remain visible in container runtime introspection tools. This approach violates best practices for secret handling and fails the requirement for automated, low-overhead credential rotation.
- ✓
Store credentials in AWS Secrets Manager and configure automatic rotation.
Why this is correct
AWS Secrets Manager is purpose-built for storing database credentials, and when configured with automatic rotation, it natively rotates the password on a schedule using an attached Lambda function (e.g., the built-in rotation template for RDS). Secrets Manager also encrypts the secret at rest with AWS KMS, integrates with ECS via the 'secrets' parameter in the task definition, and requires no custom code to implement periodic credential changes, giving you the least operational overhead while meeting the security and compliance requirements.
Quick reference
Cloud Service Model Comparison
| Model | You Manage | Provider Manages | Examples |
|---|---|---|---|
| IaaS | OS, runtime, apps, data | Hardware, hypervisor, networking | EC2, Azure VMs, GCP Compute Engine |
| PaaS | Apps and data | OS, runtime, middleware, hardware | Elastic Beanstalk, Azure App Service |
| SaaS | Data and settings only | Everything else | Microsoft 365, Salesforce, Workday |
| FaaS / Serverless | Function code only | Infra, scaling, runtime | Lambda, Azure Functions, Cloud Run |
| CaaS | Containers and apps | Kubernetes, OS, hardware | EKS, AKS, GKE |
Go deeper
Related to this question
About these practice questions
This DOP-C02 question is part of Courseiva's 1,298-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Amazon Web Services exam blueprint
This DOP-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DOP-C02 exam.