Request and response mapping in AWS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

How does AWS API Gateway transform a request with mapping templates?

You have an AWS API Gateway method with a request mapping template that extracts the 'userId' from the incoming JSON body and passes it as a path parameter to the backend. What will be the value of the path parameter 'userId' if the incoming request body is {"userId": "12345", "action": "login"}?

AWS

{
  "userId": "$input.path('$.userId')"
}

A The path parameter 'userId' will be set to '12345'.

B The path parameter 'userId' will be set to 'action'.

C The path parameter 'userId' will be empty because the mapping template is invalid.

D The path parameter 'userId' will be set to '{"userId": "12345", "action": "login"}'.

💡 Hint

Think about how JSON path expressions extract values from the input JSON.

The mapping template uses $input.path('$.userId') which extracts the value of the 'userId' key from the JSON body. Since the input JSON has 'userId' set to '12345', the path parameter will be set to '12345'.

❓ Configuration

intermediate

Identify the correct response mapping template for a JSON error response

You want to map a backend error JSON response {"errorCode": "404", "message": "Not Found"} to a client response with status code 404 and a body containing only the message. Which response mapping template achieves this?

A

#set($inputRoot = $input.path('$'))
{
  "message": "$inputRoot.message"
}

B

{
  "error": "$input.path('$.errorCode')",
  "msg": "$input.path('$.message')"
}

C

#set($inputRoot = $input.path('$'))
{
  "errorMessage": "$inputRoot.errorCode"
}

D

{
  "message": "$input.path('$.errorMessage')"
}

💡 Hint

Look for the template that extracts the 'message' field correctly and formats the response body accordingly.

Option A correctly sets a variable to the root of the input JSON and then outputs only the 'message' field in the response body. Other options either extract wrong fields or format incorrectly.

❓ Architecture

advanced

Which architecture best supports dynamic request mapping for multiple backend services?

You need to design an API Gateway setup that routes requests to different backend services based on a request header value, and applies different request mapping templates accordingly. Which architecture pattern is best?

A Use a single API Gateway with multiple stages, each stage having its own mapping templates and backend integration.

B Use multiple API Gateways, each dedicated to one backend service with fixed mapping templates.

C Use a single API Gateway with multiple resources and methods, each configured with specific request mapping templates and backend integrations, and use request header-based mapping to select the resource.

D Use a single API Gateway with a Lambda authorizer that modifies the request and sets integration request parameters dynamically.

💡 Hint

Consider how API Gateway resources and methods can be configured to handle different request mappings and routing.

Option C uses multiple resources and methods within a single API Gateway, each with its own mapping templates and backend integrations. Request header-based mapping can be used to route requests to the correct resource. This is scalable and manageable.

❓ security

advanced

What security risk arises from improper request mapping in API Gateway?

If an API Gateway request mapping template does not properly validate or sanitize incoming JSON fields before passing them to the backend, what is the most likely security risk?

A Data loss because the mapping template deletes fields from the request.

B Denial of service due to large payloads being accepted by the mapping template.

C Unauthorized access because the mapping template bypasses authentication.

D Injection attacks such as SQL injection or command injection on the backend service.

💡 Hint

Think about what happens if malicious input is passed unchecked to backend services.

Improper validation or sanitization in request mapping can allow attackers to inject malicious code or queries, leading to injection attacks on backend services.

✅ Best Practice

expert

What is the best practice for managing complex response mapping templates in AWS API Gateway?

You have a complex backend response that requires multiple conditional transformations before sending to clients. What is the best practice to manage this complexity in API Gateway response mapping?

A Split the API Gateway method into multiple methods each handling a part of the transformation.

B Use a Lambda function as a proxy integration to handle response transformation outside API Gateway.

C Embed all logic directly in the response mapping template using Velocity Template Language (VTL) with nested conditionals.

D Disable response mapping and send backend responses directly to clients.

💡 Hint

Consider maintainability and complexity of VTL templates versus external processing.

Complex transformations are better handled in Lambda functions where code is easier to write, test, and maintain. Embedding complex logic in VTL is error-prone and hard to maintain.

Practice

1. What is the main purpose of request and response mapping in AWS API Gateway?

easy

A. To encrypt data during transmission

B. To change data formats between client and backend

C. To monitor user activity on the website

D. To store data permanently in the cloud

Solution

1. Step 1: Understand the role of mapping templates

   Mapping templates in API Gateway transform data formats between client requests and backend responses.

