Concurrency and performance tuning: DVA-C03 study notes and practice questions
What to know about Concurrency and performance tuning for the DVA-C03 exam, from the Troubleshooting and Optimization domain (22% of the exam guide), then 3 free questions to test it. Part of the DVA-C03 study guide.
These questions give a symptom, such as slow cold starts, throttling from one busy queue, or database connection errors, and ask for the setting that fixes it without overspending.
Lambda memory and CPU
Lambda allocates CPU in proportion to the memory you set. A CPU-bound function that uses only part of its memory can run faster with more memory, sometimes at the same cost because it finishes sooner. Compare runs at several memory sizes with the open-source AWS Lambda Power Tuning tool, which runs the function at each setting and reports cost and speed. Lambda Insights adds enhanced metrics for CPU, memory and network use. AWS Compute Optimizer recommends memory sizes from past runs.
Concurrency
Reserved concurrency sets a maximum for one function and holds that capacity for it. Reserve capacity so that other functions still get some, and remember that the limit causes throttling.
Provisioned concurrency keeps initialized environments ready, which removes cold starts. You pay for it all the time, so schedule it with Application Auto Scaling when demand follows a pattern.
SnapStart restores a snapshot of an initialized environment to cut cold starts without paying for idle capacity, which suits runtimes such as Java.
Connections and clients
Create SDK clients and database connections outside the handler, so warm invocations reuse them. Creating them inside the handler adds time to every call. A database with a connection limit needs RDS Proxy in front, which pools and reuses connections, so a traffic spike does not open hundreds of direct connections. Thread and connection pools play the same role in EC2 applications.
EC2 Auto Scaling
Auto Scaling adds and removes instances by policy. Target tracking keeps a metric near a target, such as average CPU. Scaling on the metric that limits the app, such as queue depth per instance, works better than CPU when the work waits on I/O. Cooldowns and warm-up settings stop the group reacting to every short spike.
AI and tuning tools
Compute Optimizer and Lambda Insights point out oversized functions. AI tools such as Kiro, or Amazon Q in the console, can suggest code changes for slow paths. Treat each suggestion as a hypothesis, and measure before and after.
How to choose
Scenario wording
Answer
“cheapest memory setting for a CPU-bound function”
Lambda Power Tuning
“remove cold-start latency on a schedule”
Provisioned concurrency with scheduled scaling
“one function must not starve the others”
Reserved concurrency
“Java cold start, no idle cost”
SnapStart
“database runs out of connections under spikes”
RDS Proxy
“each invocation creates a new client”
Move the client outside the handler
Common traps
Adding memory to a function that is not CPU-bound. It costs more and gains little.
Reserved concurrency as a speed boost. It caps and holds capacity; it does not make code faster.
Provisioned concurrency for rare traffic. It costs money while idle.
An online ticketing API runs a Node.js Lambda function behind Amazon API Gateway.
Demand jumps every weekday at 09:00, and users must see consistently low latency from the first request, without paying for that capacity all day. The API calls the function through an alias named live, which points to a published version.
What should the developer configure?
Choose one answer.
AA. Provisioned concurrency set on $LATEST, with a scheduled scaling action that raises it at 08:45 each weekday.
BB. Reserved concurrency set to the expected 09:00 peak, so that enough environments exist for the burst.
CC. Provisioned concurrency on the live alias, raised by a scheduled action before 09:00 and lowered afterwards.
DD. SnapStart turned on for the function, since it removes cold starts for every invocation.
Show the answer and explanation
Answer: C
A. Wrong: Provisioned concurrency cannot be set on $LATEST, only on a published version or an alias. The schedule would never take effect on the function the API calls.
B. Wrong: Reserved concurrency limits how many environments a function can use, and it does not start any in advance. The first requests at 09:00 would still hit cold starts.
D. Wrong: SnapStart supports Java, Python and .NET runtimes, not Node.js. It also reduces startup time without guaranteeing low latency for every request.
Explanation
Provisioned concurrency pre-initializes execution environments for a published version or alias, and a scheduled action can raise it before a predictable peak. Reserved concurrency only limits capacity. SnapStart does not support Node.js, and it is not a guaranteed cold-start fix.
An image-resizing Lambda function is set to 256 MB of memory.
CloudWatch shows that it uses only about 150 MB, but each run is slow because the resize work is CPU-bound. The developer wants the function to finish faster, with the least effort and no change to the code's logic.
What should the developer do?
Choose one answer.
AA. Reduce the memory to 160 MB, because the function does not use the rest of it.
BB. Increase the function timeout so that it has more time to finish.
CC. Add reserved concurrency so that each invocation gets a dedicated CPU.
DD. Increase the memory setting, which also increases the CPU that Lambda allocates.
Show the answer and explanation
Answer: D
A. Wrong: Less memory also means less CPU, so the function would run more slowly. Memory use is not the same as the memory setting that controls CPU.
B. Wrong: A longer timeout only allows a run to last longer. It does not make the CPU-bound work finish sooner.
C. Wrong: Reserved concurrency limits how many invocations can run at once. It does not allocate CPU to any one invocation.
Lambda has no separate CPU setting, because CPU is allocated in proportion to memory. A CPU-bound function therefore often runs faster when its memory is raised, even if its memory use is low. Tools such as AWS Lambda Power Tuning can find the cheapest setting that gives the best speed.
A Lambda function is invoked about 500 times a minute.
Each invocation creates a new AWS SDK client and a new database connection inside the handler. CloudWatch shows that most of the warm-invocation duration is spent creating them. Database connections must stay within the database's limit, and no user data may be kept between invocations.
What should the developer change?
Choose one answer.
AA. Create the SDK client and database connection outside the handler, so warm invocations reuse them.
BB. Store the connection object in an environment variable so that later invocations can read it.
CC. Raise the function's reserved concurrency, so that more execution environments are created.
DD. Move the setup code into a Lambda layer, so that it runs before the handler starts.
B. Wrong: Environment variables hold strings, not live connection objects. They are also set from configuration, not created during a run.
C. Wrong: More execution environments means more open connections to the database, which works against its connection limit. It does not remove the setup cost either.
D. Wrong: A layer packages files and libraries. It does not run setup code before the handler, so the connections would still be created on each invocation.
Explanation
Lambda reuses an execution environment between invocations, so initializing SDK clients and database connections outside the handler lets warm invocations skip that work. The same reuse is why per-user data must not be stored in module-level state.
Want more on Concurrency and performance tuning? The 5 full-length practice sets have 13 more Concurrency and performance tuning questions, 390 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →