All practice questions

1542 questions

All types1,542 Multiple choice782 Multiple select746 Ordering14

A smart grid monitoring application named VoltGuard collects hourly utility consumption metrics from millions of smart meters and writes the records to an Amazon DynamoDB table. The table is configured with provisioned write capacity and uses the hour of the reading (formatted as `YYYY-MM-DD-HH`) as the partition key, and the smart meter ID as the sort key. During the first few minutes of every hour, the application experiences a massive spike in write requests, leading to frequent `ProvisionedThroughputExceededException` errors, while the overall consumed capacity remains well below the table's total provisioned limits.

What is the most effective way to resolve these write throttling errors?

Increase the table's provisioned Write Capacity Units (WCUs) to accommodate the peak hourly write traffic.

Configure a longer visibility timeout for the Amazon SQS queue that processes the incoming meter readings.

Redesign the table schema to use the smart meter ID as the partition key and the timestamp of the reading as the sort key.

Configure the AWS SDK client to use static credentials with administrator access to bypass DynamoDB write limitations.

Show answer & explanation

Answer: Redesign the table schema to use the smart meter ID as the partition key and the timestamp of the reading as the sort key.

Answer

Redesign the table schema to use the smart meter ID as the partition key and the timestamp of the reading as the sort key.

Redesigning the table schema to use the smart meter ID as the partition key and the timestamp of the reading as the sort key distributes the write load across millions of distinct partition keys. This takes full advantage of DynamoDB's internal hashing to spread write requests across multiple physical partitions, preventing any single partition from becoming a bottleneck and eliminating the ProvisionedThroughputExceededException errors.

Step-by-Step Solution

Analyze CloudWatch metrics and application logs showing ProvisionedThroughputExceededException.

Identify that total consumed write capacity is low compared to the table's provisioned limit, indicating a key distribution issue (hot partition) rather than overall capacity exhaustion.

To pinpoint whether the issue is database-wide capacity starvation or partition-level bottlenecking.

Examine the current table schema partition key design.

Observe that using the date and hour (YYYY-MM-DD-HH) as the partition key forces all concurrent writes from millions of smart meters to target the exact same partition key value within that hour.

To understand the root cause of the hot partition key issue.

Select a high-cardinality attribute for the partition key.

Migrate the schema to use the smart meter ID as the partition key and the reading timestamp as the sort key, ensuring writes are distributed across a large pool of unique partitions.

To leverage DynamoDB's automatic partitioning mechanism for scale and uniform load distribution.

Key Concept

Resolving DynamoDB throttling issues by redesigning the partition key schema to utilize high-cardinality attributes.

Estimated Time:1m 30s

Question 522Question →

A developer is building a serverless processing system where an AWS Lambda function is triggered by an Amazon SQS queue. The function is configured to run inside the private subnets of a custom VPC to write processed results to an Amazon RDS database. During execution, the Lambda function needs to retrieve database credentials from AWS Secrets Manager. During initial testing, the database writes are successful, but the function fails to retrieve the credentials from AWS Secrets Manager, resulting in connection timeout errors. In addition, the developer notices that some SQS messages are being processed multiple times. Which two actions should the developer take to resolve these issues?

Select all that apply

Create an interface VPC endpoint for AWS Secrets Manager within the VPC, and configure the security groups to allow HTTPS traffic from the Lambda function.

Increase the visibility timeout of the Amazon SQS queue to be at least six times the timeout configuration of the Lambda function.

Move the Lambda function to the public subnets of the VPC and enable the auto-assign public IP setting in the function's configuration.

Increase the Lambda function's timeout configuration to be greater than the SQS queue's visibility timeout to prevent the execution context from recycling.

Modify the Lambda function's IAM execution role trust policy to allow the Secrets Manager service principal to assume the role.

Show answer & explanation

Answer: Create an interface VPC endpoint for AWS Secrets Manager within the VPC, and configure the security groups to allow HTTPS traffic from the Lambda function.; Increase the visibility timeout of the Amazon SQS queue to be at least six times the timeout configuration of the Lambda function.

Answer

Create an interface VPC endpoint for AWS Secrets Manager within the VPC, and increase the visibility timeout of the Amazon SQS queue to be at least six times the timeout configuration of the Lambda function.

To resolve the timeout connection to AWS Secrets Manager, the Lambda function running in the private subnet needs a route to the Secrets Manager service. Creating an interface VPC endpoint for Secrets Manager allows the private Lambda function to reach the service using internal AWS routing without traversing the public internet. To resolve the duplicate message processing, the SQS visibility timeout must be increased to be at least six times the Lambda function's timeout. This ensures that the message remains locked and invisible to other consumers while the function executes.

Step-by-Step Solution

Analyze the connection timeout to AWS Secrets Manager.

Identify that the Lambda function is in private subnets without public internet routing (no NAT Gateway) and cannot reach the public endpoint of AWS Secrets Manager.

Private VPC Lambda functions require a NAT Gateway or a VPC endpoint to reach public AWS services.

Determine the solution for secure private connection to Secrets Manager.

Select the option to create an interface VPC endpoint (PrivateLink) for Secrets Manager in the VPC.

An interface endpoint creates elastic network interfaces in the subnets to route traffic privately and securely to the service.

Analyze the duplicate message processing issue.

Determine that the SQS queue's visibility timeout is too short compared to the Lambda function execution time, allowing messages to be picked up by other workers.

SQS visibility timeout must be equal to or greater than the processing time (recommended to be at least 6 times the Lambda timeout) to prevent concurrent processing of the same message.

Key Concept

Configuring VPC connectivity for AWS Lambda and aligning SQS visibility timeouts with Lambda timeouts.

Question 523Question →

A financial transaction processor uses an AWS Lambda function to validate account balances against an Amazon DynamoDB table. The Lambda function is configured to run inside a private subnet of a VPC to comply with security standards. During peak load, the system experiences a high rate of database connection timeouts and latency spikes. An analysis reveals that the Lambda function is establishing a new connection to DynamoDB during every invocation, and the outbound traffic to DynamoDB is routed via a NAT Gateway, leading to high data processing costs.

Which combination of actions will resolve the latency issues and reduce data transfer costs?

Declare and initialize the DynamoDB client inside the Lambda handler function, and create an interface VPC endpoint for DynamoDB to bypass the NAT Gateway.

Declare and initialize the DynamoDB client outside the Lambda handler function, hardcode static credentials with minimum permissions in the client initialization, and configure a public NAT Instance.

Instantiate the DynamoDB client inside the Lambda handler function, attach an Internet Gateway directly to the private subnet, and configure a security group to allow inbound traffic from DynamoDB.

Declare and initialize the DynamoDB client outside the Lambda handler function, and create a gateway VPC endpoint for DynamoDB with a route table entry pointing to it from the private subnet.

Show answer & explanation

Answer: Declare and initialize the DynamoDB client outside the Lambda handler function, and create a gateway VPC endpoint for DynamoDB with a route table entry pointing to it from the private subnet.

Answer

Declare and initialize the DynamoDB client outside the Lambda handler function, and create a gateway VPC endpoint for DynamoDB with a route table entry pointing to it from the private subnet.

The correct solution involves defining and instantiating the DynamoDB client outside the handler function. AWS Lambda reuses the execution context for subsequent invocations, allowing global variables and connections to persist. This reduces the latency of establishing new TCP connections. Additionally, routing traffic to DynamoDB via a gateway VPC endpoint eliminates NAT Gateway transit costs and reduces network latency by keeping traffic within the AWS network.

Step-by-Step Solution

Move the initialization of the DynamoDB client out of the handler function and place it in the global scope (outside the handler).

The DynamoDB client is initialized once during the Lambda container initialization (cold start) and is reused across subsequent invocations within the same execution context.

Reusing the client enables TCP connection pooling and avoids the overhead of establishing a new connection on every single invocation.

Create a gateway VPC endpoint for DynamoDB in the VPC where the Lambda function resides.

The VPC endpoint provides private connectivity to DynamoDB within the AWS network.

This routing mechanism keeps the traffic internal to the AWS network, eliminating the need to send DynamoDB traffic through the NAT Gateway.

Update the route table associated with the private subnet to include a route targeting the DynamoDB gateway VPC endpoint.

Traffic directed to DynamoDB from resources in the private subnet is automatically routed through the gateway endpoint.

This removes NAT Gateway data processing charges and reduces connection latency.

Key Concept

Optimization of AWS Lambda execution context reuse for database connections, and the implementation of gateway VPC endpoints for cost-effective, secure private routing to AWS services.

Estimated Time:2m 0s

Question 524Question →

A developer is writing a Python application using the AWS SDK for Python (Boto3) to upload files to an Amazon S3 bucket. During local development, the application must use credentials from a shared credentials file under a profile named 'local-dev'. Once deployed to an Amazon ECS task on AWS Fargate, the application must assume the ECS task role to access the S3 bucket. The developer wants to avoid making any code changes when transitioning the application from the local environment to AWS Fargate. Which configuration approach should the developer use to meet these requirements?

Initialize the S3 client using `boto3.client('s3')` without specifying credentials or profiles in the code, and configure the `AWS_PROFILE` environment variable on the local workstation.

Initialize the S3 client by passing the profile name directly in the code using `boto3.Session(profile_name='local-dev').client('s3')`, and package the shared credentials file containing that profile inside the container image.

Store the local AWS access keys in the AWS Systems Manager Parameter Store, retrieve them programmatically on application startup, and initialize the client using `boto3.client('s3', aws_access_key_id=..., aws_secret_access_key=...)`.

Modify the trust policy of the ECS task execution role to trust the developer's local IAM user, and configure the application to dynamically call the AWS Security Token Service (STS) to assume the role on startup.

Show answer & explanation

Answer: Initialize the S3 client using `boto3.client('s3')` without specifying credentials or profiles in the code, and configure the `AWS_PROFILE` environment variable on the local workstation.

Answer

Initialize the S3 client using `boto3.client('s3')` without specifying credentials or profiles in the code, and configure the `AWS_PROFILE` environment variable on the local workstation.

Initializing the Boto3 client using the default configuration (without passing explicit credentials or profiles) ensures that the SDK uses its default credential provider chain. Setting the `AWS_PROFILE` environment variable on the local machine tells Boto3 to read from the local credentials file under the specified profile. When deployed to AWS Fargate, because that environment variable is not present, the credential chain naturally proceeds to search for ECS task role credentials, enabling a seamless transition without modifying the code.

Step-by-Step Solution

Understand the behavior of the default credential provider chain in the AWS SDK for Python (Boto3).

The SDK looks for credentials in a specific sequence: environment variables, shared credentials files, and finally instance/container metadata services.

This allows applications to resolve credentials dynamically based on their environment without modifying code.

Configure the local workstation to use the correct profile without hardcoding it.

Set the `AWS_PROFILE` environment variable to 'local-dev'. The Boto3 SDK default client initialization detects this environment variable and reads the corresponding credentials from `~/.aws/credentials`.

This ensures local development uses the correct IAM identity without embedding profile names in the application code.

Deploy the application to AWS Fargate using the default Boto3 client initialization.

On Fargate, the `AWS_PROFILE` variable is absent, so the Boto3 default chain automatically looks for credentials from the ECS task role via the container metadata service.

This achieves seamless transition between local development and production with zero code changes.

Key Concept

AWS SDK Default Credential Provider Chain Resolution

Estimated Time:1m 30s

Question 525Question →

A developer is optimizing a serverless application where an Amazon API Gateway REST API is integrated with an AWS Lambda function. Currently, the Lambda function performs validation on the incoming JSON request body to verify the existence of mandatory fields. If the validation fails, the Lambda function returns a custom error response. To reduce Lambda invocation costs and latency, the developer wants to reject invalid requests before they reach the backend. Which solution should the developer implement to meet these requirements?

Configure request validation in API Gateway by creating a model that defines the required fields using JSON Schema, and enable request body validation on the method.

Configure the API Gateway method to use a Lambda proxy integration, which automatically parses and validates the structure of the incoming JSON payload before invoking the backend function.

Configure a custom Lambda authorizer for the API Gateway method to inspect the request body and reject requests with missing fields before the main backend Lambda function is invoked.

Configure Cross-Origin Resource Sharing (CORS) headers in API Gateway and set the Access-Control-Allow-Headers to restrict access to requests containing only the required fields.

Show answer & explanation

Answer: Configure request validation in API Gateway by creating a model that defines the required fields using JSON Schema, and enable request body validation on the method.

Answer

Configure request validation in API Gateway by creating a model that defines the required fields using JSON Schema, and enable request body validation on the method.

Configuring a Request Validator with a JSON Schema model directly on the API Gateway method allows API Gateway to perform the verification at the edge. If the payload does not contain the mandatory fields, API Gateway immediately blocks the request and returns a 400 Bad Request error. This prevents the request from triggering the integration, meaning the backend Lambda function is never executed, thereby saving invocation costs and reducing response latency for malformed requests.

Step-by-Step Solution

Define a JSON Schema model representing the required payload structure in API Gateway.

API Gateway has a representation of the expected fields and validation rules.

This sets up the rules needed to validate the incoming JSON object properties.

Associate the JSON Schema model with the method request and enable the request validator for the body.

API Gateway is configured to intercept incoming requests and validate them against the model.

This allows API Gateway to automatically reject requests that do not match the schema with a 400 Bad Request status code, preventing the backend Lambda function from being invoked.

Key Concept

API Gateway Request Validation

Question 526Question →

A developer is designing a high-throughput REST API using Amazon API Gateway. The API must integrate directly with an external HTTP backend via an HTTP integration. The incoming client request is a POST request with a JSON payload containing a tenantId field in the root of the document. The external HTTP backend requires the tenantId to be passed as a path parameter in the request URL (for example, /tenants/{tenantId}/events). To minimize latency and operational costs, the developer must implement this transformation without using an intermediate AWS Lambda function. Which configuration should the developer use to dynamically map the tenantId from the JSON request body to the HTTP integration request path?

Map the path parameter in the Integration Request settings directly to the Method Request body parameter using the mapping expression method.request.body.tenantId.

Create an API Gateway request mapping template for the integration. Extract the value using

input.path('

.tenantId') and override the integration path parameter by setting #set(

context.requestOverride.path.tenantId =

input.path('$.tenantId')).

Reference the JSON body parameter directly in the Integration Endpoint URL by using the dynamic path template https://backend.example.com/tenants/{

input.path('

.tenantId')}/events.

Configure a custom Lambda authorizer to parse the incoming request body, extract the tenant ID, and return it in the authorizer context to be mapped in the Integration Request parameter settings.

Show answer & explanation

Answer: Create an API Gateway request mapping template for the integration. Extract the value using $input.path('$ .tenantId') and override the integration path parameter by setting #set( $context.requestOverride.path.tenantId =$ input.path('$.tenantId')).

Answer

Create an API Gateway request mapping template for the integration, extract the value using the VTL path helper, and override the path parameter via the request override context context variable.

The correct approach is to create a request mapping template that extracts the value using

input.path('

.tenantId') and overrides the path parameter via

context.requestOverride.path.tenantId. Amazon API Gateway supports mapping overrides through the

context.requestOverride context variable in VTL mapping templates. This feature allows developers to dynamically change request paths, query strings, and headers based on the request payload without relying on Lambda functions, maintaining low latency and lower cost.

Step-by-Step Solution

Define an API Gateway request mapping template (e.g., for application/json) in the Integration Request settings.

Allows VTL logic to run during the request phase before forwarding to the backend.

Mapping templates are required to inspect, parse, or manipulate the incoming request payload.

Extract the value of the tenantId property from the JSON request payload.

Use

input.path('

.tenantId') within the VTL mapping template to capture the client-supplied tenant identifier.

The $input.path() utility function is the standard method for parsing JSON bodies in API Gateway mapping templates.

Override the path parameter dynamically using $context.requestOverride.

Apply #set(

context.requestOverride.path.tenantId =

input.path('$.tenantId')) inside the template.

The $context.requestOverride object allows developers to dynamically modify or inject integration request parameters (headers, query parameters, or paths) directly from within mapping templates, removing the need for a helper Lambda function.

Key Concept

API Gateway Integration Request Parameter Overrides via VTL

Estimated Time:3m 0s

Question 527Question →

A developer is building a serverless backend using Amazon API Gateway and AWS Lambda. The API Gateway REST API is configured with a Lambda custom (non-proxy) integration. When the client sends invalid input, the Lambda function throws an exception with the error message: `[ValidationFailed] User age is under the legal limit`. The developer wants API Gateway to return a `400 Bad Request` HTTP response with a custom JSON payload when this error occurs. Which configuration steps must the developer perform in API Gateway to achieve this?

Configure a Method Response for the 400 status code. In the Integration Response, configure an entry with a Lambda Error Regex pattern set to `.*ValidationFailed.*`, map it to the 400 Method Response, and define a body mapping template to customize the returned JSON payload.

Enable Lambda proxy integration, and configure an Integration Response with a Lambda Error Regex pattern set to `.*ValidationFailed.*` to map the exception to a 400 Method Response.

Configure a custom Lambda authorizer on the method to validate the input payload, and set the Gateway Response for 400 bad requests to transform the exception message.

Define the regex pattern `.*ValidationFailed.*` directly in the Method Response configuration, and map the matching pattern to the integration request body mapping template to mock the response without executing the Lambda function.

Show answer & explanation

Answer: Configure a Method Response for the 400 status code. In the Integration Response, configure an entry with a Lambda Error Regex pattern set to `.*ValidationFailed.*`, map it to the 400 Method Response, and define a body mapping template to customize the returned JSON payload.

Answer

Configure a Method Response for the 400 status code, create an Integration Response with a Lambda Error Regex matching the error message (such as `.*ValidationFailed.*`), link it to the 400 Method Response, and define a body mapping template.

The correct answer correctly outlines the requirements for mapping Lambda errors to custom HTTP responses in a non-proxy (custom) integration. This involves: 1) Declaring the HTTP status code (400) in the Method Response. 2) Creating an Integration Response with a selection pattern regex (such as `.*ValidationFailed.*`) that matches the Lambda function's error message. 3) Specifying a VTL mapping template to shape the output payload returned to the client.

Step-by-Step Solution

Define the HTTP status code in the Method Response configuration.

The API Gateway Method is registered as capable of returning a 400 Bad Request status code to the client.

Before an Integration Response can map an output to a status code, that status code must first be declared in the Method Response.

Create an Integration Response entry and set the Lambda Error Regex selection pattern.

The selection pattern evaluates the `errorMessage` property of the JSON payload returned by Lambda (e.g. matching `.*ValidationFailed.*`).

API Gateway matches the regex pattern against the string returned in the Lambda error's `errorMessage` header or payload to select the correct integration response.

Associate the Integration Response entry with the 400 Method Response and define a body mapping template.

API Gateway transforms the Lambda error JSON (containing `errorMessage`, `errorType`, `stackTrace`) into the custom client-facing JSON structure.

This shapes the response payload to match client expectations, hiding internal stack traces and presenting a clean error format.

Key Concept

API Gateway integration and response mapping patterns for Lambda non-proxy integrations

Question 528Question →

A developer is building an AWS Lambda function that retrieves customer order history from an Amazon DynamoDB table. The orders are retrieved based on a specific `CustomerID` and filtered by order status. To connect to the database, the developer has hardcoded the access keys of an IAM user directly inside the Lambda function's code. During load testing, the application experiences high latency and receives `ProvisionedThroughputExceededException` errors when retrieving orders, even though the total read capacity units (RCU) of the table are not fully utilized. The logs indicate that the application is performing a sequential `Scan` operation to find the customer's records. Which two actions should the developer take to resolve these security and performance issues? (Select TWO.)

Select all that apply

Perform a `Query` operation instead of a `Scan` operation, specifying the `CustomerID` as the partition key in the key condition expression.

Remove the hardcoded IAM user access keys from the function code, assign an IAM execution role with the required DynamoDB permissions to the Lambda function, and rely on the default SDK credential provider chain to assume the role.

Apply a filter expression on `CustomerID` while keeping the `Scan` operation to reduce the number of Read Capacity Units (RCUs) consumed by the database.

Store the IAM user access keys in an Amazon S3 bucket, and configure the Lambda function to download and load them into the environment variables at startup.

Enable strongly consistent reads on the `Scan` operation to improve retrieval performance and decrease the overall RCU consumption.

Show answer & explanation

