All practice questions

1542 questions

All types1,542 Multiple choice782 Multiple select746 Ordering14

An application publishes event messages to an Amazon SNS topic. An Amazon SQS queue named ShippingQueue is subscribed to this topic, and an AWS Lambda function is configured to process messages from this queue. The developer needs to ensure that the ShippingQueue only receives messages where the message attribute shipping_type is set to physical. Additionally, the developer must prevent messages from being processed by multiple concurrent Lambda instances while the function is actively executing. Which TWO configurations should the developer implement?

Select all that apply

Define a subscription filter policy on the Amazon SNS subscription for the ShippingQueue that checks the shipping_type attribute.

Configure the visibility timeout of the ShippingQueue to be greater than or equal to the timeout of the consumer Lambda function.

Configure the visibility timeout of the ShippingQueue to be shorter than the Lambda function timeout to ensure failed messages are immediately retried.

Initialize the SQS client inside the Lambda function handler using hardcoded IAM access keys and secret keys.

Configure the Lambda function to delete messages from the ShippingQueue at the start of the execution to prevent execution context reuse issues.

Show answer & explanation

Answer: Define a subscription filter policy on the Amazon SNS subscription for the ShippingQueue that checks the shipping_type attribute.; Configure the visibility timeout of the ShippingQueue to be greater than or equal to the timeout of the consumer Lambda function.

Answer

To configure this architecture correctly, the developer must define an SNS subscription filter policy to filter out non-physical orders and set the SQS visibility timeout to be at least the duration of the Lambda function's timeout.

Configuring an SNS subscription filter policy restricts message delivery to only matching messages. Aligning the SQS visibility timeout with the Lambda timeout prevents SQS from releasing the message back into the queue while processing is active.

Step-by-Step Solution

Configure the SNS Subscription Filter Policy.

Only messages with the attribute shipping_type set to physical are delivered to the ShippingQueue.

SNS evaluates message attributes at the subscription level. Defining the policy on the subscription prevents unwanted messages from reaching the queue.

Align SQS visibility timeout with the Lambda execution timeout.

Messages remain invisible in the queue for the entire duration of the Lambda execution.

If processing takes longer than the visibility timeout, SQS assumes the consumer failed and makes the message visible to other consumers, causing duplicate processing.

Key Concept

Decoupled architectures using SNS subscription filters restrict message delivery to relevant queues, while SQS visibility timeouts ensure single-consumer processing safety during execution.

Question 302Question →

A developer is designing a REST API in Amazon API Gateway to ingest high-frequency telemetry data from client devices. To minimize latency and operating costs, the API must write incoming JSON payloads directly to an Amazon Kinesis data stream without using an intermediate AWS Lambda function. The client payload is sent as application/json containing a telemetry event. The API Gateway integration must map the payload to the format required by the Kinesis PutRecords API, which expects base64-encoded data. Which two configuration steps must the developer perform to successfully implement this integration? (Select TWO.)

Select all that apply

Configure an Integration Request mapping template for the application/json Content-Type using Velocity Template Language (VTL) to format the payload and encode the data using $util.base64Encode().

Create an IAM execution role that allows the kinesis:PutRecords action, trust the apigateway.amazonaws.com service principal, and specify the role's ARN in the Credentials field of the API Gateway Integration Request.

Configure the API Gateway integration type as AWS Service with a Lambda Proxy integration, and set the request payload to be processed via Lambda.

Associate the IAM execution role with an Amazon Cognito Identity Pool, and configure a Cognito User Pool Authorizer on the API method to handle the direct payload mapping.

Enable Request Validation on the API Gateway Method Request and configure a mapping template in the Method Response section to base64-encode the client payload.

Show answer & explanation

Answer: Configure an Integration Request mapping template for the application/json Content-Type using Velocity Template Language (VTL) to format the payload and encode the data using $util.base64Encode().; Create an IAM execution role that allows the kinesis:PutRecords action, trust the apigateway.amazonaws.com service principal, and specify the role's ARN in the Credentials field of the API Gateway Integration Request.

Answer

Configure an Integration Request mapping template using VTL to base64-encode the payload, and create an IAM execution role with Kinesis PutRecords permissions configured in the Integration Request Credentials.

The correct solution involves utilizing API Gateway's direct 'AWS Service' integration with Amazon Kinesis. This requires an IAM execution role that allows the API Gateway service principal to call the Kinesis PutRecords action. Furthermore, because Kinesis requires payload data to be base64-encoded, an Integration Request mapping template using Velocity Template Language (VTL) and the utility function helper must be used to restructure the client's request payload into the format expected by Kinesis.

Step-by-Step Solution

Configure the API Gateway Method to use the 'AWS Service' integration type pointing to the Kinesis service and PutRecords action.

Establishes a direct connection between API Gateway and Amazon Kinesis without intermediate compute resources.

Eliminating Lambda reduces costs and cold-start latencies.

Create an IAM role allowing 'kinesis:PutRecords' with a trust relationship for 'apigateway.amazonaws.com' and paste its ARN in the Credentials field.

Grants API Gateway the required authorization to write data into the target Kinesis data stream.

API Gateway needs explicit execution permissions to access downstream AWS resources.

Add an Integration Request mapping template for 'application/json' that maps client data to Kinesis format using VTL helper functions.

Formats the payload to the required Kinesis schema and encodes the telemetry data using the built-in base64 utility.

The Kinesis API expects record data payloads to be base64-encoded strings.

Key Concept

AWS Service Direct Integration with Amazon API Gateway

Question 303Question →

A developer is designing a system where order events must be processed independently by both an inventory management service and a shipping notification service. Each service must receive its own copy of every order event. Which of the following configurations should the developer implement? (Select TWO.)

Select all that apply

Publish order events to an Amazon SNS topic.

Create two separate Amazon SQS queues, subscribe them to the SNS topic, and have each service consume from its own queue.

Configure a single Amazon SQS queue and set the visibility timeout to 0 seconds so that both services can retrieve the same event simultaneously.

Embed AWS access keys directly in the application source code during initialization of the AWS SDK client.

Set the processing Lambda function execution timeout to 10 minutes and configure the source SQS queue's visibility timeout to 30 seconds.

Show answer & explanation

Answer: Publish order events to an Amazon SNS topic.; Create two separate Amazon SQS queues, subscribe them to the SNS topic, and have each service consume from its own queue.

Answer

Publish order events to an Amazon SNS topic, and create two separate Amazon SQS queues, subscribe them to the SNS topic, and have each service consume from its own queue.

