Jeff’s Note #
Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.
For DVA-C02 candidates, the confusion often lies in how to handle synchronous vs. asynchronous Lambda invocations via API Gateway. In production, this is about knowing exactly which invocation type to configure to achieve immediate API responses without blocking the client. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
A software team at Veridium Solutions created a serverless web application that lets users upload and process detailed financial reports. The frontend UI provides users a button to submit a file for processing and expects to immediately notify them that their job is started. The backend uses AWS Step Functions orchestrating multiple Lambda functions to parse, calculate, and generate report summaries. The UI relies on an API built with Amazon API Gateway integrated directly with Lambda functions to support these user actions.
Recently, the frontend team reported that when users submit large or complex reports, the API Gateway request times out, causing poor user experience. Their goal is for the API to provide an instant response confirming the task submission, allowing the UI to display a “processing started” message immediately. Meanwhile, the long-running backend processing should continue independently. Finally, an email notification should be sent when the report processing completes.
The Requirement #
What should the developer implement to enable the API Gateway to return an immediate response and let the backend process run asynchronously with an email notification sent upon completion?
The Options #
-
A) Change the API Gateway route to add an
X-Amz-Invocation-Typeheader with a static value of ‘Event’ in the integration request. Deploy the API Gateway stage to apply the changes. -
B) Change the configuration of the Lambda function that implements the request to process a file. Configure the maximum age of the event so that the Lambda function will run asynchronously.
-
C) Change the API Gateway timeout value to match the Lambda function timeout value. Deploy the API Gateway stage to apply the changes.
-
D) Change the API Gateway route to add an
X-Amz-Targetheader with a static value of ‘Async’ in the integration request. Deploy the API Gateway stage to apply the changes.
Google adsense #
leave a comment:
Correct Answer #
A
Quick Insight: The Developer Imperative #
- API Gateway synchronous integrations wait for Lambda to complete, causing timeouts with long-running tasks.
- Adding the
X-Amz-Invocation-Type: Eventheader triggers an asynchronous Lambda invocation — API Gateway immediately returns success while the Lambda executes independently.- This pattern decouples UI responsiveness from backend processing duration, exactly what is needed in this case.
Content Locked: The Expert Analysis #
You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?
The Expert’s Analysis #
Correct Answer #
Option A
The Winning Logic #
Lambda provides two invocation types: synchronous and asynchronous. By default, API Gateway invokes Lambda synchronously, meaning API Gateway waits until Lambda completes and returns output or times out. This tightly couples request duration to Lambda execution time, which leads to frontend timeouts if the processing is long.
Option A is correct because adding the X-Amz-Invocation-Type: Event header in the API Gateway integration request tells API Gateway to invoke Lambda asynchronously. This means the API returns a success response immediately without waiting for Lambda to finish. Lambda then processes the file independently in the background.
This design perfectly fits the requirement: the UI gets an instant confirmation that processing started, avoiding timeouts, while the backend can process complex jobs asynchronously. The Step Functions and Lambda can send a completion email independently by themselves.
The Trap (Distractor Analysis): #
-
Option B is invalid because “maximum age of the event” is not a Lambda configuration parameter controlling sync vs async invocations.
-
Option C is a common misconception—simply increasing API Gateway timeout won’t solve UI slowness or improve user experience. Plus, API Gateway maximum timeout is 29 seconds, insufficient for very long processing.
-
Option D is incorrect because
X-Amz-Targetis used for AWS service action targets, not for controlling invocation async behavior.
The Technical Blueprint #
# Example: Configure API Gateway Integration Request to invoke Lambda asynchronously
aws apigateway update-integration \
--rest-api-id abc123xyz \
--resource-id xyz789def \
--http-method POST \
--patch-operations op=add,path=/requestParameters/integration.request.header.X-Amz-Invocation-Type,value=Event
This CLI command adds the header instructing API Gateway to make async Lambda calls.
The Comparative Analysis #
| Option | API Complexity | Performance | Use Case |
|---|---|---|---|
| A | Adds header to invoke Lambda asynchronously | Immediate API response; Lambda runs in background | Best for decoupling UI from heavy processing |
| B | Misunderstands Lambda config parameters | No effect on async behavior | Incorrect; no such setting exists |
| C | Changes timeout config | Might increase wait but still sync | Marginal improvement; UX still poor |
| D | Misuses header for AWS service actions | No effect on invocation type | Wrong header use, no async invocation |
Real-World Application (Practitioner Insight) #
Exam Rule #
“For the exam, always pick ‘Event’ invocation type when you need asynchronous Lambda invocations via API Gateway.”
Real World #
“In production, you might also use EventBridge or SQS for more complex async workflows, but for a direct API Gateway to Lambda async call, the X-Amz-Invocation-Type header is the cleanest way.”
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the DVA-C02 exam.