DVA-C02 Deployment Practice Question
A startup is deploying a Node.js application using AWS Elastic Beanstalk. They have configured the environment to use a load-balanced, auto-scaled environment with a minimum of 2 instances and a maximum of 4. The application connects to an Amazon RDS MySQL database. After a successful deployment, users report that the application is intermittently returning errors. The developer checks the Elastic Beanstalk logs and finds that the application is timing out when connecting to the database. The developer also notices that the database connection string is hardcoded in the application code. What is the most likely cause of the intermittent errors?
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 RDS instance has reached its maximum number of concurrent connections because the application instances are not using connection pooling.
The RDS instance has reached its maximum number of concurrent connections because the application instances are not using connection pooling. In a load-balanced, auto-scaled Elastic Beanstalk environment with 2-4 Node.js instances, each instance opens its own database connections, and without connection pooling or Amazon RDS Proxy, the total can exceed the MySQL max_connections limit, producing intermittent connection timeouts under load. Option A is unlikely because a security group misconfiguration would typically cause consistent, not intermittent, connection failures across all instances. Option C is not supported by the symptom of timeouts when connecting, which points to connection exhaustion rather than premature closure. Option D is irrelevant because lack of Multi-AZ affects availability during an AZ failure, not routine intermittent connection timeouts.
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 security group for the RDS instance does not allow inbound traffic from the Elastic Beanstalk environment's security group.
Why it's wrong here
This scenario would result in consistent connection failures from the Elastic Beanstalk application to the RDS instance, manifesting as immediate "connection refused" errors rather than intermittent timeouts. The problem description likely implies intermittent issues or timeouts, which are not characteristic of a fundamental security group misconfiguration blocking all traffic. A security group misconfiguration typically prevents any initial connection attempt from succeeding.
- ✓
The RDS instance has reached its maximum number of concurrent connections because the application instances are not using connection pooling.
Why this is correct
Node.js applications, especially when deployed across multiple Elastic Beanstalk instances, can quickly exhaust the RDS instance's maximum concurrent connection limit if they establish a new database connection for every request without proper pooling. Each application instance, without pooling, might open numerous persistent connections, leading to connection starvation for subsequent requests and manifesting as intermittent timeouts or failures when the limit is reached. Connection pooling reuses existing connections, significantly reducing the total number of open connections to the database.
- ✗
The application code has a bug that causes the database connection to be closed prematurely.
Why it's wrong here
If the application code were prematurely closing database connections, the logs would typically indicate errors related to "connection closed" or "invalid connection state" during query execution, rather than connection timeouts. Premature closure would likely lead to immediate errors upon subsequent attempts to use that specific connection, not a general inability to establish new connections or execute queries due to a timeout. Timeouts often suggest the database is unresponsive or overloaded, not that the client closed the connection too soon.
- ✗
The RDS instance is not configured for Multi-AZ deployment, causing failover issues.
Why it's wrong here
Multi-AZ deployment for RDS primarily enhances availability and durability by providing an automatic failover mechanism to a standby replica in a different Availability Zone. While crucial for high availability, it does not directly impact the maximum number of concurrent connections that the primary database instance can handle. Connection limits are determined by the instance class and database engine configuration, not by the presence or absence of a Multi-AZ standby. Failover issues would typically manifest as brief outages during a failover event, not as intermittent connection timeouts due to resource exhaustion.
Go deeper
Related to this question
About these practice questions
One of 1,135 original DVA-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DVA-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 DVA-C02 exam.