To decouple services and ensure that both the inventory management and shipping notification services receive every order event, a fan-out pattern must be implemented. This is accomplished by publishing events to an Amazon SNS topic and subscribing two separate Amazon SQS queues (one for each service) to that topic. This setup guarantees that each queue receives a copy of every published event and processes it independently.

Step-by-Step Solution

Select a message distribution service that supports publishing messages to multiple consumers simultaneously.

Amazon SNS is chosen as the message publisher to support the fan-out pattern.

Amazon SNS enables a single publisher to broadcast messages to multiple destinations.

Configure separate consumer queues to isolate processing failures and maintain decoupling.

Two SQS queues are created, one for each backend service, and subscribed to the SNS topic.

This allows each backend service to process messages at its own pace and guarantees that both services receive every event independently.

Key Concept

Message fan-out using Amazon SNS and SQS queues

Question 304Question →

A developer is designing a message-based integration pattern for an e-commerce platform. Order event messages are published to an Amazon SNS topic, which fans them out to an Amazon SQS queue. A backend worker application polls the SQS queue and processes the events. The developer has two requirements for handling failed messages:

- If the SQS queue is temporarily unreachable or misconfigured (e.g., due to an incorrect IAM policy), any messages that SNS cannot deliver to the SQS queue must be captured for troubleshooting.
- If the backend worker application receives a message from SQS but fails to process it successfully after $3$ attempts, the message must be safely set aside.

Which configuration should the developer implement to satisfy both requirements?

Configure an Amazon SQS queue as a dead-letter queue (DLQ) for the Amazon SNS subscription to capture delivery failures, and configure another SQS queue as a DLQ for the main SQS queue with a redrive policy specifying a maxReceiveCount of

3

Configure a single Amazon SQS queue as a dead-letter queue (DLQ) on the main SQS queue, and set the SQS visibility timeout to at least three times the application processing time to allow SNS to automatically forward delivery failures to the same DLQ.

Configure an Amazon SQS queue as a dead-letter queue (DLQ) at the Amazon SNS topic level, and configure a redrive policy on the SQS queue with a maxReceiveCount of

3

pointing back to the SNS topic to retry delivery.

Configure an Amazon SQS queue as a dead-letter queue (DLQ) for the main SQS queue with a redrive policy specifying a maxReceiveCount of

3

, which will automatically capture both worker processing failures and SNS delivery failures to the queue.

Show answer & explanation

Answer: Configure an Amazon SQS queue as a dead-letter queue (DLQ) for the Amazon SNS subscription to capture delivery failures, and configure another SQS queue as a DLQ for the main SQS queue with a redrive policy specifying a maxReceiveCount of $3$ .

Answer

3

The correct answer is to configure two separate dead-letter queues. The SNS subscription DLQ is designed to capture messages that SNS fails to deliver to the SQS endpoint (due to client or server errors). The SQS queue-level DLQ (configured with a redrive policy and a maxReceiveCount of

3

) handles messages that were successfully delivered to the queue but failed to be processed and deleted by the worker application.

Step-by-Step Solution

Analyze the requirement for SNS-to-SQS delivery failures.

Identify that if SNS cannot write to SQS (due to permissions, deleted queue, etc.), this represents an SNS delivery failure. SNS handles this by forwarding messages to a DLQ configured on the subscription itself.

To ensure messages that fail to reach the queue are not lost.

Analyze the requirement for SQS consumer-side processing failures.

Identify that if the backend worker retrieves a message but fails to process it

3

times, this is a consumer processing failure. This is handled by SQS using a redrive policy with maxReceiveCount set to

3

that points to an SQS DLQ.

To prevent poison-pill messages from blocking the queue processing indefinitely.

Synthesize the architecture.

Combine an SNS subscription-level DLQ with an SQS queue-level DLQ to address both distinct failure vectors independently.

To satisfy both requirements using the native capabilities of each service.

Key Concept

Handling message delivery and processing failures in SNS-SQS fan-out integrations using distinct dead-letter queue (DLQ) mechanisms.

Question 305Question →

An application uses an AWS Lambda function to process messages from an Amazon SQS standard queue. The Lambda function has its timeout configured to $3$ minutes. During peak traffic, the developer notices that many messages are processed multiple times by parallel Lambda invocations, even though all Lambda executions finish successfully. The SQS queue has a Default Visibility Timeout of $30$ seconds. Which configuration change should the developer make to resolve this issue?

Configure the SQS queue as a FIFO queue and enable content-based deduplication.

Increase the Lambda function's timeout configuration to

18

minutes.

Increase the SQS queue's Default Visibility Timeout to

18

minutes.

Redeploy the Lambda function inside a private VPC subnet without a NAT Gateway.

Show answer & explanation

Answer: Increase the SQS queue's Default Visibility Timeout to $18$ minutes.

Answer

Increase the SQS queue's Default Visibility Timeout to

18

minutes.

To prevent duplicate message processing when SQS is used as an event source for AWS Lambda, the queue's visibility timeout must be configured to at least

6

times the timeout of the Lambda function. With a Lambda timeout of

3

minutes, the visibility timeout should be set to at least

18

minutes to ensure that the message is not visible to other consumers during execution and retries.

Step-by-Step Solution

Analyze the relationship between the SQS visibility timeout and the Lambda timeout.

The current SQS visibility timeout is

30

seconds, while the Lambda function timeout is

3

minutes (

180

seconds).

Since the Lambda execution can take longer than the visibility timeout, SQS assumes the processing failed and makes the message visible again before the Lambda function finishes.

Determine the recommended SQS visibility timeout for Lambda integration.

AWS recommends setting the SQS queue's visibility timeout to at least

6

times the timeout of the integrated Lambda function.

This

6\times

multiplier provides sufficient time for the Lambda service to execute the function and perform retries in case of transient errors without the messages reappearing in the queue prematurely.

Calculate the new visibility timeout.

3

minutes

\times 6 = 18

minutes.

Increasing the Default Visibility Timeout to

18

minutes ensures that messages are not processed concurrently by multiple Lambda invocations.

Key Concept

SQS Visibility Timeout configuration when integrated with AWS Lambda as an event source.

Question 306Question →

An application publishes transaction events to an Amazon SNS topic. An Amazon SQS standard queue is subscribed to this topic, and an AWS Lambda function processes messages from the queue. The Lambda function's timeout is configured to $30$ seconds. During traffic spikes, some transactions are processed multiple times by different Lambda invocations, causing duplicate database entries. Additionally, the developer wants to ensure that any messages that fail processing $3$ times are automatically moved to a dead-letter queue (DLQ).