Answer: Perform a `Query` operation instead of a `Scan` operation, specifying the `CustomerID` as the partition key in the key condition expression.; Remove the hardcoded IAM user access keys from the function code, assign an IAM execution role with the required DynamoDB permissions to the Lambda function, and rely on the default SDK credential provider chain to assume the role.

Answer

Perform a Query operation instead of a Scan operation, specifying the CustomerID as the partition key in the key condition expression, and remove the hardcoded IAM user access keys from the function code, assign an IAM execution role with the required DynamoDB permissions to the Lambda function, and rely on the default SDK credential provider chain.

Querying by partition key directly locates the customer's orders, significantly reducing latency and RCU usage. Removing hardcoded keys and using an IAM execution role is the recommended security practice for AWS Lambda.

Step-by-Step Solution

Analyze performance bottleneck

The application uses a Scan operation with a filter expression, which reads the entire table and discards non-matching items, wasting RCUs and causing latency/throttling.

To fix this, the developer must switch to a Query operation which directly targets the specific CustomerID partition key.

Analyze security issue

The developer has hardcoded long-term IAM access keys inside the Lambda code, which violates AWS security best practices.

The developer must remove these keys and associate an IAM execution role with DynamoDB permissions to the Lambda function, letting the SDK dynamically fetch temporary credentials.

Key Concept

Using Query instead of Scan for key-based retrieval, and utilizing Lambda execution roles for secure AWS service access.

Estimated Time:1m 30s

Question 529Question →

A financial services company uses an Amazon SNS topic to publish transaction notifications. One of the subscribers is an Amazon SQS standard queue that triggers an AWS Lambda function to write transaction details to an Amazon DynamoDB table. The Lambda function is configured with a timeout of $25$ seconds. The event source mapping is configured with a Batch Size of $20$ messages and a Maximum Batching Window (`MaximumBatchingWindowInSeconds`) of $15$ seconds. During high-traffic periods, the DynamoDB table experiences temporary write throttling, which in turn causes the Lambda function to be throttled. The developer observes that many transactions are processed and written to the database multiple times, creating duplicate entries. The current Visibility Timeout of the SQS queue is set to $45$ seconds. Which of the following is the root cause of these duplicate entries, and what is the correct configuration to resolve the issue?

The queue's Visibility Timeout is too short, allowing messages to become visible to other function instances while Lambda retries throttled invocations. The developer should increase the SQS queue's Visibility Timeout to at least

165

seconds.

The Lambda function is experiencing execution context reuse and timing out due to accumulated stateful connection pools. The developer should increase the Lambda timeout to

165

seconds and configure the function to re-initialize the DynamoDB client inside the handler, keeping the queue's Visibility Timeout at

45

seconds.

The Lambda function's DynamoDB SDK client is initialized with hardcoded AWS access keys that expire periodically. When credentials expire, the SDK fails to write and Lambda retries, causing duplicate processing. The developer should remove the hardcoded keys, use the Lambda execution role, and decrease the SQS Visibility Timeout to

25

seconds to match the Lambda timeout.

The Lambda function is deployed in a private subnet without a NAT Gateway or VPC Endpoint to access DynamoDB, causing the database writes to fail silently and trigger retries. The developer should deploy a NAT Gateway in the public subnet and set the queue's Visibility Timeout to

40

seconds, which is the sum of the Lambda timeout and the batching window.

Show answer & explanation

Answer: The queue's Visibility Timeout is too short, allowing messages to become visible to other function instances while Lambda retries throttled invocations. The developer should increase the SQS queue's Visibility Timeout to at least $165$ seconds.

Answer

165

seconds.

The correct configuration is to increase the SQS queue's Visibility Timeout to at least

165

seconds. Under the AWS Lambda integration model for SQS, the visibility timeout should be configured to at least 6 times the Lambda function's timeout (

6 \times 25 = 150

seconds) plus the maximum batching window (

15

seconds), resulting in

165

seconds. This configuration provides a sufficient buffer for the Lambda service to retry throttled invocations before the SQS messages become visible to other consumer instances.

Step-by-Step Solution

Analyze the relationship between SQS Visibility Timeout and Lambda Timeout.

Identify that AWS recommends setting the SQS Visibility Timeout to at least 6 times the Lambda Timeout to allow for retries in case of function throttling.

Throttled Lambda invocations are retried automatically, and the visibility timeout must remain in effect during these retries to prevent other instances from processing the same messages.

Incorporate the Maximum Batching Window into the calculation.

The minimum Visibility Timeout is calculated as:

\text{Visibility Timeout} \geq 6 \times \text{Lambda Timeout} + \text{MaximumBatchingWindowInSeconds}

Messages can spend up to the maximum batching window length in the queue before Lambda starts processing them, which reduces the active visibility period.

Perform the calculation using the given values (

25

seconds Lambda timeout,

15

seconds batching window).

6 \times 25 + 15 = 150 + 15 = 165

seconds.

Determines the exact threshold required to solve the duplicate processing issue.

Key Concept

Amazon SQS Visibility Timeout calculation for AWS Lambda event source mapping with batching windows

Estimated Time:3m 0s

Question 530Question →

A developer is maintaining a legacy REST API in Amazon API Gateway that integrates with an AWS Lambda function using a Lambda custom (non-proxy) integration. When client input fails validation, the Lambda function throws an exception returning the string `[ValidationFailed] Input values must be alphanumeric`. Currently, the client receives a 200 OK response with the error message in the payload. The developer wants the API to return an HTTP 400 Bad Request status code and a JSON payload containing only the error message when validation fails.

Which configuration steps should the developer perform to return the correct error response to the client?

Define a 400 Method Response for the API method. In the Integration Response configuration, add a new response with the Lambda Error Regex set to `.*ValidationFailed.*`, map it to the 400 Method Response, and define a body mapping template to extract and format the error message.

Enable Lambda Proxy Integration for the API method. Modify the Lambda function to throw the `[ValidationFailed]` exception so that API Gateway automatically maps the exception type to an HTTP 400 Bad Request status code.

Create a custom Lambda Authorizer for the API. Configure the authorizer to inspect the incoming request parameters, throw a validation exception if they are not alphanumeric, and map the authorizer output to an HTTP 400 response.

Define a 400 Method Response. In the Integration Request configuration, create a mapping template for the Content-Type `application/json` that maps the Lambda error string `.*ValidationFailed.*` to an HTTP 400 status code.

Show answer & explanation

Answer: Define a 400 Method Response for the API method. In the Integration Response configuration, add a new response with the Lambda Error Regex set to `.*ValidationFailed.*`, map it to the 400 Method Response, and define a body mapping template to extract and format the error message.

Answer

To map custom errors in a Lambda custom (non-proxy) integration, you must declare the target HTTP status code in the Method Response. Then, in the Integration Response, you define a regular expression matching the error pattern thrown by the Lambda function (such as `.*ValidationFailed.*`), select the corresponding Method Response status code, and configure a mapping template to format the output payload.

Step-by-Step Solution

Configure the Method Response in API Gateway to include the HTTP 400 status code.

