Courseiva
Development with AWS ServiceshardMultiple ChoiceObjective-mapped

DVA-C02 Development with AWS Services Practice Question

A developer is building a serverless application using AWS Lambda and Amazon API Gateway REST API. The API Gateway is configured to use a Lambda proxy integration. The developer wants to return a custom error message with a specific HTTP status code (e.g., 404) when a resource is not found. How should the developer implement this?

⚠ Common exam trap

Many candidates confuse the Lambda proxy integration response format with the standard Lambda error response format (errorMessage/errorType) or assume that simply throwing an exception will propagate the status code, but AWS requires a specific structured success response to control the HTTP status code.

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

Return a JSON object with keys 'statusCode', 'headers', and 'body' where 'statusCode' is 404 and 'body' contains the error message.

With Lambda proxy integration in API Gateway, the Lambda function must return a response in the exact format that API Gateway expects: a JSON object with 'statusCode' (integer), 'headers' (object), and 'body' (string). This allows the developer to set a custom HTTP status code like 404 and include a custom error message in the body. API Gateway will then map this response directly to the HTTP response sent to the client.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • Return a JSON object with 'status_code' and 'message' keys.

    Why it's wrong here

    When using API Gateway Lambda proxy integration, the Lambda function's response must adhere to a precise JSON structure. Using `status_code` (snake_case) instead of `statusCode` (camelCase) and `message` instead of `body` will cause API Gateway to treat the response as an invalid format. Consequently, API Gateway will return a default 500 Internal Server Error, rather than the intended custom status code and message to the client.

  • Throw an exception with a message that includes the HTTP status code.

    Why it's wrong here

    Throwing an unhandled exception within a Lambda function configured for API Gateway proxy integration will result in API Gateway returning a 502 Bad Gateway error. This occurs because API Gateway interprets the exception as an unexpected function failure, preventing the custom status code and error message from being propagated to the client. The proxy integration expects a structured JSON response, not an exception, to control the HTTP response.

  • Return a JSON object with 'errorMessage' and 'errorType' keys.

    Why it's wrong here

    The JSON format `{ 'errorMessage': '...', 'errorType': '...' }` is specifically used by AWS Lambda to report function errors when *not* using API Gateway Lambda proxy integration, or when using a non-proxy integration. In a proxy integration scenario, API Gateway expects a specific response structure containing `statusCode`, `headers`, and `body` to directly control the HTTP response. Returning this error format will not be correctly parsed by API Gateway, leading to a default 500 Internal Server Error.

  • Return a JSON object with keys 'statusCode', 'headers', and 'body' where 'statusCode' is 404 and 'body' contains the error message.

    Why this is correct

    For API Gateway Lambda proxy integration, the Lambda function must return a JSON object with the exact structure `{ 'statusCode': <number>, 'headers': <object>, 'body': <string> }`. This specific format allows the Lambda function to fully control the HTTP response returned to the client, including the status code (e.g., 404 Not Found), custom headers, and the response body containing the error message. Adhering to this contract ensures API Gateway correctly maps the Lambda's output to the desired HTTP response.

Quick reference

Cloud Service Model Comparison

ModelYou ManageProvider ManagesExamples
IaaSOS, runtime, apps, dataHardware, hypervisor, networkingEC2, Azure VMs, GCP Compute Engine
PaaSApps and dataOS, runtime, middleware, hardwareElastic Beanstalk, Azure App Service
SaaSData and settings onlyEverything elseMicrosoft 365, Salesforce, Workday
FaaS / ServerlessFunction code onlyInfra, scaling, runtimeLambda, Azure Functions, Cloud Run
CaaSContainers and appsKubernetes, OS, hardwareEKS, AKS, GKE

About these practice questions

This DVA-C02 question is part of Courseiva's 724-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 →

How Courseiva writes practice questions · Editorial policy

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.