Which two actions should the developer take to meet these requirements? (Select TWO.)

Select all that apply

Increase the Amazon SQS queue's visibility timeout to at least

180

seconds.

Configure a redrive policy on the source Amazon SQS queue specifying a dead-letter queue with a `maxReceiveCount` set to

3

Configure a dead-letter queue target on the AWS Lambda function's asynchronous invocation configuration.

Decrease the Amazon SQS queue's visibility timeout to

10

seconds to speed up the recovery of failed messages.

Set the Amazon SQS queue's visibility timeout to exactly

30

seconds to align with the Lambda function's timeout.

Show answer & explanation

Answer: Increase the Amazon SQS queue's visibility timeout to at least $180$ seconds.; Configure a redrive policy on the source Amazon SQS queue specifying a dead-letter queue with a `maxReceiveCount` set to $3$ .

Answer

Increase the Amazon SQS queue's visibility timeout to at least

180

seconds and configure a redrive policy on the source Amazon SQS queue with a `maxReceiveCount` set to

3

To resolve duplicate processing, the SQS visibility timeout must be configured to at least

6

times the Lambda function's timeout (

6 \times 30\text{ seconds} = 180\text{ seconds}

). This ensures the message remains hidden during execution and potential retries. To redirect failed messages after

3

attempts, a redrive policy with `maxReceiveCount` set to

3

must be configured directly on the source SQS queue because the event source mapping invokes Lambda synchronously.

Step-by-Step Solution

Calculate the required visibility timeout for the Amazon SQS queue based on the Lambda function's timeout.

The minimum recommended visibility timeout is

6 \times 30\text{ seconds} = 180\text{ seconds}

AWS recommends setting the SQS queue visibility timeout to at least

6

times the Lambda function timeout to allow sufficient time for processing and retries within the event source mapping.

Select the correct mechanism to route persistently failing messages to a dead-letter queue (DLQ).

Configure a redrive policy on the source Amazon SQS queue with `maxReceiveCount` set to

3

Since the Lambda service polls SQS synchronously using event source mapping, DLQ redirection must be configured on the SQS queue itself via a redrive policy, rather than on the Lambda function's asynchronous settings.

Key Concept

Decoupling serverless architectures using Amazon SNS, SQS, and AWS Lambda event source mappings, including proper visibility timeout alignment and redrive policy configuration.

Question 307Question →

A developer is building a REST API using Amazon API Gateway that integrates with an existing AWS Lambda function. The Lambda function expects a JSON payload containing specific keys: `searchCategory` and `maxResults`. However, client applications will send requests containing query string parameters `category` and `limit` (for example, `/items?category=books&limit=10`). The developer wants API Gateway to transform these incoming query string parameters into the required JSON payload structure before invoking the Lambda function.

Which integration approach should the developer implement to meet these requirements?

Configure a Lambda proxy integration and define a request mapping template to transform the query string parameters before passing them to the Lambda function.

Configure a Lambda custom integration and define a request mapping template in API Gateway to map the query string parameters to the required JSON format.

Configure a Lambda proxy integration and configure stage variables to rewrite the query parameters into the Lambda event object.

Configure a Lambda authorizer to intercept the request, transform the query parameters, and inject the mapped JSON payload into the request context.

Show answer & explanation

Answer: Configure a Lambda custom integration and define a request mapping template in API Gateway to map the query string parameters to the required JSON format.

Answer

Configure a Lambda custom integration and define a request mapping template in API Gateway to map the query string parameters to the required JSON format.

Configuring a Lambda custom integration (non-proxy integration) allows the developer to define an Integration Request mapping template. This template uses Velocity Template Language (VTL) to transform the incoming HTTP request query string parameters into the structured JSON payload format expected by the Lambda function before invocation.

Step-by-Step Solution

Determine the correct integration type for request transformation.

Select Lambda custom (non-proxy) integration.

Proxy integrations pass the raw request format directly to the backend without modification, whereas custom integrations allow mapping templates to transform client requests.

Configure the Integration Request mapping template.

Create a template for application/json mapping the query parameters to the expected JSON keys.

API Gateway uses Velocity Template Language (VTL) mapping templates to extract the query string values and format them into the structured JSON payload required by the backend Lambda function.

Key Concept

API Gateway Lambda Custom vs. Proxy Integration

Question 308Question →

A developer is building a digital concert ticketing application. The application needs to retrieve ticket status details for a single ticket using the TicketId, which is the partition key of the Amazon DynamoDB table. The developer wants to minimize latency and read capacity consumption. Which approach is the most efficient and cost-effective way to retrieve the ticket details?

Use the GetItem API operation specifying the exact TicketId value.

Use the Scan API operation with a FilterExpression to match the TicketId.

Increase the provisioned read capacity units (RCUs) and use the Scan API operation.

Configure the AWS SDK client with hardcoded credentials and run a Scan operation.

Show answer & explanation

Answer: Use the GetItem API operation specifying the exact TicketId value.

Answer

Use the GetItem API operation specifying the exact TicketId value.

Using the GetItem operation is the most efficient method because it retrieves a single item directly by its primary key (TicketId) without reading any other items in the table, resulting in the lowest latency and resource consumption.

Step-by-Step Solution

Identify the key attributes needed to retrieve the ticket status details.

The target item is a single ticket uniquely identified by its primary partition key, TicketId.

Knowing that the search is for a single item using its primary key dictates the most optimal retrieval path.

Compare DynamoDB read operations for retrieving a single item.

GetItem retrieves a single item using the primary key, while Scan reads all items in the table.

GetItem is designed for single-item lookups and consumes minimal Read Capacity Units (RCUs), whereas Scan is extremely inefficient for this use case.

Select the most optimal API operation.

GetItem is chosen because it avoids scanning the entire database table.

This minimizes both response latency and operational costs.

Key Concept

Single-item lookup using the GetItem API operation is the most efficient way to retrieve data by primary key in DynamoDB.

Question 309Question →

A developer is implementing a game state update system where player level-up events are sent to an Amazon SQS queue. An AWS Lambda function is configured to consume messages from the queue and process the updates. The Lambda function has its timeout configured to 50 seconds. The SQS queue has a visibility timeout of 20 seconds. During testing, the developer notices that some level-up events are being processed multiple times by different Lambda invocations. Which configuration change will prevent the duplicate processing of these messages?

Increase the visibility timeout of the Amazon SQS queue to at least 50 seconds.