The API method is prepared to return a 400 status code to client applications.

Method Responses define the valid HTTP status codes that API Gateway can send back to the client.

Configure the Integration Response in API Gateway by creating a new entry with the Lambda Error Regex set to `.*ValidationFailed.*`.

API Gateway will match errors containing the validation failure pattern returned from the Lambda function.

In non-proxy integrations, API Gateway checks the `errorMessage` field from the Lambda response against regular expressions to determine which Method Response to trigger.

Map the matching integration response to the 400 Method Response and add a response mapping template.

The validation error response is mapped to HTTP status 400 and its body is structured as JSON.

The mapping template extracts the error message and formats it into the clean JSON format required by the client.

Key Concept

Error mapping in API Gateway Lambda Custom (Non-Proxy) Integrations

Question 531Question →

A company is building a machine-to-machine (M2M) integration that allows an on-premises backend service to programmatically upload raw telemetry data to a private Amazon API Gateway endpoint. The developer needs to secure the API Gateway endpoint using Amazon Cognito. The backend service must authenticate using its credentials, obtain an access token, and use this token to authorize its API requests.

Which solution meets these requirements with the least operational overhead?

Configure an Amazon Cognito User Pool with a resource server and a user pool client configured with the client credentials grant. In Amazon API Gateway, configure a Cognito User Pool authorizer and set the OAuth scopes on the API method.

Configure an Amazon Cognito Identity Pool to federate the on-premises backend service. Use the developer-authenticated identities feature to generate temporary AWS credentials, and configure IAM authorization on the API Gateway endpoint.

Configure an Amazon Cognito User Pool with a resource server and a user pool client configured with the client credentials grant. In Amazon API Gateway, write a custom Lambda authorizer to decode, verify, and validate the signature of the Cognito JWT access token.

Configure an Amazon Cognito User Pool and create a user account for the on-premises service. Use the USER_PASSWORD_AUTH authentication flow to retrieve an ID token, and use an API Gateway Cognito User Pool authorizer to secure the method.

Show answer & explanation

Answer: Configure an Amazon Cognito User Pool with a resource server and a user pool client configured with the client credentials grant. In Amazon API Gateway, configure a Cognito User Pool authorizer and set the OAuth scopes on the API method.

Answer

The correct solution uses an Amazon Cognito User Pool with the client credentials grant to support machine-to-machine authentication. By defining a resource server with custom scopes, the backend service can retrieve a JWT access token. Securing the API Gateway is natively achieved by configuring a built-in Cognito User Pool authorizer and applying the custom OAuth scopes to the API method, which eliminates the need to write custom Lambda code or manage complex developer-authenticated identity flows.

Step-by-Step Solution

Set up a Cognito User Pool with a client credentials flow

Created a User Pool, defined a resource server with custom scopes, and enabled the client credentials grant on the app client.

This allows the on-premises machine/service to authenticate programmatically using its client ID and client secret, receiving a standard OAuth 2.0 JSON Web Token (JWT) access token containing the scopes.

Configure API Gateway Authorization

Created an API Gateway Cognito User Pool authorizer and associated it with the target API resource methods, specifying the custom OAuth scopes required to invoke them.

This offloads token validation to API Gateway's native authorizer, ensuring that only requests with a valid token containing the correct scopes are allowed to pass through to the backend.

Key Concept

Using Amazon Cognito User Pools for OAuth 2.0 client credentials grant and securing API Gateway with a built-in Cognito authorizer.

Question 532Question →

A flight scheduling application retrieves flight status details from an Amazon DynamoDB table using the flight number as the partition key. During peak holiday seasons, a sudden surge in search requests for a small set of popular flights causes a latency spike and throws ProvisionedThroughputExceededException errors. The developer needs to optimize the application's performance, achieving sub-millisecond read latency without rewriting the database access patterns or changing the primary key design. Which of the following solutions should the developer implement?

Increase the provisioned read capacity units (RCUs) on the DynamoDB table to handle the overall load, assuming the latency is due to table-wide limit constraints.

Replace the partition key queries with DynamoDB Scan operations containing a filter expression, and increase the provisioned read capacity units (RCUs) on the table.

Deploy an Amazon DynamoDB Accelerator (DAX) cluster and configure the application to use the DAX client SDK.

Package the application database logic in an AWS Lambda function with an increased execution timeout, relying on Lambda execution context reuse to cache query results locally.

Show answer & explanation

Answer: Deploy an Amazon DynamoDB Accelerator (DAX) cluster and configure the application to use the DAX client SDK.

Answer

Deploying an Amazon DynamoDB Accelerator (DAX) cluster and configuring the application to use the DAX client SDK is the correct solution.

The correct solution is to deploy an Amazon DynamoDB Accelerator (DAX) cluster and use the DAX client SDK. DAX provides a fully managed, in-memory cache directly in front of DynamoDB that delivers microsecond response times for read-heavy workloads. Because it is API-compatible, it requires minimal changes to the application (only the client initialization needs to be updated to point to the DAX cluster instead of DynamoDB directly), satisfying the requirement to avoid rewriting database access patterns.

Step-by-Step Solution

Identify the root cause of the performance bottleneck.

A surge in read requests for specific popular keys (hot partition key problem) is causing read throttling (ProvisionedThroughputExceededException) and high read latency.

Understanding the access pattern helps determine the appropriate caching or scaling strategy.

Evaluate the latency and application-level constraints.

The application requires sub-millisecond (microsecond) read latencies without rewriting the data access logic or altering the primary keys.

Amazon ElastiCache would require custom code integration for lookups and invalidation, whereas DAX is API-compatible.

Select the optimization solution.

Amazon DynamoDB Accelerator (DAX) meets the latency requirements and integrates seamlessly via the DAX client SDK without changes to database access code.

DAX provides a fully managed, highly available write-through cache that reduces read response times to microseconds.

Key Concept

Caching read-heavy DynamoDB tables using DynamoDB Accelerator (DAX) to resolve hot partition keys and achieve microsecond latency.

Question 533Question →

A developer is building a high-volume clickstream analytics pipeline where web applications publish event data to Amazon Kinesis Data Streams. The stream is configured with 4 shards, but the developer notices ProvisionedThroughputExceededException errors during high traffic. Upon review, they find that the partition key is set to a constant string value 'clickstream_event'. Which two actions should the developer take to resolve the throttling errors and optimize stream throughput?

Select all that apply

Modify the producer application to use the unique session ID or user ID as the partition key for each record.

Increase the shard count of the Kinesis Data Stream to scale the write throughput capacity.

Modify the producer application to use a static value like the application environment name as the partition key.

Deploy the consumer Lambda function in a private VPC subnet without configuring a NAT Gateway or VPC endpoint.

Increase the Lambda function execution timeout to its maximum limit to allow more processing time.

Show answer & explanation

Answer: Modify the producer application to use the unique session ID or user ID as the partition key for each record.; Increase the shard count of the Kinesis Data Stream to scale the write throughput capacity.

Answer

