DOP-C02 SDLC Automation 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.

• ✗

  The RDS database is not available because it is being updated during the deployment.

  Why it's wrong here

  This is incorrect because the RDS database is an independent managed service and its lifecycle is not tied to the Elastic Beanstalk deployment. If the database were being updated, you would see a maintenance window, a failover event, or a status of 'modifying' in the RDS console, but the deployment logs for the application show connection failures, not an unavailable RDS endpoint. Even during a Multi-AZ failover, connections typically recover within a minute; a persistent failure is much more likely a network permission issue than an RDS update.

• ✗

  The deployment policy should be changed to 'Rolling' to ensure instances are updated in place.

  Why it's wrong here

  Changing the deployment policy to 'Rolling' will not resolve the problem because rolling updates do not perform 'in-place' patch updates—they still terminate existing instances and launch new ones in batches. Each newly launched instance receives the current security group assigned to the Elastic Beanstalk environment, so if that security group is not authorized in the RDS security group's inbound rules, the new instances will still be unable to connect. The root cause is a security group misconfiguration, not the deployment strategy, so modifying the policy only changes how failures are rolled out, not whether the database connection succeeds.

• ✓

  The security group attached to the Elastic Beanstalk environment does not allow the new instances to connect to the RDS database.

  Why this is correct

  This is correct. When Elastic Beanstalk performs a deployment that replaces instances (such as an immutable or rolling update with a new Auto Scaling group), the new instances are launched with the environment's current security group. If that security group is not explicitly added as an allowed source in the RDS database's security group inbound rules, the new instances will be denied TCP (or PostgreSQL/MySQL) connections, even though the application code and database settings are unchanged. You must authorize the Elastic Beanstalk environment's security group ID (or its attached load balancer's security group) in the RDS security group to allow traffic from the latest instance replacements.

• ✗

  The application code has a bug that causes the health check to fail.

  Why it's wrong here

  This is wrong because the application logs and health check failures are symptoms, not the root cause. If the code had a bug that caused the health check to fail, you would see HTTP 5xx errors, timeouts in the app logs, or application-level exceptions; however, the reported logs indicate a database connectivity error (e.g., 'connection timed out' or 'could not connect to server'). The health check is likely failing because the application cannot start or respond due to failed DB connections, but the underlying issue is network security, not the code itself. Therefore, fixing the code would not address the real problem.

Go deeper

Related to this question