Increase the timeout of the AWS Lambda function to 90 seconds.

Decrease the visibility timeout of the Amazon SQS queue to 10 seconds.

Change the Lambda function's IAM execution role to have trust relationships with the SQS queue.

Show answer & explanation

Answer: Increase the visibility timeout of the Amazon SQS queue to at least 50 seconds.

Answer

Increase the visibility timeout of the Amazon SQS queue to at least 50 seconds.

The correct option is to increase the visibility timeout of the Amazon SQS queue to at least 50 seconds. SQS visibility timeout prevents other consumers from receiving and processing a message that is currently being processed. If the consumer (the Lambda function) takes up to 50 seconds to complete, the visibility timeout must be at least 50 seconds so that the message remains invisible until the Lambda function successfully deletes it.

Step-by-Step Solution

Analyze the relationship between the consumer processing time (Lambda function timeout) and the queue configuration.

The Lambda function timeout is 50 seconds, meaning a single invocation can run for up to 50 seconds.

This establishes the maximum time a consumer requires to finish processing and delete a message.

Compare the processing time with the SQS visibility timeout.

The current SQS visibility timeout is 20 seconds, which is less than the 50-second processing time.

After 20 seconds, SQS makes the message visible to other consumers again, even though the original Lambda invocation is still running.

Determine the required adjustment to the visibility timeout.

The SQS visibility timeout must be increased to a value that is at least equal to the Lambda function timeout (50 seconds).

This ensures the message remains hidden from other consumers for the entire duration of the Lambda function execution, preventing duplicate processing.

Key Concept

Amazon SQS visibility timeout must be configured to be greater than or equal to the processing timeout of the consumer to prevent duplicate processing.

Estimated Time:1m 0s

Question 310Question →

A developer is developing an application that retrieves order history for a customer from an Amazon DynamoDB table. The table uses `CustomerId` as the partition key and `OrderTimestamp` as the sort key. Currently, the application retrieves data by fetching all items from the table and filtering them in memory, and the AWS SDK client is initialized using hardcoded AWS access keys. Which two actions should the developer take to resolve these performance and security issues? (Select TWO.)

Select all that apply

Use the Query API operation with a key condition expression specifying the CustomerId.

Use the Scan API operation with a filter expression specifying the CustomerId.

Use the default credential provider chain to initialize the AWS SDK client.

Hardcode the AWS access key ID and secret access key in the application's client initialization code.

Increase the table's provisioned read capacity units (RCU) to resolve the throttling issues caused by the Scan operation.

Show answer & explanation

Answer: Use the Query API operation with a key condition expression specifying the CustomerId.; Use the default credential provider chain to initialize the AWS SDK client.

Answer

To resolve the performance and security issues, the developer should use the Query API operation with a key condition expression specifying the partition key (CustomerId), and use the default credential provider chain to initialize the AWS SDK client rather than hardcoding credentials.

The correct options are to use the Query API operation and the default credential provider chain. The Query operation optimizes data retrieval by targeting specific partition key values, minimizing read capacity consumption and latency. The default credential provider chain securely retrieves credentials from the environment or IAM roles without hardcoding them.

Step-by-Step Solution

Identify the data retrieval method optimization.

Determine that switching from Scan to Query using the CustomerId partition key reduces read capacity unit (RCU) consumption and latency.

Query retrieves only matching partition key items, whereas Scan reads the entire table.

Identify the secure client initialization method.

Determine that using the default credential provider chain avoids hardcoding credentials.

Hardcoded credentials present a significant security vulnerability.

Key Concept

Optimizing DynamoDB retrieval operations with Query and managing SDK credentials securely.

Estimated Time:1m 0s

Question 311Question →

A developer is implementing an AWS Lambda function that queries an Amazon RDS for PostgreSQL DB instance. The Lambda function is configured to connect to the database using IAM database authentication. To minimize connection overhead and query latency, the developer initializes a database connection pool in the global scope (outside the Lambda handler function) and generates the IAM database authentication token once during this initialization. During initial testing, the Lambda function successfully connects to the RDS instance and retrieves data. However, when the application is left idle and then invoked again after 30 minutes, subsequent invocations fail with database authentication errors. Which action should the developer take to resolve this issue while maintaining optimal database connection management?

Move the database connection pool initialization and connection establishment entirely inside the Lambda handler function so that a new pool is created on every invocation.

Configure the Lambda function's execution timeout to 15 minutes to force AWS Lambda to automatically recycle the execution context and refresh the token.

Keep the connection pool in the global scope, but configure the pool to dynamically generate a new IAM database authentication token whenever a new connection is established.

Hardcode a static database credential token in the Lambda function's environment variables and decrypt it using AWS KMS helper tools on each invocation.

Show answer & explanation

Answer: Keep the connection pool in the global scope, but configure the pool to dynamically generate a new IAM database authentication token whenever a new connection is established.

Answer

Keep the connection pool in the global scope, but configure the pool to dynamically generate a new IAM database authentication token whenever a new connection is established.

The correct approach is to maintain the connection pool in the global scope (enabling connection reuse across warm invocations) but configure the pool to dynamically request a new IAM database authentication token whenever it creates a new database connection. Since IAM database authentication tokens are only valid for 15 minutes, any attempts by the pool to establish new connections (such as after connection idle timeouts or pool scaling) using the initial global token will fail. By dynamically generating the token during connection creation, the pool always uses a valid credential.

Step-by-Step Solution

Analyze the lifecycle of IAM database authentication tokens and Lambda execution contexts.

Note that IAM database authentication tokens expire after 15 minutes, while Lambda execution contexts can persist and be reused for longer periods.

To identify why the database connection pool fails to authenticate when trying to open new connections after 15 minutes have passed.

Evaluate the placement of the connection pool and token generation code.

Understand that keeping the pool in the global scope is necessary for connection reuse, but the token must not be static or generated only once at startup.

To find a solution that balances database connection pooling efficiency with dynamic token refreshes.

Configure the connection pool to refresh authentication tokens.

Provide a connection creation function or callback to the global connection pool that dynamically calls the RDS AWS SDK client to generate a new IAM authentication token whenever a new physical connection is opened.

This guarantees that new connection handshakes succeed with valid tokens, while existing established connections are reused without performance penalty.

Key Concept

AWS Lambda execution context reuse and RDS IAM database authentication token lifecycle

Question 312Question →