Modify the producer application to use the unique session ID or user ID as the partition key, and increase the shard count of the Kinesis Data Stream.

To resolve the throttling issues caused by a hot shard, the developer must select a partition key with high entropy (such as a unique session ID or user ID) so that data is distributed evenly across all shards. Additionally, if the overall volume exceeds the total capacity of the stream, increasing the shard count provides more aggregate throughput capacity.

Step-by-Step Solution

Analyze the cause of the ProvisionedThroughputExceededException error.

The error occurs because a static partition key routes all traffic to a single shard, which exhausts its capacity.

Kinesis determines shard routing by hashing the partition key. A constant key sends all records to the same shard.

Change the partition key design to use a high-entropy attribute.

Using attributes like user ID or session ID distributes the records evenly across all available shards.

This resolves the hot shard problem by spreading the throughput load across the stream.

Scale the Kinesis Data Stream capacity.

Increasing the shard count increases the total write capacity of the stream.

Each shard provides up to 1 MB/sec or 1,000 records/sec write capacity, so scaling the shard count matches high traffic demands.

Key Concept

Partition key design and shard capacity scaling in Amazon Kinesis Data Streams

Question 534Question →

A multiplayer gaming platform operates a matchmaking lobby service that frequently retrieves game mode configurations from an Amazon DynamoDB table. During peak traffic hours, player sign-ins spike, leading to high read latency and ProvisionedThroughputExceededException errors on the table due to the volume of read requests. The development team decides to deploy an Amazon DynamoDB Accelerator (DAX) cluster to cache these configurations. Which of the following implementation steps must the developers perform to successfully resolve the latency issue using DAX caching? (Select two.)

Select all that apply

Configure the application code to use the DAX SDK client instead of the standard DynamoDB SDK client.

Modify the application's query requests to use eventually consistent reads instead of strongly consistent reads.

Convert the query operations to Scan operations to force DAX to populate its item cache for all game configurations.

Scale up the DynamoDB table's provisioned read capacity units (RCUs) to handle the cache miss rate during peak hours.

Hardcode the DAX cluster primary endpoint and IAM access key credentials directly in the application's SDK client initialization block.

Show answer & explanation

Answer: Configure the application code to use the DAX SDK client instead of the standard DynamoDB SDK client.; Modify the application's query requests to use eventually consistent reads instead of strongly consistent reads.

Answer

To successfully optimize read latency using DAX, the application must instantiate the DAX SDK client instead of the standard DynamoDB SDK client, and all read queries must be configured as eventually consistent reads.

To cache query results using DAX, the application must point to the DAX cluster using the specialized DAX SDK client. Furthermore, DAX is designed to cache eventually consistent reads; executing queries with strong consistency forces DAX to bypass its cache and query DynamoDB directly, failing to resolve the latency bottleneck.

Step-by-Step Solution

Integrate the DAX SDK into the application dependencies.

The application has access to the DAX client classes.

The standard AWS SDK for DynamoDB is not aware of DAX cluster endpoints and cannot route caching calls correctly without the DAX SDK wrapper.

Replace the instantiation of the standard DynamoDB client with the DAX client pointing to the cluster endpoint.

All client calls now target the DAX cluster.

This enables the application to write through and read from the DAX cluster nodes automatically.

Verify and change the read consistency settings on the query calls from strongly consistent to eventually consistent.

Queries hit the DAX query cache when available.

Strongly consistent queries bypass the DAX cache to guarantee the latest data from the DynamoDB table, which prevents caching from resolving the latency bottleneck.

Key Concept

Integrating the Amazon DynamoDB Accelerator (DAX) SDK and understanding the requirement of eventually consistent reads for caching behavior.

Estimated Time:2m 0s

Question 535Question →

A developer is building a backend service for an IoT-based smart agricultural monitoring system. The system receives real-time telemetry from $500$ sensor nodes deployed in the field. Each sensor node publishes status updates containing soil moisture and temperature readings. The serialized payload size for each status update is $2.2\text{ KB}$ , and the application receives and writes $150$ status updates per second directly to an Amazon DynamoDB table. A management dashboard displays a summary of the last $10$ telemetry updates for a specific sensor node by making $5$ requests per second using eventually consistent reads. Which two of the following actions should the developer perform to design the database and client access layer efficiently?

Select all that apply

Provision

450

Write Capacity Units (WCUs) for the table to handle the sensor telemetry ingestion.

Query the table using a KeyConditionExpression on the sensor ID partition key, and provision

15

Read Capacity Units (RCUs) to support the dashboard workload.

Scan the table using a FilterExpression on the sensor ID, and provision

15

Read Capacity Units (RCUs) to retrieve the dashboard telemetry.

Initialize the Amazon DynamoDB client in the application by hardcoding the AWS Access Key ID and Secret Access Key of a dedicated IAM user to bypass IAM role evaluation latency.

Provision

330

Write Capacity Units (WCUs) for the table, calculating the write capacity as

150\text{ writes/sec} \times 2.2\text{ KB}

without rounding up individual items.

Show answer & explanation

Answer: Provision $450$ Write Capacity Units (WCUs) for the table to handle the sensor telemetry ingestion.; Query the table using a KeyConditionExpression on the sensor ID partition key, and provision $15$ Read Capacity Units (RCUs) to support the dashboard workload.

Answer

Provision

450

Write Capacity Units (WCUs) for the table and query the table using a KeyConditionExpression on the sensor ID partition key, provisioning

15

Read Capacity Units (RCUs).

The correct options are the ones recommending provisioning

450

WCUs for table writes and using the Query API with

15

RCUs. For the write capacity,

150

updates per second at

2.2\text{ KB}

(rounded up to

3\text{ KB}

per item) requires

450

WCUs. For the read capacity, querying

10

items totaling

22\text{ KB}

(rounded up to

24\text{ KB}

) at

5

eventually consistent queries per second requires

15