2. Step 2: Identify the main purpose

   This transformation allows different systems to communicate smoothly by renaming, adding, or removing fields.

3. Final Answer:

   To change data formats between client and backend -> Option B

4. Quick Check:

   Mapping templates = data format change [OK]

Hint: Mapping templates transform data formats between client and backend [OK]

Common Mistakes:

• Confusing mapping with data storage
• Thinking mapping encrypts data
• Assuming mapping monitors activity

2. Which of the following is the correct syntax to access a JSON field named userId in a request mapping template?

easy

A. $input.path('$.userId')

B. $input.json('userId')

C. $input.get('userId')

D. $input.body('userId')

Solution

1. Step 1: Recall JSON path syntax in mapping templates

   The correct way to access a JSON field is using $input.path('$.fieldName').

2. Step 2: Match the syntax to the field userId

   Using $input.path('$.userId') correctly accesses the userId field.

3. Final Answer:

   $input.path('$.userId') -> Option A

4. Quick Check:

   JSON field access = $input.path('$.field') [OK]

Hint: Use $input.path('$.fieldName') to access JSON fields [OK]

Common Mistakes:

• Using incorrect method names like json or get
• Missing the '$.' prefix in JSON path
• Confusing body access with path access

3. Given this request mapping template:

{
  "user": "$input.path('$.username')",
  "id": "$input.path('$.userId')"
}

What will be the transformed request if the client sends:

{"username": "alice", "userId": "123"}

medium

A. {"user": "$.username", "id": "$.userId"}

B. {"username": "alice", "userId": "123"}

C. {"user": "alice", "id": "123"}

D. {"user": null, "id": null}

Solution

1. Step 1: Understand the mapping template fields

   The template maps user to $.username and id to $.userId.

2. Step 2: Apply the client JSON values

   Client sends username as "alice" and userId as "123", so these replace the template placeholders.

3. Final Answer:

   {"user": "alice", "id": "123"} -> Option C

4. Quick Check:

   Template fields replaced by client values [OK]

Hint: Mapping replaces template fields with client JSON values [OK]

Common Mistakes:

• Confusing template keys with client keys
• Leaving placeholders as literal strings
• Assuming null values when fields exist

4. You have this response mapping template:

{
  "message": "$input.path('$.msg')",
  "status": "$input.path('$.code')"
}

But the backend returns:

{"message": "Success", "code": 200}

What is the main issue causing the mapping to fail?

medium

A. The template uses wrong JSON paths not matching backend keys

B. The backend response is not valid JSON

C. The template syntax is missing quotes around keys

D. The backend response keys are case-insensitive

Solution

1. Step 1: Compare template paths with backend keys

   The template expects msg and code, but backend returns message and code.

2. Step 2: Identify mismatch causing failure

   Since msg does not exist in backend response, mapping fails for that field.

3. Final Answer:

   The template uses wrong JSON paths not matching backend keys -> Option A

4. Quick Check:

   Template paths must match backend keys exactly [OK]

Hint: Ensure template JSON paths match backend response keys exactly [OK]

Common Mistakes:

• Assuming backend keys are case-insensitive
• Thinking syntax errors cause this issue
• Ignoring key name mismatches

5. You want to add a new field requestTime with the current timestamp to every request sent to your backend using request mapping. Which mapping template snippet correctly adds this field?

hard

A. {
"user": "$input.path('$.user')",
"requestTime": "$context.stage"
}

B. {
"user": "$input.path('$.user')",
"requestTime": "$input.requestTime"
}

C. {
"user": "$input.path('$.user')",
"requestTime": "$stageVariables.requestTime"
}

D. {
"user": "$input.path('$.user')",
"requestTime": "$context.requestTime"
}

Solution

1. Step 1: Identify how to get current request time

   In API Gateway mapping templates, $context.requestTime provides the current request timestamp.

2. Step 2: Check each option for correct usage

   { "user": "$input.path('$.user')", "requestTime": "$context.requestTime" } uses $context.requestTime correctly; others use invalid or unrelated variables.

3. Final Answer:

   { "user": "$input.path('$.user')", "requestTime": "$context.requestTime" } -> Option D

4. Quick Check:

   Use $context.requestTime for current timestamp [OK]

Hint: Use $context.requestTime to add current timestamp in mapping [OK]

Common Mistakes:

• Using $input.requestTime which doesn't exist
• Confusing stage variables with request time
• Using unrelated context variables