DVA-C02 Troubleshooting and Optimization Practice Question
Network Topology
A developer invokes a Lambda function from the AWS CLI and receives the response shown in the exhibit. The output file contains an error message. What is the MOST likely cause of the FunctionError field being set to 'Unhandled'?
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 function code threw an uncaught exception.
The FunctionError field set to 'Unhandled' in a Lambda invocation response indicates that the function's code raised an uncaught exception during execution, so option C is correct. AWS Lambda returns this value when the runtime catches an error that the handler did not handle, and the error details appear in the response payload. Option A would typically cause logging failures rather than an 'Unhandled' FunctionError, and could even prevent error details from being logged. Option B is incorrect because the synchronous invocation payload limit is 6 MB, not 6 KB, and exceeding it produces a request validation error, not an 'Unhandled' FunctionError. Option D is incorrect because a timeout produces a different error type (for example, 'Task timed out after X seconds') rather than the generic 'Unhandled' value.
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 function's execution role does not have permission to write to CloudWatch Logs.
Why it's wrong here
If the function's execution role lacked permission to write to CloudWatch Logs, the Lambda service would still successfully invoke the function, resulting in a StatusCode 200. The function code would execute as normal, but its logs would simply not be delivered to CloudWatch. The FunctionError 'Unhandled' indicates an issue *within* the function's execution, not a failure to log or a permission issue preventing the invocation itself.
- ✗
The invocation request payload exceeded the 6 KB limit for synchronous invocation.
Why it's wrong here
The stated 6 KB limit is incorrect; the actual payload limit for synchronous Lambda invocations is 6 MB. If this 6 MB limit were exceeded, the Lambda service would reject the invocation request *before* the function even starts, returning an HTTP 413 (Payload Too Large) error. This would contradict the StatusCode 200 observed in the scenario, which signifies the invocation request was successfully received by the Lambda service.
- ✓
The function code threw an uncaught exception.
Why this is correct
When a Lambda function's code encounters an error that is not explicitly handled by the developer (e.g., via a try-catch block), it results in an uncaught exception. The Lambda runtime then terminates the execution, sets FunctionError: Unhandled in the response, and returns a StatusCode 200 to the invoker, indicating the service successfully processed the invocation request. The specific error message from this exception is then captured and written to the output file specified in the AWS CLI command.
- ✗
The function timed out before completing execution.
Why it's wrong here
A timeout would also result in 'Unhandled', but the most common cause is an uncaught exception. However, timeout is also possible. But the question asks 'most likely', and typically an uncaught exception is more common than timeout. Let me re-evaluate: The exhibit shows StatusCode 200, which means the Lambda service received the invocation. FunctionError 'Unhandled' means the function encountered an error that was not handled by the code. Both timeout and uncaught exception can cause this. But the stem says 'output file contains an error message', which suggests the function code threw an error. So option B is more specific.
Quick reference
Cloud Service Model Comparison
| Model | You Manage | Provider Manages | Examples |
|---|---|---|---|
| IaaS | OS, runtime, apps, data | Hardware, hypervisor, networking | EC2, Azure VMs, GCP Compute Engine |
| PaaS | Apps and data | OS, runtime, middleware, hardware | Elastic Beanstalk, Azure App Service |
| SaaS | Data and settings only | Everything else | Microsoft 365, Salesforce, Workday |
| FaaS / Serverless | Function code only | Infra, scaling, runtime | Lambda, Azure Functions, Cloud Run |
| CaaS | Containers and apps | Kubernetes, OS, hardware | EKS, AKS, GKE |
Go deeper
Related to this question
About these practice questions
Courseiva writes every DVA-C02 question from scratch — 1,135 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. 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.