RCUs (

24\text{ KB} / 4\text{ KB} \times 0.5 \times 5 = 15

Step-by-Step Solution

Calculate the Write Capacity Units (WCUs) needed for ingestion.

Each update is

2.2\text{ KB}

, which rounds up to

3\text{ KB}

per item. Writing

150

updates per second requires

150 \times 3 = 450\text{ WCUs}

DynamoDB rounds up write payloads to the nearest

1\text{ KB}

increment, and each standard write consumes

1\text{ WCU}

per

1\text{ KB}

per second.

Calculate the Read Capacity Units (RCUs) needed for the dashboard queries.

The query retrieves

10

items of

2.2\text{ KB}

each, totaling

22\text{ KB}

. This rounds up to the next

4\text{ KB}

boundary, which is

24\text{ KB}

. A single query consumes

24\text{ KB} / 4\text{ KB} = 6\text{ RCUs}

for strongly consistent reads, or

3\text{ RCUs}

for eventually consistent reads. At

5

queries per second, this requires

3 \times 5 = 15\text{ RCUs}

Query operations sum the total size of all returned items and round up to the next

4\text{ KB}

boundary. Eventually consistent reads consume

0.5\text{ RCU}

per

4\text{ KB}

block.

Determine the optimal access API and security pattern.

Use the Query API instead of Scan to target specific partition keys, and use the default credential provider chain rather than hardcoded credentials.

Querying minimizes RCU consumption by scanning only the targeted partition, and using IAM roles ensures secure AWS SDK client configuration.

Key Concept

Calculating DynamoDB read and write capacity units for item-level writes and Query operations under specific consistency models, combined with secure client initialization.

Question 536Question →

A developer is designing an API in Amazon API Gateway that routes incoming client requests to an AWS Lambda function. To keep the Lambda function's logic simple and decoupled from the API structure, the developer wants the function to receive a specific, simplified JSON payload containing only the client's source IP and a custom API header called 'X-App-Version'. The developer wants to avoid parsing the full HTTP request structure within the Lambda function code. Which API Gateway integration strategy should the developer use to meet these requirements?

Configure a Lambda custom (non-proxy) integration, and use an integration request mapping template in Velocity Template Language (VTL) to extract the source IP and header into the required JSON format.

Configure a Lambda proxy integration, and access the source IP and header fields directly from the parsed input event object inside the Lambda function.

Configure a custom Lambda authorizer to validate the header, and configure it to inject the source IP into the Lambda execution context.

Configure a Lambda proxy integration, and configure API Gateway CORS response headers mapping to filter out all request fields except the source IP and header.

Show answer & explanation

Answer: Configure a Lambda custom (non-proxy) integration, and use an integration request mapping template in Velocity Template Language (VTL) to extract the source IP and header into the required JSON format.

Answer

A Lambda custom (non-proxy) integration allows the developer to define an integration request mapping template using Velocity Template Language (VTL). This template can extract parameters from the request context (like the source IP) and headers, and construct a custom JSON payload that is sent to the Lambda function. As a result, the Lambda function only receives the mapped parameters and does not need to parse the full HTTP request structure.

Step-by-Step Solution

Identify the requirement to transform the incoming API Gateway request before it reaches the backend Lambda function, specifically avoiding the ingestion and parsing of the entire raw HTTP request wrapper within the Lambda function code.

Limits the solution to API Gateway integration types that support request transformation.

This requirement ensures that the Lambda function remains simple and decoupled from the API request format.

Evaluate the integration types in API Gateway. Lambda Proxy integration forwards the raw request wrapper directly to Lambda, shifting the parsing responsibility to the function. Lambda Custom (non-proxy) integration allows the creation of request mapping templates.

Establishes that Lambda Custom (non-proxy) integration is required.

Only custom integration supports payload mapping and transformation before the request reaches the backend integration.

Determine the correct technology for payload modification. Velocity Template Language (VTL) in the integration request template is used to extract the source IP (via

context.identity.sourceIp) and headers (via

input.params('X-App-Version')) and format them into the desired JSON structure.

Identifies the exact configuration path to build the desired integration payload.

VTL mapping templates are the standard mechanism in API Gateway to map and transform request parameters and body contents for non-proxy integrations.

Key Concept

API Gateway Integration Types and Request Mapping Templates

Question 537Question →

A developer is designing a document processing system. User-uploaded documents are published to an Amazon SNS topic. Two Amazon SQS queues are subscribed to the topic: Queue A feeds a text-extraction service running on Amazon ECS, which takes up to 45 seconds to process each document, while Queue B feeds an archiving service. During high-load periods, the text-extraction service experiences two problems: many documents are processed multiple times by different ECS tasks, and SQS messages sent to Queue A are occasionally discarded before being processed because the ECS task scale-up takes longer than the queue's default message age limit. Which TWO actions should the developer take to resolve these issues? (Select TWO.)

Select all that apply

Increase the VisibilityTimeout attribute of Queue A to a value greater than the maximum document processing time, such as 60 seconds.

Increase the MessageRetentionPeriod attribute of Queue A to a higher value, such as 4 days.

Decrease the VisibilityTimeout attribute of Queue A to 15 seconds to ensure that unprocessed messages are quickly made available to other ECS tasks.

Enable Content-Based Deduplication on Queue A to automatically filter out duplicate message deliveries.

Set the SNS subscription delivery policy retry backoff to 45 seconds to throttle message delivery to Queue A.

Show answer & explanation

Answer: Increase the VisibilityTimeout attribute of Queue A to a value greater than the maximum document processing time, such as 60 seconds.; Increase the MessageRetentionPeriod attribute of Queue A to a higher value, such as 4 days.

Answer

The developer should increase the VisibilityTimeout attribute of Queue A to a value greater than the maximum document processing time (such as 60 seconds) and increase the MessageRetentionPeriod attribute of Queue A to a higher value (such as 4 days).

Increasing the SQS visibility timeout to a value larger than the consumer processing time ensures that the consumer can complete the task and delete the message before another consumer picks it up. Increasing the message retention period ensures that messages stay in the queue during scaling delays instead of being discarded.

Step-by-Step Solution

Analyze the duplicate processing issue.

The text-extraction service takes up to 45 seconds, which exceeds the default SQS visibility timeout of 30 seconds. While a task is processing, the visibility timeout expires and the message returns to the queue, allowing another task to poll and process it.

To resolve this, the visibility timeout must be set to a value greater than the maximum processing time.

Analyze the message loss issue.

Delayed ECS task scaling causes messages to age out and get discarded before they can be consumed. SQS deletes messages that exceed their configured retention period (default 4 days, but can be configured lower).

Increasing the message retention period gives the auto-scaling group enough time to launch new instances/tasks and process the backlog.

Key Concept

Configuring SQS Visibility Timeout and Message Retention Period for Consumer Capacity Alignment

Question 538Question →

An organization enforces a standard error response schema where all HTTP error responses must return a JSON object containing a custom error ID and a descriptive message. A developer deployed a REST API in Amazon API Gateway protected by a Cognito User Pool authorizer. During testing, clients attempting to call the API without a valid token receive the default Gateway response `{"message":"Unauthorized"}`. Which configuration should the developer implement in API Gateway to return the custom error schema?

Update the Gateway Response for the Unauthorized error type in API Gateway by configuring a mapping template for the application/json content type.

Configure an integration response mapping template on the API Gateway method to catch the 401 status code and transform the payload.

Replace the Cognito User Pool authorizer with a custom Lambda authorizer, and return the custom JSON error payload in the response context when denying access.

Enable CORS on the API Gateway resources and add the custom error response schema under the Access-Control-Expose-Headers configuration.

Show answer & explanation

Answer: Update the Gateway Response for the Unauthorized error type in API Gateway by configuring a mapping template for the application/json content type.

Answer

Update the Gateway Response for the Unauthorized error type in API Gateway by configuring a mapping template for the application/json content type.

Updating the Gateway Response for the Unauthorized error type is the correct approach. Gateway Responses are used to customize responses generated by API Gateway itself when a request does not reach the integration backend (such as authentication or authorization failures). By configuring a mapping template for the application/json content type, developers can format the response body to match any custom JSON error schema.

Step-by-Step Solution

Identify the point of failure for requests without a valid token.

Requests are blocked at the Cognito Authorizer stage in API Gateway, prior to reaching the integration backend.

Since the request is blocked by API Gateway before the backend executes, standard integration responses cannot be used to modify the error payload.

Determine the API Gateway mechanism designed to handle client-side or gateway-generated errors.

Identify 'Gateway Responses' as the feature that controls errors originating from API Gateway, such as 401 Unauthorized or 403 Forbidden.

Gateway Responses allow API administrators to customize the response status code, headers, and body mapping templates for gateway-level errors.

Configure the Gateway Response for the Unauthorized error type.

Add a mapping template for the application/json content type using Velocity Template Language (VTL) to return the custom error ID and message.

This guarantees that any time API Gateway rejects a request due to authorization failure, it formats the error response body to match the organization's required JSON schema.

Key Concept

Amazon API Gateway Gateway Responses

Estimated Time:1m 30s

Question 539Question →

A developer is building a backend for a conference ticketing application. The ticketing data is stored in an Amazon DynamoDB table with `BookingId` (a unique UUID) as the partition key and no sort key. The developer needs to implement two new requirements:

1. Retrieve all bookings for a specific `EventId` sorted by `BookingTimestamp` in descending order.
2. Process bulk attendee registrations where groups of up to $20$ bookings must be written or updated simultaneously. If any booking in the group fails (such as due to a sold-out status or validation error), none of the bookings in the group should be applied.

Which TWO actions should the developer take to meet these requirements efficiently?

Select all that apply

Create a Global Secondary Index (GSI) with `EventId` as the partition key and `BookingTimestamp` as the sort key, and use the `Query` API on the GSI.

Use the `TransactWriteItems` API to execute the bulk registrations as a single transaction.

Use the `Scan` API with a `FilterExpression` on the base table to retrieve bookings for a specific `EventId` and sort them in application code.

Increase the provisioned Write Capacity Units (WCUs) on the base table to automatically resolve failures caused by transactional validation checks.

Initialize the AWS SDK DynamoDB client inside the application code using hardcoded AWS access key and secret access key credentials for authentication.

Show answer & explanation

Answer: Create a Global Secondary Index (GSI) with `EventId` as the partition key and `BookingTimestamp` as the sort key, and use the `Query` API on the GSI.; Use the `TransactWriteItems` API to execute the bulk registrations as a single transaction.

Answer

Create a Global Secondary Index (GSI) with EventId as the partition key and BookingTimestamp as the sort key, and use the Query API on the GSI. Also use the TransactWriteItems API to execute the bulk registrations as a single transaction.

Creating a Global Secondary Index with EventId as the partition key and BookingTimestamp as the sort key allows the application to perform efficient queries and receive sorted results. Utilizing the TransactWriteItems API ensures that the bulk updates are performed atomically, preventing partial updates where some registrations succeed and others fail.

Step-by-Step Solution

Evaluate query and sorting needs for non-key attributes.

Identified that retrieving sorted bookings by event requires a secondary index because the base table partition key is BookingId.

DynamoDB does not support direct sorting on non-key attributes without a sort key, and query operations are restricted to key attributes.

Select index type and key attributes.

Determined that a Global Secondary Index (GSI) with EventId as the partition key and BookingTimestamp as the sort key is required.

A GSI allows querying on EventId and returns results sorted by BookingTimestamp.

Evaluate requirements for bulk atomic writes.

Identified the need for all-or-nothing transactional guarantees for up to 20 writes.

Standard batch writes (BatchWriteItem) do not support transactions or conditional failures, whereas TransactWriteItems guarantees ACID transactions.

Key Concept

Using Global Secondary Indexes (GSIs) for alternative query patterns and sorting, and utilizing TransactWriteItems for atomic multi-item operations.

Question 540Question →

A developer is implementing a microservice that processes message batches from an Amazon SQS queue. The processing logic is deployed as an AWS Lambda function with a timeout of $5$ minutes. However, the developer notices that some message batches are processed multiple times, and the application logs show that the Lambda function is frequently terminated prematurely. Additionally, the Lambda function code currently initializes the SQS client by passing hardcoded IAM credentials.

Which of the following actions should the developer take to resolve these issues? (Select TWO.)

Select all that apply

Remove the hardcoded credentials from the SDK client initialization and associate an IAM execution role containing SQS permissions with the Lambda function.

Increase the Lambda function's timeout to exceed the maximum processing time, and set the SQS queue's visibility timeout to at least

6

times the Lambda function's timeout.

Decrease the SQS queue's visibility timeout to

30

seconds so that messages can be quickly picked up by other concurrent Lambda executions.

Re-initialize the SQS client inside the Lambda handler function on every invocation to guarantee that execution context variables are cleared after each run.

Pass the IAM access key and secret access key directly to the SQS client constructor in the code, using the default credential provider chain as a fallback.

Show answer & explanation

Answer: Remove the hardcoded credentials from the SDK client initialization and associate an IAM execution role containing SQS permissions with the Lambda function.; Increase the Lambda function's timeout to exceed the maximum processing time, and set the SQS queue's visibility timeout to at least $6$ times the Lambda function's timeout.

Answer

The developer should remove the hardcoded credentials from the SDK client initialization and associate an IAM execution role containing SQS permissions with the Lambda function, while also increasing the Lambda function's timeout to exceed the maximum processing time and setting the SQS queue's visibility timeout to at least

6

times the Lambda function's timeout.

To secure the function, the developer should associate an IAM execution role with the Lambda function and remove hardcoded credentials from the SDK client. To resolve the timeouts and duplicates, the developer should increase the Lambda timeout to accommodate the processing duration and set the SQS queue's visibility timeout to at least

6

times the Lambda function's timeout, which is the AWS recommended ratio for SQS-Lambda integrations.

Step-by-Step Solution

Analyze the log files to diagnose the root causes: Lambda function premature termination and message duplication.

Identify that the Lambda function requires more than

5

minutes to complete processing, causing a timeout, which leads SQS to make the message visible to other consumers again.

This establishes that both the Lambda timeout and the SQS visibility timeout must be adjusted.

Address the security issue in the SDK configuration.

Remove the hardcoded IAM access keys from the code and assign an IAM execution role with the required SQS policies directly to the Lambda function.

To ensure secure credential management via AWS STS temporary credentials.

Adjust SQS and Lambda timeouts based on processing requirements.

Increase the Lambda function timeout (e.g., to

10

minutes) to allow complete execution, and configure the SQS queue's visibility timeout to at least

6

times that value.

To prevent duplicate processing by ensuring the message remains invisible to other consumers during processing.

Key Concept

Integrating Amazon SQS with AWS Lambda, managing visibility timeouts, and securing SDK clients using IAM execution roles.

PreviousPage 27 / 78Next

All practice questions

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept