DOP-C02 SDLC Automation Practice Question

Exhibit

CodePipeline execution history:
Pipeline: MyPipeline
Date: 2024-03-01
Stage: Deploy
Action: DeployToECS

Execution ID: e-123456789
Status: Succeeded

Revision: commit SHA abc123
Deployment details:
  - ECS service: my-service
  - Task definition: my-task:12
  - Desired count: 2
  - Running count: 2
  - Pending count: 0

After deployment, application health checks fail. Rolling back to previous revision (task definition my-task:11) resolves the issue.

CloudWatch Logs from ECS tasks:
[ERROR] Failed to connect to database: TimeoutError: connect ETIMEDOUT 10.0.0.5:5432

Refer to the exhibit. The deployment succeeded but the application fails. What is the MOST likely cause?

⚠ Common exam trap

It's easy for candidates to assume a successful deployment means the application is fully functional, but AWS separates the deployment of infrastructure (task definition, service update) from the application's runtime dependencies, so a misconfigured connection string or security group can cause application failure post-deployment.

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

✓

The new task definition has a misconfigured database connection string or security group.

The most common cause of a deployment succeeding but the application failing is a misconfiguration in the new task definition, such as an incorrect database connection string or a security group that does not allow traffic to the database. CodePipeline can successfully deploy the new task definition to ECS, but if the application cannot connect to its backend services due to these configuration errors, the application will fail at runtime. This aligns with the scenario where the deployment pipeline reports success but the application itself is non-functional.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
The CodePipeline deployment action uses the wrong cluster.
Why it's wrong here
The deployment action references the cluster in the ECS service definition, and an incorrect cluster name or ARN would cause the CodePipeline action to fail before any tasks are placed. Since the pipeline completed successfully and tasks are running, the cluster reference is demonstrably valid. A cluster mismatch would also surface as a ResourceNotFoundException or service discovery failure, not a database timeout.
✓
The new task definition has a misconfigured database connection string or security group.
Why this is correct
A database connection timeout to the database IP address strongly indicates the new task definition is passing an invalid connection string or is associated with a security group that blocks the database port. The application container is starting and attempting to open a TCP connection, but the destination either rejects or silently drops it — exactly what a bad host, port, or restrictive inbound rule produces. This is an application-level configuration defect in the task definition that does not prevent the task from launching, which is why the deployment can still be marked successful.
✗
The ECS service is not registered with a target group.
Why it's wrong here
If the ECS service had no target group registration, the ALB would be unable to route traffic to the tasks and would return HTTP 503 Service Unavailable before any application code executes. The observed database timeout proves the container received incoming traffic and attempted to make an outbound connection, so the service must be correctly wired to a target group. Moreover, a missing target group registration would cause the deployment to fail health checks, not allow a green deployment.
✗
The database is not available in the same Availability Zone.
Why it's wrong here
An Availability Zone mismatch between the database and the ECS tasks does not produce a connection timeout, because VPC networking permits cross-AZ traffic by default. Even if tasks and the DB are in different AZs, the TCP connection succeeds unless a security group or NACL blocks it, and any added latency would be minimal. Additionally, managed database services like RDS/Aurora replicate across AZs transparently, so an AZ mismatch is not a logical configuration error that would cause this symptom.

Go deeper

DOP-C02 SDLC Automation Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question