DVA-C02 Troubleshooting and Optimization Practice Question
A company runs a web application on EC2 instances behind an Application Load Balancer (ALB). The application stores session data in an RDS MySQL database. Recently, users have reported that they are being logged out unexpectedly and their session data is lost. The developer investigates and finds that the RDS instance's CPU utilization spikes periodically, coinciding with the logout events. The application uses connection pooling via an RDS Proxy. The developer suspects that the session table is being dropped or truncated. After checking the application logs, the developer finds no evidence of truncation commands. The RDS instance has automated backups enabled, and the binary logs are retained for 24 hours. The developer wants to identify the root cause and prevent future occurrences. Which course of action should the developer take?
⚠ Common exam trap
DVA-C02 often tests the MEMORY storage engine's volatility — candidates focus on CPU spikes and failover, missing that the real issue is a non-persistent storage engine losing data on restart.
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
✓
Check the session table's storage engine; if it uses MEMORY, change it to InnoDB to persist data across restarts.
The MEMORY storage engine in MySQL stores table data in RAM and loses all rows when the MySQL server restarts (e.g., during a crash, failover, or maintenance). The periodic CPU spikes and session loss without any TRUNCATE/DROP in the logs strongly indicate the session table is using MEMORY and being wiped on restart. Converting the table to InnoDB persists data to disk and survives restarts, resolving the issue.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Enable Multi-AZ deployment for RDS to improve availability and prevent data loss during failover.
Why it's wrong here
Enabling Multi-AZ deployment for an Amazon RDS instance primarily enhances database availability by automatically failing over to a synchronous standby replica in a different Availability Zone during an outage of the primary. While this minimizes downtime, it does not inherently guarantee data persistence if the underlying storage engine of the session table itself is non-durable, such as the MEMORY engine. Data stored in a volatile engine would still be lost upon a primary instance restart or crash, even with Multi-AZ configured, as the issue lies with data durability, not just instance availability.
- ✗
Increase the RDS instance size to handle the CPU spikes and prevent future issues.
Why it's wrong here
Increasing the RDS instance size (scaling up) provides more computational resources like CPU, memory, and I/O throughput, which can certainly help alleviate CPU spikes and improve overall database performance under heavy load. However, this action addresses resource capacity, not the fundamental issue of data persistence. If the session data is stored in a non-durable storage engine, simply adding more hardware resources will not prevent that data from being lost whenever the database instance restarts or encounters an unexpected shutdown.
- ✗
Disable RDS Proxy and implement connection pooling in the application code to reduce database load.
Why it's wrong here
AWS RDS Proxy is a managed service designed to improve application resilience and reduce database load by efficiently pooling and managing database connections, especially beneficial for serverless applications or those with fluctuating connection demands. Disabling RDS Proxy and relying solely on application-side connection pooling might actually increase the connection overhead and potentially the database load, depending on the application's implementation. RDS Proxy is a solution for connection management and scalability, not a cause of data loss related to storage engine durability.
- ✓
Check the session table's storage engine; if it uses MEMORY, change it to InnoDB to persist data across restarts.
Why this is correct
The MEMORY storage engine in MySQL stores all table data in RAM, providing extremely fast access but making the data volatile; any database restart, instance reboot, or crash will result in the complete loss of all data within these tables. Conversely, the InnoDB storage engine is ACID-compliant, writes data to disk, and includes robust crash recovery mechanisms, ensuring data persistence even after unexpected shutdowns. Changing the session table's engine to InnoDB directly addresses the problem of data loss upon restarts by making the data durable.
Visual reference
Go deeper
Related to this question
About these practice questions
This DVA-C02 question is part of Courseiva's 1,135-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 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.