A developer is building a serverless backend for a web application using Amazon API Gateway and AWS Lambda. The API must secure its endpoints by authenticating users against an Amazon Cognito User Pool. The backend Lambda function needs access to the user's Cognito group memberships (claims) as well as the request's HTTP headers and query string parameters. To reduce development time and minimize latency, the developer wants to avoid writing custom authorization code or custom payload mapping logic. Which configuration should the developer implement?

Configure a custom Lambda Authorizer in API Gateway to validate the Cognito JWT token, and configure the integration type as Lambda Proxy Integration.

Configure the API method with no API Gateway authorizer, use Lambda Proxy Integration, and perform the Cognito JWT token validation and claims extraction within the backend Lambda function code.

Configure a Cognito User Pool Authorizer in API Gateway for the REST API method, and configure the integration type as Lambda Proxy Integration.

Configure a Cognito User Pool Authorizer in API Gateway, and configure the integration type as Lambda Custom Integration with a custom Velocity Mapping Template.

Show answer & explanation

Answer: Configure a Cognito User Pool Authorizer in API Gateway for the REST API method, and configure the integration type as Lambda Proxy Integration.

Answer

Configure a Cognito User Pool Authorizer in API Gateway for the REST API method, and configure the integration type as Lambda Proxy Integration.

The correct configuration utilizes a Cognito User Pool Authorizer combined with Lambda Proxy Integration. The Cognito User Pool Authorizer natively handles JWT validation without requiring custom code, and automatically exposes claims in the request context. The Lambda Proxy Integration automatically passes all request components, including query strings, headers, and the authorizer claims, to the backend Lambda function in a structured format.

Step-by-Step Solution

Create and configure a Cognito User Pool Authorizer in API Gateway pointing to the application's User Pool, and apply it to the REST API method.

API Gateway handles the JWT validation natively, securing the endpoint and extracting user claims into the context without custom authorization code.

To validate incoming authorization tokens at the gateway level with minimal latency and zero compute execution costs.

Set the API Gateway integration type to Lambda Proxy Integration.

API Gateway packages all incoming HTTP headers, query string parameters, body, and context parameters (including the Cognito claims under requestContext.authorizer.claims) into a single, standardized JSON event structure.

To avoid writing custom mapping templates and allow the backend Lambda function to receive all request details dynamically.

Access the required claims and request metadata from the event object inside the backend Lambda function code.

The Lambda function code can directly parse group memberships from the event object without manual data mapping or token decoding.

To retrieve user context and request parameters efficiently using native integration features.

Key Concept

API Gateway Integration with AWS Lambda and Amazon Cognito

Question 313Question →

A developer is building an integration where an application publishes messages to an Amazon SNS topic. An Amazon SQS queue is subscribed to the topic, and an AWS Lambda function processes messages from the queue. The messages take approximately $15$ seconds to process. During testing, the developer observes that messages are frequently being processed multiple times, and the Lambda function is running out of database connections. Which of the following actions should the developer take to resolve these issues? (Select TWO.)

Select all that apply

Configure the SQS queue's visibility timeout to be at least six times the Lambda function's timeout.

Initialize the database connection client outside of the Lambda handler function.

Decrease the SQS queue's visibility timeout to

5

seconds to allow failed messages to be retried faster.

Hardcode the database access credentials directly in the SDK client initialization within the Lambda function.

Rely on the Lambda execution context to automatically close database connection pools at the end of each invocation.

Show answer & explanation

Answer: Configure the SQS queue's visibility timeout to be at least six times the Lambda function's timeout.; Initialize the database connection client outside of the Lambda handler function.

Answer

Configure the SQS visibility timeout to be at least six times the Lambda function's timeout, and initialize the database connection client outside of the Lambda handler function.

Configuring the SQS visibility timeout to be at least six times the Lambda function timeout ensures that messages do not become visible to other consumers before the current Lambda function invocation has finished processing them or retrying. Initializing the database connection client outside of the Lambda handler function allows subsequent invocations that reuse the same execution context to reuse the existing database connection, preventing connection exhaustion.

Step-by-Step Solution

Analyze the duplicate processing issue.

The messages take

15

seconds to process. SQS requires the visibility timeout to be greater than the processing time (and ideally at least six times the Lambda function's timeout) to prevent duplicate processing by other concurrent consumers.

If the visibility timeout is too short, SQS assumes the consumer failed and makes the message visible again.

Analyze the database connection exhaustion issue.

Initialize connection clients outside the Lambda handler function to reuse connections across container executions.

Creating a new connection client inside the handler function on every invocation will quickly exhaust the database's available connections.

Key Concept

Managing SQS visibility timeout and Lambda execution context connection reuse

Estimated Time:1m 0s

Question 314Question →

A developer is configuring an Amazon API Gateway REST API with a Lambda integration. To manage deployments across different environments, the developer defines a stage variable named $env$ and configures the integration request to dynamically target a Lambda function alias using the format `my-function: ${stageVariables.env}`. After deploying the API to a stage where$ env $is set to `prod`, clients receive a$ 500$ Internal Server Error. The API Gateway execution logs show a permission error when attempting to invoke the Lambda function. Which action should the developer take to resolve this issue?

Use the AWS CLI to run the `aws lambda add-permission` command, granting the API Gateway service principal (`apigateway.amazonaws.com`) permission to perform the `lambda:InvokeFunction` action on the specific Lambda function alias.

Update the Lambda function's execution role trust policy to allow the API Gateway service principal (`apigateway.amazonaws.com`) to assume the role.

Enable Lambda Proxy Integration in the integration request to allow API Gateway to bypass Lambda resource-based policy checks.

Configure a VTL mapping template in the Integration Request to forward the stage variables inside the request payload.

Show answer & explanation

Answer: Use the AWS CLI to run the `aws lambda add-permission` command, granting the API Gateway service principal (`apigateway.amazonaws.com`) permission to perform the `lambda:InvokeFunction` action on the specific Lambda function alias.

Answer

The correct answer is correct because when you use stage variables to dynamically specify a Lambda function in API Gateway, the console cannot automatically add the resource-based policy permission to the Lambda function. You must manually grant invocation permissions to the API Gateway service principal (`apigateway.amazonaws.com`) using the `aws lambda add-permission` command for the specific alias that will be resolved at runtime.

Step-by-Step Solution

Analyze the error cause from the logs.

The API Gateway logs indicate a permission failure trying to invoke the backend Lambda function.

API Gateway needs explicit invocation permissions to trigger a Lambda function or alias.

Identify why permissions were not automatically configured.

Using the stage variable syntax `my-function:${stageVariables.env}` prevents the console from defining static permissions during configuration.

Because the runtime target is resolved dynamically, permissions must be explicitly set for each potential target function/alias.

Grant the required permissions.

Run `aws lambda add-permission` for the targeted Lambda function alias to allow API Gateway to invoke it.

This modifies the Lambda function's resource-based policy to allow the API Gateway service principal (`apigateway.amazonaws.com`) to call the function.

Key Concept

API Gateway stage variables and resource-based invocation permissions for Lambda integrations

Question 315Question →

A developer is designing the backend for a multiplayer game where the game session state is stored in an Amazon DynamoDB table. The table structure is defined as follows:
- Partition key: ` $GameSessionId$ ` (String)
- Sort key: ` $PlayerId$ ` (String)
- Attributes: ` $Score$ ` (Number), ` $SessionStatus$ ` (String), ` $MatchDetails$ ` (Map, size $12\text{ KB}$ )

The application must support the following requirements:
1. Retrieve the top $10$ highest scores for a specific ` $GameSessionId$ ` in real-time with strong consistency.
2. Every $10\text{ seconds}$ , retrieve a list of all active sessions (where ` $SessionStatus$ ` is $\text{"ACTIVE"}$ ) to display on a public lobby dashboard. The number of active sessions is typically small (fewer than $100$ at any time), but the table contains millions of completed sessions.
3. Minimize provisioned write capacity consumption. Players update their ` $Score$ ` and ` $MatchDetails$ ` frequently (up to $100\text{ writes/sec}$ per session).

Which two configurations should the developer implement to meet these requirements with the lowest latency and cost?

Select all that apply

Create a Local Secondary Index (LSI) with `

GameSessionId

` as the partition key and `

Score

` as the sort key. Configure the LSI projection to `KEYS_ONLY` to prevent the

12\text{ KB}

MatchDetails

` attribute from being copied, thereby minimizing write capacity consumption during score updates.

Create a Global Secondary Index (GSI) with `

SessionStatus

` as the partition key and `

GameSessionId

` as the sort key, configured with `KEYS_ONLY` projection. In the application, set `

SessionStatus

` to

\text{"ACTIVE"}

when starting a session, and delete the `

SessionStatus

` attribute when the session completes.

Create a GSI with `

SessionStatus

` as the partition key and project all (`ALL`) attributes. When players update their score, resolve any write throttling on the base table by scaling up the base table's provisioned write capacity units, assuming the limit is due to the overall table capacity.

Perform a `Scan` operation on the base table with a `FilterExpression` of `

SessionStatus

= 'ACTIVE'` to populate the dashboard, and use a local cache inside the application to reduce the query frequency to once every

10\text{ seconds}

In the AWS Lambda function that updates scores, initialize the DynamoDB client by hardcoding the AWS Access Key ID and Secret Access Key of a dedicated IAM user with full DynamoDB permissions to bypass IAM role assumption latency and optimize write performance.

Show answer & explanation

Answer: Create a Local Secondary Index (LSI) with ` $GameSessionId$ ` as the partition key and ` $Score$ ` as the sort key. Configure the LSI projection to `KEYS_ONLY` to prevent the $12\text{ KB}$ ` $MatchDetails$ ` attribute from being copied, thereby minimizing write capacity consumption during score updates.; Create a Global Secondary Index (GSI) with ` $SessionStatus$ ` as the partition key and ` $GameSessionId$ ` as the sort key, configured with `KEYS_ONLY` projection. In the application, set ` $SessionStatus$ ` to $\text{"ACTIVE"}$ when starting a session, and delete the ` $SessionStatus$ ` attribute when the session completes.

Answer

Create a Local Secondary Index (LSI) with KEYS_ONLY projection, and create a Global Secondary Index (GSI) configured with KEYS_ONLY projection while using a sparse index pattern in the application logic.

To satisfy query pattern 1 with strong consistency, a Local Secondary Index (LSI) is required since Global Secondary Indexes (GSIs) do not support strongly consistent reads. By using a KEYS_ONLY projection for the LSI, we prevent the large 12 KB MatchDetails attribute from being projected. When a player's score is updated, DynamoDB only writes the modified score and keys to the LSI, consuming 1 WCU (or 2 WCUs if deleting and writing) instead of the 12 WCUs that would be consumed if the MatchDetails attribute was projected (e.g., using ALL projection). To satisfy query pattern 2, a sparse GSI is created by setting SessionStatus as the partition key and only writing 'ACTIVE' when a session is live, deleting the attribute upon completion. This keeps the GSI extremely small (under 100 items). By configuring the GSI with KEYS_ONLY projection, updates to Score and MatchDetails on the base table do not trigger GSI writes because those attributes are not projected. This prevents GSI write throttling and avoids hot partition issues on the 'ACTIVE' key.

Step-by-Step Solution

Select the correct index for retrieving the top scores for a specific game session.

Create a Local Secondary Index (LSI) on the base table using GameSessionId as the partition key and Score as the sort key.

This allows querying within the partition to get sorted results with strong consistency.

Determine the optimal projection strategy for the LSI to minimize write capacity costs.

Set the LSI projection to KEYS_ONLY.

This avoids copying the large MatchDetails attribute to the LSI on every score write, reducing the write capacity consumption from 12 WCUs to 1 WCU per update.

Select the correct index design for retrieving active sessions.

Create a sparse Global Secondary Index (GSI) with SessionStatus as the partition key and GameSessionId as the sort key, and only populate SessionStatus with 'ACTIVE' when the session is live.

This excludes completed sessions from the GSI, creating a small index containing only active sessions, which can be queried instead of scanning the millions of base table rows.

Optimize the GSI projection to prevent write capacity bottlenecks.

Use KEYS_ONLY projection on the GSI.

Since the frequently updated attributes (Score and MatchDetails) are not projected in the GSI, player score updates do not trigger GSI writes, preventing GSI write capacity exhaustion and hot partitions on the 'ACTIVE' key.

Key Concept

DynamoDB Local and Global Secondary Index write capacity optimization, sparse indexes, and projection selection.

Estimated Time:3m 0s

Question 316Question →

A company is migrating a transaction processing system to AWS. The solution uses an AWS Lambda function that must process events from an Amazon SQS queue, perform a call to an external payment gateway API over the public internet, and save the transaction status to an Amazon DynamoDB table. The Lambda function is configured to run inside private subnets of an Amazon VPC to comply with security requirements. During testing, the function experiences connection timeout errors when trying to reach the payment gateway. Additionally, many SQS messages are being processed multiple times by different Lambda invocations. Which two configuration changes should a developer make to resolve these issues? (Select two.)

Select all that apply

Configure a NAT Gateway in a public subnet of the VPC, and add a route in the private subnet's route table directing outbound destination 0.0.0.0/0 traffic to the NAT Gateway.

Increase the visibility timeout of the Amazon SQS queue to at least 6 times the timeout of the Lambda function.

Attach an Internet Gateway directly to the private subnet where the Lambda function resides, and modify the route table to route 0.0.0.0/0 traffic to it.

Set the visibility timeout of the Amazon SQS queue to be equal to or less than the Lambda function timeout to ensure that messages return to the queue immediately if the function fails.

Associate an Elastic IP address directly to the Lambda function's elastic network interface (ENI) to allow direct outbound communication with the external API.

Show answer & explanation

Answer: Configure a NAT Gateway in a public subnet of the VPC, and add a route in the private subnet's route table directing outbound destination 0.0.0.0/0 traffic to the NAT Gateway.; Increase the visibility timeout of the Amazon SQS queue to at least 6 times the timeout of the Lambda function.

Answer

To resolve the issues, configure a NAT Gateway in a public subnet of the VPC and route outbound destination 0.0.0.0/0 traffic from the private subnet's route table to the NAT Gateway, and increase the visibility timeout of the Amazon SQS queue to at least 6 times the timeout of the Lambda function.

Configuring a NAT Gateway in a public subnet and routing the private subnet's outbound traffic (0.0.0.0/0) to it enables the Lambda function inside the private subnet to securely access the public internet (external payment gateway). Concurrently, setting the Amazon SQS visibility timeout to at least 6 times the Lambda function timeout satisfies the AWS-recommended integration guidelines, preventing messages from being visible to other pollers before the current invocation completes or has a chance to retry.

Step-by-Step Solution

Analyze the connection timeout issue for the VPC-attached Lambda function trying to reach the public internet.

Identify that a Lambda function attached to a private subnet of a VPC does not have public internet access by default. It requires routing public-destined traffic through a NAT Gateway situated in a public subnet.

Since the payment gateway is on the public internet, outbound network translation is required for private subnet resources.

Analyze the duplicate message processing issue for the SQS queue integrated with Lambda.

Determine that if the SQS visibility timeout is not sufficiently longer than the Lambda function's timeout, messages will reappear in the queue before the processing invocation completes, leading to duplicate invocations.

AWS best practices specify that the queue's visibility timeout should be set to at least 6 times the function timeout to prevent early message visibility and allow for proper retries.

Select the two correct configuration steps matching the findings.

Select the configuration of a NAT Gateway with appropriate private subnet routing and adjusting the SQS visibility timeout to at least 6 times the Lambda timeout.

These steps address the specific causes of the connection timeouts and the duplicate processing errors.

Key Concept

Configuring VPC routing for outbound access in AWS Lambda and adjusting SQS queue visibility timeout relative to Lambda timeouts.

Question 317Question →

A developer is designing an AWS Lambda function that processes incoming images. The function requires a static machine learning model file of $250\text{ MB}$ , which is stored in a private Amazon S3 bucket. This model file is read-only and rarely updated. To process the images, the function also needs to write metadata to an Amazon DynamoDB table. The developer wants to optimize the Lambda function's performance by minimizing execution time and avoiding unnecessary API calls during cold starts and warm invocations. Which of the following actions should the developer take to meet these requirements? (Select TWO.)

Select all that apply

Initialize the Amazon S3 and Amazon DynamoDB SDK client objects outside of the Lambda handler function.

Download the model file to the `/tmp` directory during the initialization phase, checking for its existence in `/tmp` before downloading it on subsequent invocations.

Download the model file directly to the `/tmp` directory inside the handler function on every invocation.

Initialize the AWS SDK clients using hardcoded access keys and secret keys inside the handler function.

Configure the Lambda function to run inside a private VPC subnet without an internet gateway or NAT gateway, and access Amazon S3 using the public S3 endpoint.

Show answer & explanation

Answer: Initialize the Amazon S3 and Amazon DynamoDB SDK client objects outside of the Lambda handler function.; Download the model file to the `/tmp` directory during the initialization phase, checking for its existence in `/tmp` before downloading it on subsequent invocations.

Answer

The correct actions are to initialize the Amazon S3 and Amazon DynamoDB SDK client objects outside of the Lambda handler function, and to download the model file to the `/tmp` directory during the initialization phase while checking for its existence in `/tmp` before downloading on subsequent invocations.

The correct options specify initializing SDK clients outside the Lambda handler function and downloading the large static model file to `/tmp` during the initialization phase while checking for its presence first. These techniques take full advantage of AWS Lambda's execution context reuse, avoiding redundant connections and high-volume data transfers on subsequent warm invocations, which dramatically improves performance.

Step-by-Step Solution

Analyze connection reuse practices for AWS Lambda functions.

Initializing SDK clients outside the handler allows the reuse of HTTP connections and clients across invocations, which reduces the time spent on client setup during cold starts and warm invocations.

AWS Lambda reuse of execution contexts is optimized when resource initialization (like client SDK instantiation) occurs during the initialization phase.

Evaluate strategies for caching static, large assets in a serverless environment.

Downloading the

250\text{ MB}

model file once to `/tmp` and checking for its presence in subsequent invocations avoids high latency and bandwidth costs associated with fetching the file from Amazon S3 every time.

The `/tmp` directory provides ephemeral local storage that persists as long as the execution context is kept active, which allows for caching static files.

Verify VPC network paths for S3 access.

Ensure that the Lambda function is either not placed in a VPC unless necessary, or is placed in a subnet with access to a NAT gateway or S3 VPC Gateway Endpoint to access Amazon S3.

Lambda functions in private VPC subnets cannot reach public AWS endpoints without explicit routing (NAT gateway or VPC endpoint).

Key Concept

AWS Lambda execution context reuse, client initialization, and ephemeral storage optimization.

Estimated Time:2m 0s

Question 318Question →

A developer is implementing a medical imaging pipeline where scan metadata is published to an Amazon SNS topic. An Amazon SQS queue, which is subscribed to the topic, triggers an AWS Lambda function to generate detailed diagnostic reports. The Lambda function has a timeout of $90$ seconds, and a single report can take up to $80$ seconds to generate. During testing, the developer observes that several reports are being generated multiple times for the same scan.

Which configuration change should the developer make to resolve this duplicate processing issue?

Increase the visibility timeout of the SQS queue to at least

540

seconds.

Set the visibility timeout of the SQS queue to

90

seconds to match the Lambda function timeout.

Configure an SQS dead-letter queue (DLQ) with a maxReceiveCount of

1

on the main queue.

Increase the Lambda function timeout to

480

seconds while leaving the queue settings at their defaults.

Show answer & explanation

Answer: Increase the visibility timeout of the SQS queue to at least $540$ seconds.

Answer

Increase the visibility timeout of the SQS queue to at least

540

seconds.

The correct answer is to increase the SQS visibility timeout to at least

540

seconds. According to AWS best practices for SQS-Lambda event source mappings, the queue's visibility timeout must be set to at least 6 times the Lambda function's timeout. This buffer allows the Lambda service to handle retries and throttling without immediately making the message visible to other concurrent execution environments.

Step-by-Step Solution

Analyze the cause of message duplication in SQS-Lambda integrations.

The Lambda function timeout is

90

seconds, but the SQS default visibility timeout is

30

seconds. When a processing job takes up to

80

seconds, the default visibility timeout expires, making the message visible again in the queue while the original Lambda execution is still running.

Understanding the relationship between processing duration, SQS visibility timeout, and Lambda execution helps locate the misconfiguration.

Apply the AWS recommended formula for SQS visibility timeout when integrated with Lambda.

AWS recommends setting the SQS queue's visibility timeout to at least 6 times the timeout of the consuming Lambda function.

This configuration provides a buffer for Lambda to retry downstream calls if the function is throttled during event source mapping invocations.

Calculate the required visibility timeout.

90 \text{ seconds} \times 6 = 540 \text{ seconds}

Ensures that the queue's visibility timeout is configured to the correct minimum value based on the

90

-second Lambda timeout.

Key Concept

SQS Visibility Timeout configuration with AWS Lambda integration

Estimated Time:1m 30s

Question 319Question →

An application uses an Amazon SQS standard queue to distribute image processing tasks to EC2 worker instances. Each worker instance takes approximately $15$ seconds to process a single task and then delete the message from the queue. Currently, the SQS queue's visibility timeout is set to $5$ seconds. The developer notices that worker instances are frequently processing the same image tasks multiple times. What should the developer do to resolve this issue?

Increase the visibility timeout of the SQS queue to a value greater than

15

seconds.

Decrease the visibility timeout of the SQS queue to

2

seconds so messages are processed faster.

Modify the application logic to reuse the SDK client's credentials rather than fetching them dynamically.

Increase the timeout value of the AWS Lambda functions serving as the queue's consumers.

Show answer & explanation

Answer: Increase the visibility timeout of the SQS queue to a value greater than $15$ seconds.

Answer

Increase the visibility timeout of the SQS queue to a value greater than

15

seconds.

The correct answer is to increase the visibility timeout of the SQS queue to a value greater than the worker's processing time. When a consumer receives a message from an SQS queue, the message remains in the queue but is hidden from other consumers for the duration of the visibility timeout. If the consumer does not delete the message within this period, it becomes visible again. Since the workers take

15

seconds to process the task but the timeout is set to

5

seconds, the message becomes visible and gets processed by other workers. Setting the timeout to a value greater than

15

seconds prevents this overlap.

Step-by-Step Solution

Analyze the relationship between processing duration and SQS visibility timeout.

The message processing takes

15

seconds, but the visibility timeout is only

5

seconds.

When the visibility timeout is shorter than the processing time, the message becomes visible to other consumers in the queue before the current worker can finish processing and delete it.

Select the configuration adjustment that keeps the message hidden for the full processing duration.

Increase the SQS visibility timeout to a value greater than

15

seconds.

This guarantees that the processing worker has enough time to complete the task and delete the message from the queue, preventing other workers from picking it up in the meantime.

Key Concept

SQS Visibility Timeout vs Message Processing Time

Estimated Time:45s

Question 320Question →

A developer is building a blogging application where posts are stored in an Amazon DynamoDB table. The table's partition key is AuthorId and the sort key is PostId. The application needs to retrieve all posts written by a specific author that were published within the last 30 days. This operation must minimize latency and read capacity unit (RCU) consumption. Which combination of actions should the developer take to meet these requirements? (Select TWO.)

Select all that apply

Create a Global Secondary Index (GSI) with AuthorId as the partition key and PublishDate as the sort key.

Perform a Query operation on the Global Secondary Index (GSI) using a KeyConditionExpression to specify the AuthorId and PublishDate range.

Perform a Scan operation on the base table using a FilterExpression to filter by AuthorId and PublishDate.

Perform a Query operation on the base table using a FilterExpression for both AuthorId and PublishDate.

Initialize the Amazon DynamoDB client by hardcoding the AWS access keys in the application source code.

Show answer & explanation

Answer: Create a Global Secondary Index (GSI) with AuthorId as the partition key and PublishDate as the sort key.; Perform a Query operation on the Global Secondary Index (GSI) using a KeyConditionExpression to specify the AuthorId and PublishDate range.

Answer

To optimize the retrieval, the developer should create a Global Secondary Index (GSI) with AuthorId as the partition key and PublishDate as the sort key, and then perform a Query operation on that GSI using a KeyConditionExpression for both fields.

To optimize read capacity unit (RCU) consumption and reduce latency, the query should target only the relevant data. Creating a Global Secondary Index (GSI) with AuthorId as the partition key and PublishDate as the sort key enables querying by date. Querying the GSI using a KeyConditionExpression for both AuthorId and PublishDate ensures that DynamoDB reads only the items that match the criteria.

Step-by-Step Solution

Analyze the table key schema and query requirements.

The base table uses AuthorId as the partition key and PostId as the sort key, but the query needs to filter by AuthorId and PublishDate.

Since PublishDate is not part of the primary key, querying the base table directly by date would require filtering all items for a partition, which is inefficient.

Design a Global Secondary Index (GSI) to support the query.

Create a GSI with AuthorId as the partition key and PublishDate as the sort key.

This configuration allows the application to perform key-based lookups on the date range for specific authors.

Use the Query API with KeyConditionExpression.

Query the GSI, supplying the AuthorId and the 30-day range for PublishDate in the KeyConditionExpression.

Using KeyConditionExpression on the GSI ensures that DynamoDB only reads matching items, keeping RCU usage low.

Key Concept

Using a Global Secondary Index (GSI) with a KeyConditionExpression to optimize queries on non-primary key attributes and minimize RCU consumption.

PreviousPage 16 / 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