Troubleshooting and Optimization

271 questions

All types271 Multiple choice138 Multiple select133

A health tracking application named FitPulse records real-time heart rate data from millions of user devices. The application writes telemetry records directly to an Amazon DynamoDB table configured with provisioned write capacity. The table uses `DeviceType` (with values such as `Watch`, `Band`, or `Ring`) as the partition key and `Timestamp` as the sort key. During a global fitness event, write activity surges, and the application receives a high volume of `ProvisionedThroughputExceededException` errors. CloudWatch metrics show that the total consumed Write Capacity Units (WCUs) are well below the table's total provisioned WCU limit. Which of the following is the most effective solution to resolve this throttling issue and ensure even write distribution across the partitions?

Modify the application to retrieve records using parallel Scan operations on the DynamoDB table to bypass partition throughput limits.

Redesign the partition key schema to use a high-cardinality attribute such as `DeviceId` and, if write volumes for a single device are extremely high, append a random or calculated numeric suffix to the partition key.

Increase the visibility timeout of the Amazon SQS queue that buffers incoming writes to

12

hours to allow the DynamoDB table more time to process the backlog.

Hardcode the IAM User's access key and secret access key in the application's SDK client initialization code to reduce credential retrieval latency during write surges.

Show answer & explanation

Answer: Redesign the partition key schema to use a high-cardinality attribute such as `DeviceId` and, if write volumes for a single device are extremely high, append a random or calculated numeric suffix to the partition key.

Answer

Redesigning the partition key schema to use a high-cardinality attribute distributes the database write load across many partitions. In Amazon DynamoDB, provisioned capacity is distributed across physical partitions. If a low-cardinality attribute like `DeviceType` is used as the partition key, all writes for a given device type will target the same partition, causing a hot partition that exceeds the per-partition limit (

1000

WCUs) even if the table-level provisioned capacity is not fully consumed. Appending a random or calculated numeric suffix to the partition key (write sharding) further distributes writes across multiple partitions when a single entity's write rate exceeds the per-partition limit.

Step-by-Step Solution

Analyze the CloudWatch metrics showing that total consumed throughput is below the table's total provisioned limits while `ProvisionedThroughputExceededException` errors are occurring.

Identify that the issue is a hot partition rather than an overall table capacity exhaustion.

Provisioned capacity in DynamoDB is divided across physical partitions, meaning a single partition can exceed its individual limit (

1000

WCUs or

3000

RCUs) even if the table-wide threshold is not breached.

Evaluate the primary key design (`DeviceType` as partition key and `Timestamp` as sort key).

Recognize that `DeviceType` has low cardinality (few distinct values like `Watch`, `Band`, or `Ring`), causing heavy write volumes to target only a few partitions.

Low-cardinality keys lead to uneven data distribution and partition overloading.

Redesign the schema to use a high-cardinality attribute like `DeviceId` as the partition key, and apply write sharding if necessary.

Ensure even key distribution across DynamoDB's physical partitions.

Using a high-cardinality key like `DeviceId` combined with a random or calculated suffix spreads the write requests uniformly across all physical partitions, resolving the hot partition throttling.

Key Concept

Resolving DynamoDB partition throttling by designing a high-cardinality partition key schema to avoid hot partitions.

Estimated Time:2m 0s

Question 42Question →

An AWS Lambda function in Account A ( $111122223333$ ) is configured to download files from an Amazon S3 bucket located in Account B ( $444455556666$ ). The S3 bucket is encrypted using an AWS KMS customer managed key also located in Account B. The Lambda function's IAM execution role in Account A has an identity-based policy that grants permission for the `s3:GetObject` and `kms:Decrypt` actions. When the Lambda function runs, it fails to retrieve objects and receives an Access Denied error. Which two actions must be taken in Account B to resolve this authorization failure?

Select all that apply

Modify the Amazon S3 bucket policy in Account B to grant the `s3:GetObject` permission to the Lambda execution role in Account A.

Modify the AWS KMS key policy in Account B to grant the `kms:Decrypt` permission to the Lambda execution role in Account A.

Update the trust policy of the Lambda execution role in Account A to trust the `kms.amazonaws.com` service principal.

Configure the Lambda function to use an Amazon Cognito Identity Pool to retrieve temporary credentials to access the AWS KMS key.

Hardcode temporary access credentials generated from Account B directly in the Lambda function's initialization code.

Show answer & explanation

Answer: Modify the Amazon S3 bucket policy in Account B to grant the `s3:GetObject` permission to the Lambda execution role in Account A.; Modify the AWS KMS key policy in Account B to grant the `kms:Decrypt` permission to the Lambda execution role in Account A.

Answer

To resolve the authorization failure, the S3 bucket policy in Account B must be updated to grant the Lambda execution role `s3:GetObject` permissions, and the KMS key policy in Account B must be updated to grant the Lambda execution role `kms:Decrypt` permissions.

For cross-account resource access where KMS encryption is involved, the target resource policies must grant access. Specifically, the S3 bucket policy in Account B must permit `s3:GetObject` to the Lambda execution role in Account A. Additionally, because the S3 object is encrypted with a customer managed KMS key in Account B, the KMS key policy in Account B must explicitly permit the `kms:Decrypt` action for the external Lambda role. Local IAM policies in Account A cannot grant access to external KMS keys without the key policy delegating that permission.

Step-by-Step Solution

Examine the S3 cross-account access requirements.

For cross-account access to Amazon S3, both the identity-based policy in the source account (Account A) and the resource-based bucket policy in the destination account (Account B) must explicitly allow the operation.

Since the resource is in a different account, AWS evaluates both policies to determine authorization.

Examine the KMS cross-account access requirements.

For cross-account access to a customer managed KMS key, the KMS key policy in the owning account (Account B) must explicitly grant permission to the external account or IAM principal.

Unlike same-account KMS access where the key policy can delegate authorization to IAM policies, cross-account access requires explicit permission in the key policy itself.

Key Concept

Cross-account authorization requires resource-based policies (S3 bucket policy and KMS key policy) in the target account to explicitly trust and grant permissions to the IAM identity in the source account.

Question 43Question →

A retail e-commerce company uses an Amazon DynamoDB table to store product inventory details. During a flash sale event, the product detail page experiences a huge spike in read traffic, resulting in `ProvisionedThroughputExceededException` errors on the DynamoDB table. To resolve this and reduce read latency, a developer deploys an Amazon DynamoDB Accelerator (DAX) cluster. However, despite deploying the DAX cluster, the table continues to experience throttling and read latency remains high. Analysis reveals that the DAX cache hit rate is $0\%$ .

Which two actions should the developer take to ensure the application successfully uses the DAX cache and resolves the throttling? (Select two.)

Select all that apply

Configure the application to use the DAX client SDK and point it to the DAX cluster endpoint instead of the standard DynamoDB endpoint.

Ensure the application performs eventually consistent read requests rather than strongly consistent read requests.

Convert the application's Query operations into Scan operations to allow DAX to pre-fetch and store the entire table dataset in its query cache.

Increase the provisioned Read Capacity Units (RCUs) on the DynamoDB table and enable auto-scaling to absorb the read spikes.

Configure the application to authenticate with the DAX cluster by hardcoding the AWS access key and secret access key in the DAX client initialization code.

Show answer & explanation

Answer: Configure the application to use the DAX client SDK and point it to the DAX cluster endpoint instead of the standard DynamoDB endpoint.; Ensure the application performs eventually consistent read requests rather than strongly consistent read requests.

Answer

To resolve the issue, the developer must configure the application to use the DAX client SDK pointing to the DAX cluster endpoint, and ensure that read requests are eventually consistent rather than strongly consistent.

The correct options state that the application should be configured to use the DAX client SDK pointed to the DAX cluster endpoint and perform eventually consistent read requests. Because DAX operates as a write-through cache, applications must actively direct their API calls to the DAX cluster endpoint using the API-compatible DAX SDK. Additionally, DAX only caches eventually consistent reads. Strongly consistent reads are always passed through to the DynamoDB table directly, which continues to consume table RCUs and leads to throttling if not changed.

Step-by-Step Solution

Redirect traffic to the cache.

The application sends API calls to the DAX cluster endpoint using the DAX SDK client instead of querying the DynamoDB endpoint directly.

If the application continues to call the standard DynamoDB endpoint, the caching layer is bypassed entirely.

Review the consistency model of the read requests.

The application's queries are updated to use eventual consistency instead of strong consistency.

Strongly consistent reads bypass the DAX cache and are forwarded to the underlying DynamoDB table, causing continued resource consumption and throttling.

Key Concept

DAX endpoint configuration and consistency caching rules

Question 44Question →

A logistics company operates an IoT fleet monitoring dashboard. Telemetry data from devices is continuously written to an Amazon DynamoDB table. The table's partition key is `device_type` (which has three distinct values) and its sort key is `timestamp`. During peak periods, the application receives a high volume of writes and experiences `ProvisionedThroughputExceededException` errors. To resolve this, a developer deploys an Amazon DynamoDB Accelerator (DAX) cluster in front of the table and updates the application to write through the DAX client. However, the write throttling errors persist. Which of the following explains why the write throttling continues and provides the correct resolution?

The DAX cluster size is too small to handle the write volume. The developer should scale the DAX cluster horizontally by adding more read replicas to distribute the write traffic.

The dashboard application is executing Scan operations to locate the devices before performing updates. The developer should replace these Scan operations with Query operations to resolve the throttling.

DAX is a write-through cache and does not shield the DynamoDB table from write throttling. The developer must redesign the table schema to use a high-cardinality partition key like `device_id`.

The developer should deploy an Amazon ElastiCache for Memcached cluster to cache the write operations, as ElastiCache scales write throughput horizontally across multiple nodes.

Show answer & explanation

Answer: DAX is a write-through cache and does not shield the DynamoDB table from write throttling. The developer must redesign the table schema to use a high-cardinality partition key like `device_id`.

Answer

DAX is a write-through cache and does not shield the DynamoDB table from write throttling. The developer must redesign the table schema to use a high-cardinality partition key like `device_id` to distribute writes evenly across partitions.

The correct choice explains that Amazon DynamoDB Accelerator (DAX) is a write-through cache, meaning write requests are forwarded directly to the backend DynamoDB table. Deploying DAX does not prevent write throttling on the underlying database. The write throttling is caused by a hot partition key because the partition key (`device_type`) has low cardinality (only three values). Changing the partition key to a high-cardinality attribute like `device_id` ensures that writes are distributed across multiple partitions.

Step-by-Step Solution

Identify the operation type experiencing throttling.

The application is experiencing `ProvisionedThroughputExceededException` specifically during write operations.

Understanding whether read or write capacity is exhausted helps narrow down the effectiveness of DAX, which behaves differently for reads versus writes.

Analyze the architecture of DAX and its write behavior.

DAX is a write-through cache. Writes are written to DAX and synchronously written to the DynamoDB table.

This confirms that deploying DAX does not shield DynamoDB from write throttling.

Evaluate the table's partition key design.

The partition key `device_type` has low cardinality (only 3 unique values), leading to all write traffic targeting a few partitions.

A low-cardinality partition key causes a hot partition issue. Redesigning the schema to use a high-cardinality key like `device_id` resolves the write throttling.

Key Concept

Amazon DynamoDB Accelerator (DAX) is a write-through cache, meaning write requests are forwarded directly to the backend DynamoDB table. It does not queue or buffer write operations to protect DynamoDB from write capacity exhaustion or hot partitions. Redesigning the schema with a high-cardinality partition key is necessary to address write hot partitions.

Question 45Question →

A smart grid monitoring application named 'GridMonitor' collects electricity usage data from regional smart meters. The application writes these metrics directly to an Amazon DynamoDB table configured with provisioned write capacity. During daily peak hours, the application occasionally receives ProvisionedThroughputExceededException errors, leading to immediate transaction failures. A review of Amazon CloudWatch metrics shows that the overall write throughput is well below the provisioned capacity limit, but the application's SDK client configuration has retries disabled. Which action should the developer take to resolve these transient write errors in the most cost-effective manner?

Replace the current write logic with a Scan operation to locate and re-process failed writes.

Increase the visibility timeout of the SQS queue feeding the ingestion service to handle throttled requests.

Configure the SDK client to use exponential backoff and jitter for retries.

Hardcode the AWS credentials directly in the initialization parameters of the SDK client.

Show answer & explanation

Answer: Configure the SDK client to use exponential backoff and jitter for retries.

Answer

Configure the SDK client to use exponential backoff and jitter for retries.

Implementing exponential backoff and jitter in the SDK client allows the application to automatically retry failed requests after progressively longer intervals with randomized variation (jitter). This spreads out the retries to avoid overwhelming the database during transient spikes in traffic, making it the most cost-effective solution as it does not require provisioning extra database capacity or changing the architecture.

Step-by-Step Solution

Analyze the error metrics and application configuration.

Identify that the ProvisionedThroughputExceededException is occurring despite the table's total throughput being sufficient, indicating transient spikes, and that the SDK has retries disabled.

To pinpoint whether the issue requires scaling the table or modifying client-side retry behaviors.

Select a retry strategy that spreads requests over time.

Configure the SDK client with exponential backoff and jitter.

Exponential backoff increases wait times between consecutive retries, while jitter introduces randomness to prevent retry collisions from multiple client instances.

Deploy the updated application configuration and verify the error rate.

Transient spikes are handled gracefully by SDK retries, eliminating immediate write failures without increasing DynamoDB capacity costs.

To confirm that the solution handles the micro-bursts of traffic effectively.

Key Concept

Configuring SDK client retry policy with exponential backoff and jitter to mitigate transient DynamoDB throttling exceptions.

Question 46Question →

A multiplayer gaming application named 'QuestRealm' stores active player matchmaking lobby states in an Amazon DynamoDB table. The backend application uses the AWS SDK to write frequent updates. During peak event periods, the backend application logs show a high volume of `ProvisionedThroughputExceededException` errors, leading to lobby disconnections. A review of Amazon CloudWatch metrics indicates that the write requests are evenly distributed across all partitions, but transient traffic bursts occasionally exceed the provisioned write capacity for fractions of a second. Which action should the developer take to resolve these errors and prevent lobby disconnections?

Modify the backend application to perform a Scan operation instead of a Query operation to check partition availability before writing data.

Configure the AWS SDK client to use exponential backoff and jitter for retrying throttled request errors.

Increase the visibility timeout of the Amazon SQS queue that buffers incoming matchmaking requests to allow more time for DynamoDB updates.

Hardcode access key credentials and increase the connection timeout directly in the AWS SDK client initialization code.

Show answer & explanation

Answer: Configure the AWS SDK client to use exponential backoff and jitter for retrying throttled request errors.

Answer

Configure the AWS SDK client to use exponential backoff and jitter for retrying throttled request errors.

Since write requests are evenly distributed across partitions and throttling is caused by short-lived, transient spikes in traffic that occasionally exceed the provisioned capacity, implementing retry logic with exponential backoff and jitter on the client side is the best solution. The AWS SDKs default to standard retries, but configuring customized backoff and jitter helps smooth out the retry rate, avoiding additional throttling and allowing requests to succeed when the transient capacity burst subsides.

Step-by-Step Solution

Analyze the CloudWatch metrics and application logs to identify the error pattern.

Confirm that writes are evenly distributed (eliminating hot key/partition issues) but experience brief, transient spikes exceeding the provisioned capacity limit, causing ProvisionedThroughputExceededException.

Understanding the nature of the throttling helps differentiate between schema issues (e.g., hot partitions) and simple transient burst capacity issues.

Determine the appropriate mitigation strategy for transient write capacity throttling.

Select exponential backoff with jitter on the client SDK retries, which spaces out retry attempts to handle brief spikes without dropping requests or overloading the database.

For transient spikes, retrying with backoff allows the client to wait out the brief capacity deficit, while jitter prevents collision of simultaneous retries.

Configure the AWS SDK client settings in the backend application code.

The application now handles transient exceptions gracefully by retrying automatically with randomized delays, resolving the lobby disconnection issues.

Proper SDK client configuration ensures the application handles database-level transient errors robustly without requiring manual capacity intervention.

Key Concept

Handling transient DynamoDB write throttling with SDK retries, exponential backoff, and jitter.

Estimated Time:1m 30s

Question 47Question →

An IoT telemetry platform named "VesselTrack" monitors maritime vessel operations. It records real-time sensor updates in an Amazon DynamoDB table. The table has a provisioned write capacity of 5,000 WCU. The partition key is `vessel_type` (e.g., "Cargo", "Tanker", "Passenger") and the sort key is `timestamp`. During peak operational hours, the application experiences frequent `ProvisionedThroughputExceededException` errors when writing cargo ship telemetry, even though the total write volume across the entire table is well below the table's total provisioned WCU limit.

Which TWO actions should the developer take to resolve these throttling issues and optimize the table's performance?

Select all that apply

Redesign the partition key schema by appending a calculated hash of the vessel ID to the vessel type (e.g., Cargo#12a3) to distribute writes more evenly across partitions.

Configure the application's AWS SDK client to implement exponential backoff with jitter for all write requests.

Increase the provisioned write capacity of the table to 10,000 WCU to accommodate the write throughput for Cargo vessels.

Adjust the visibility timeout of the source Amazon SQS queue to be shorter than the DynamoDB write request timeout to prevent message processing duplicates.

Perform a DynamoDB Scan operation with a filter expression on vessel_type to group writing requests into bulk operations.

Show answer & explanation

Answer: Redesign the partition key schema by appending a calculated hash of the vessel ID to the vessel type (e.g., Cargo#12a3) to distribute writes more evenly across partitions.; Configure the application's AWS SDK client to implement exponential backoff with jitter for all write requests.

Answer

Redesign the partition key schema by appending a calculated hash of the vessel ID to the vessel type (e.g., Cargo#12a3) to distribute writes more evenly across partitions, and configure the application's AWS SDK client to implement exponential backoff with jitter for all write requests.

The ProvisionedThroughputExceededException is caused by a hot partition key ('Cargo' representing the majority of the writes), which overwhelms a single partition. Redesigning the partition key by adding a hash or suffix distributes the data across more partition keys. Additionally, configuring the AWS SDK with exponential backoff and jitter ensures that temporary retry spikes are handled gracefully.

Step-by-Step Solution

Analyze the table key schema and distribution of values.

Identify that the partition key 'vessel_type' has very low cardinality and 'Cargo' accounts for the vast majority of operations, leading to a hot partition.

DynamoDB tables partition data based on the partition key. Low cardinality partition keys with high traffic skew lead to uneven partition loading.

Apply write partition key sharding (salting).

Append a calculated hash of the vessel ID to the vessel type, which increases partition key cardinality and spreads writes across multiple physical partitions.

This resolves the structural hot partition issue by ensuring that different cargo ships write to different partition keys.

Implement exponential backoff and jitter in the application's SDK client.

The client handles transient throttling gracefully and avoids retry storms.

Randomized retry delays allow the table partitions to catch up and handle transient spikes without failing the overall request.

Key Concept

Resolving hot partition keys via key salting and handling throttling with SDK exponential backoff with jitter.

Estimated Time:2m 0s

Question 48Question →

A mobile application client receives a 502 Bad Gateway error when calling a REST API endpoint. The endpoint is configured with Amazon API Gateway using a Lambda Proxy integration. Upon reviewing the Amazon CloudWatch logs, the developer confirms that the backend Lambda function executed successfully and completed without timing out. Which of the following is the most likely cause of this error?

The REST API resource does not have CORS enabled, which blocked API Gateway from processing the backend response.

The Lambda function is returning a raw string response instead of a JSON object containing the required statusCode field.

The developer did not configure an integration response mapping template in API Gateway to convert the Lambda output.

The Lambda function's IAM execution role lacks the permissions to invoke the API Gateway endpoint.

Show answer & explanation

Answer: The Lambda function is returning a raw string response instead of a JSON object containing the required statusCode field.

Answer

The Lambda function is returning a raw string response instead of a JSON object containing the required statusCode field.

The correct answer is correct because under a Lambda Proxy integration, API Gateway expects the backend Lambda function to return a JSON object containing specific keys, including 'statusCode' and 'body'. If the function returns a raw text string, API Gateway fails to parse the output and returns a 502 Bad Gateway error to the client.

Step-by-Step Solution

Analyze the error symptoms and configuration.

The client gets a 502 Bad Gateway error, but the backend Lambda function (integrated via Lambda Proxy integration) executes successfully according to CloudWatch logs.

This indicates the connection from API Gateway to Lambda was successful, but API Gateway failed to process the response returned by Lambda.

Identify the response requirements for Lambda Proxy integration.

For Lambda Proxy integrations, API Gateway expects the backend Lambda function to return a JSON object with specific fields, such as 'statusCode', 'body', and 'headers'.

API Gateway relies on these fields to construct the HTTP response to the client.

Determine the cause of the failure.

If the Lambda function returns a raw string or JSON that does not match this format (e.g., missing the 'statusCode' field), API Gateway cannot parse it and returns a 502 Bad Gateway error.

The function executed successfully, so the issue must lie in the format of the returned payload.

Key Concept

API Gateway Lambda Proxy Integration response format requirements

Question 49Question →

A developer is troubleshooting an AWS Lambda function that processes customer orders. The function is configured to connect to an Amazon RDS PostgreSQL database in a private subnet of a custom VPC. The function also needs to call a third-party payment provider's public API endpoint over the internet. The developer configured the Lambda function to run in the public subnets of the VPC and associated it with a security group that allows all outbound traffic. During execution, the function successfully queries the database but times out when attempting to reach the payment provider's API.

Which of the following actions will resolve this connectivity issue?

Associate the Lambda function with the private subnets of the VPC, deploy a NAT Gateway in a public subnet, and route internet-bound traffic from the private subnets through the NAT Gateway.

Enable the 'Assign Public IP' setting in the Lambda function's VPC configuration to allow the function to route traffic directly through the VPC's Internet Gateway.

Add a route to the public subnet's route table with destination 0.0.0.0/0 targeting the Internet Gateway, and attach an Elastic IP address to the Lambda function's elastic network interfaces (ENIs).

Increase the Lambda function's execution timeout to 15 minutes and allocate more memory to allow the connection pool to establish a secure connection over the VPC internet route.

Show answer & explanation

Answer: Associate the Lambda function with the private subnets of the VPC, deploy a NAT Gateway in a public subnet, and route internet-bound traffic from the private subnets through the NAT Gateway.

Answer

Associate the Lambda function with the private subnets of the VPC, deploy a NAT Gateway in a public subnet, and route internet-bound traffic from the private subnets through the NAT Gateway.

The correct solution is to associate the Lambda function with the private subnets of the VPC, deploy a NAT Gateway in a public subnet, and route internet-bound traffic from the private subnets through the NAT Gateway. AWS Lambda functions associated with a VPC do not receive public IP addresses. Even if placed in a public subnet, they cannot route traffic directly to the Internet Gateway. Moving the function to private subnets and routing outbound traffic through a NAT Gateway resolves this limitation.

Step-by-Step Solution

Analyze the network configuration of the Lambda function.

Identify that the Lambda function is placed in public subnets but lacks public IP addresses, preventing direct internet access.

Lambda functions in a VPC do not get public IPs, meaning they cannot use an Internet Gateway directly.

Reconfigure the Lambda subnets.

Move the Lambda function configuration to private subnets of the VPC.

This is the standard architectural pattern for resource isolation and enabling NAT-based outbound routes.

Deploy and configure a NAT Gateway.

Set up a NAT Gateway in a public subnet and update the private subnet's route table to direct 0.0.0.0/0 traffic to the NAT Gateway.

This enables resources in the private subnets (including the Lambda function) to securely route outbound requests to the public API.

Key Concept

AWS Lambda VPC networking and outbound internet access

Question 50Question →

A developer is troubleshooting an AWS Lambda function that occasionally fails. The developer wants to monitor these failures by creating a CloudWatch metric and alarm whenever the function times out. The Lambda function has a timeout configured for 15 seconds. The log stream contains the following log event:

`2026-07-14T12:00:00.000Z 8f029cfa-13e5-4b4f-8f81-540e7912a78f Task timed out after 15.02 seconds`

The developer configures a metric filter with the filter pattern `[timestamp, request_id, message = "Task timed out*"]` to increment a custom metric named `TimeoutCount`. However, the metric remains at 0 even after subsequent timeouts occur.

Which of the following actions should the developer take to resolve this issue and successfully track the timeouts? (Select TWO.)

Select all that apply

Update the metric filter pattern to "Task timed out" (with double quotes) to match the exact phrase anywhere in the log event.

Update the metric filter pattern to [timestamp, request_id, word1 = "Task", word2 = "timed", word3 = "out"] to correctly match the individual space-delimited words in the log entry.

Grant cloudwatch:PutMetricData permissions to the Lambda function's IAM execution role so the function can publish the metric.

Increase the Lambda function's timeout configuration to 15 minutes to allow the metric filter enough time to process and publish the custom metric.

Update the metric filter pattern to [timestamp, request_id, message = "*Task timed out*"] to enable wildcard matching for the message field.

Show answer & explanation

Answer: Update the metric filter pattern to "Task timed out" (with double quotes) to match the exact phrase anywhere in the log event.; Update the metric filter pattern to [timestamp, request_id, word1 = "Task", word2 = "timed", word3 = "out"] to correctly match the individual space-delimited words in the log entry.

Answer

Update the metric filter pattern to "Task timed out" (with double quotes) and update the metric filter pattern to [timestamp, request_id, word1 = "Task", word2 = "timed", word3 = "out"].

The correct options are: updating the metric filter pattern to use the exact phrase "Task timed out" in double quotes, and updating the metric filter pattern to use individual space-delimited words. The first option works because enclosing a phrase in double quotes instructs CloudWatch Logs to search for the literal substring anywhere in the log event, bypassing field parsing. The second option works because it maps each space-separated term (e.g., 'Task', 'timed', 'out') to individual fields, matching the actual log structure.

Step-by-Step Solution

Analyze the log format and the failing filter pattern.

The log event is space-delimited: `2026-07-14T12:00:00.000Z 8f029cfa-13e5-4b4f-8f81-540e7912a78f Task timed out after 15.02 seconds`. The third field contains only 'Task', not the entire phrase 'Task timed out'.

Understanding why the current filter pattern `[timestamp, request_id, message = "Task timed out*"]` fails to match.

Identify correct string matching patterns in CloudWatch Logs.

Using a literal term search like `"Task timed out"` in double quotes matches the exact phrase anywhere in the log line.

Literal phrase matching is the simplest way to find multi-word strings without defining complex space-delimited fields.

Identify correct space-delimited field structures.

Represent the log event fields individually: `[timestamp, request_id, word1 = "Task", word2 = "timed", word3 = "out"]`.

This maps each space-separated word to a separate variable and matches them exactly, which is valid for space-delimited filtering.

Key Concept

CloudWatch Logs Metric Filter pattern syntax and space-delimited log parsing rules.

Question 51Question →

An application deployed on AWS Fargate publishes structured JSON logs to an Amazon CloudWatch Logs log group. Each log event contains fields such as `latency`, `statusCode`, `path`, and `userId`. A developer is tasked with creating a CloudWatch Logs Insights query to analyze application performance. The query must calculate the $95\text{th}$ percentile of latency for all requests and count the number of server errors (where `statusCode` is $500$ or greater). The results must be grouped by the API `path` and aggregated into $5$ -minute intervals. Which CloudWatch Logs Insights query should the developer use to meet these requirements?

fields @timestamp, path, latency, statusCode | filter statusCode >= 500 | stats pct(latency, 95) as p95_latency, count() as error_count by path, bin(5m)

fields @timestamp, path, latency, statusCode | stats pct(latency, 95) as p95_latency, count(statusCode >= 500) as error_count by path, bin(5m)

fields @timestamp, path, latency, statusCode | stats pct(latency, 95) as p95_latency, sum(statusCode >= 500) as error_count by path, bin(5m)

fields @timestamp, path, latency, statusCode | stats pct(latency, 95) as p95_latency, count() filter(where statusCode >= 500) as error_count by path, bin(5m)

Show answer & explanation

Answer: fields @timestamp, path, latency, statusCode | stats pct(latency, 95) as p95_latency, sum(statusCode >= 500) as error_count by path, bin(5m)

Answer

The query that uses the sum function with a conditional expression inside stats: 'fields @timestamp, path, latency, statusCode | stats pct(latency, 95) as p95_latency, sum(statusCode >= 500) as error_count by path, bin(5m)'

The correct query uses sum(statusCode >= 500) inside the stats command. In CloudWatch Logs Insights, boolean expressions inside aggregation functions evaluate to 1 for true and 0 for false. Therefore, summing the expression statusCode >= 500 effectively counts only the events where the status code indicates a server error, while allowing the percentile function pct(latency, 95) to be calculated over the entire dataset without prior filtering.

Step-by-Step Solution

Determine where to place the filtering/conditional logic to ensure latency is calculated over all requests.

Avoid using a top-level '| filter statusCode >= 500' command, as it would prematurely discard successful requests before the latency calculation.

A top-level filter restricts the input dataset to only matching records, skewing overall metrics like latency percentiles.

Select the correct conditional aggregation function in CloudWatch Logs Insights.

Use 'sum(statusCode >= 500)' to sum the boolean results (1 for true, 0 for false).

Boolean expressions inside 'sum()' evaluate to 1 when true and 0 when false, which acts as a conditional count.

Group and bin the aggregated results.

Use 'by path, bin(5m)' at the end of the 'stats' command.

This groups the calculated statistics by the request path and segments them into 5-minute time intervals.

Key Concept

Conditional aggregation in CloudWatch Logs Insights stats command

Estimated Time:1m 30s

Question 52Question →

A developer is deploying a containerized application to Amazon ECS using AWS Fargate. During task startup, the container fails to launch. The ECS service events reveal that the task is unauthorized to pull the application image from Amazon Elastic Container Registry (ECR). In addition, the container is configured to retrieve a database secret from AWS Secrets Manager at startup, which is also failing. The developer verifies that the IAM policy attached to the ECS Task Role (task_role_arn) has the necessary ecr:GetDownloadUrlForLayer, ecr:BatchGetImage, and secretsmanager:GetSecretValue permissions.

What action should the developer take to resolve these authorization failures?

Configure an Amazon Cognito Identity Pool to exchange temporary credentials during task initialization.

Update the trust policy of the ECS Task Role to allow the Secrets Manager service principal (secretsmanager.amazonaws.com) to assume the role.

Embed the ECR registry credentials and Secrets Manager secrets directly inside the application's source code.

Attach the required permissions to the ECS Task Execution Role instead of the ECS Task Role.

Show answer & explanation

Answer: Attach the required permissions to the ECS Task Execution Role instead of the ECS Task Role.

Answer

Attach the required permissions to the ECS Task Execution Role instead of the ECS Task Role.

The Amazon ECS container agent makes the API calls to pull the container image from Amazon ECR and to retrieve secrets from AWS Secrets Manager during the task bootstrap phase. These operations occur before the application container is running. Therefore, the permissions must be attached to the ECS Task Execution Role, not the ECS Task Role (which is used by the application code once running).

Step-by-Step Solution

Identify the entity performing the unauthorized actions during the task bootstrap phase.

Determine that the Amazon ECS container agent (not the application code) pulls the image from Amazon ECR and retrieves secrets from AWS Secrets Manager.

Understanding which entity performs these tasks is essential to choosing the correct IAM role.

Distinguish between the ECS Task Role and the ECS Task Execution Role.

The ECS Task Role is assumed by the containers after they start to make AWS API calls from application code. The ECS Task Execution Role is used by the ECS container agent to perform actions on behalf of the task before the container runs.

Matching the bootstrap permissions to the correct role prevents authorization errors during initialization.

Move the permissions to the correct role.

Attach the Amazon ECR and Secrets Manager permissions to the ECS Task Execution Role.

This grants the ECS container agent the authority to pull the container image and read the secret required to start the task.

Key Concept

ECS Task Role vs. ECS Task Execution Role permissions

Question 53Question →

A developer is monitoring a payment processing application deployed on Amazon EC2. The Unified CloudWatch Agent is configured to stream application logs to a CloudWatch Logs log group named `/aws/ec2/PaymentService`. The application outputs logs in the following JSON format:

{
"timestamp": "2026-07-14T12:00:00Z",
"status": "FAILED",
"executionTimeMs": 4500,
"errorDetails": {
"category": "GatewayTimeout",
"attempt": 3
}
}

The developer needs to create a CloudWatch Alarm that triggers when there are more than 5 occurrences of failed executions due to a `GatewayTimeout` where the number of attempts is greater than 2 within a 5-minute window.

Which of the following actions should the developer take to implement this monitoring solution? (Select TWO.)

Select all that apply

Create a CloudWatch Logs metric filter on the `/aws/ec2/PaymentService` log group with the filter pattern `{

.status = "FAILED" &&

.errorDetails.category = "GatewayTimeout" && $.errorDetails.attempt > 2 }`.

Create a CloudWatch Logs metric filter on the `/aws/ec2/PaymentService` log group with the space-delimited filter pattern `[timestamp, status = "FAILED", executionTimeMs, category = "GatewayTimeout", attempt > 2]`.

Create a CloudWatch Alarm that monitors the custom metric generated by the metric filter, configuring it to trigger when the metric value is greater than 5 within an evaluation period of 5 minutes.

Create a CloudWatch Logs subscription filter with a destination of Amazon EventBridge, and configure an EventBridge rule to match the error patterns and route them to an alarm.

Configure the Unified CloudWatch Agent configuration file (`amazon-cloudwatch-agent.json`) on the EC2 instances with a custom metric parsing rule to extract the JSON properties and publish them directly to CloudWatch Metrics.

Show answer & explanation

Answer: Create a CloudWatch Logs metric filter on the `/aws/ec2/PaymentService` log group with the filter pattern `{ $.status = "FAILED" &&$ .errorDetails.category = "GatewayTimeout" && $.errorDetails.attempt > 2 }`.; Create a CloudWatch Alarm that monitors the custom metric generated by the metric filter, configuring it to trigger when the metric value is greater than 5 within an evaluation period of 5 minutes.

Answer

The developer should create a CloudWatch Logs metric filter using the JSON syntax `{

.status = "FAILED" &&

.errorDetails.category = "GatewayTimeout" && $.errorDetails.attempt > 2 }` and create a CloudWatch Alarm that monitors the metric and triggers when it is greater than 5 over a 5-minute evaluation period.

The correct options involve creating a metric filter with JSON syntax and establishing an alarm based on that filter's metric. The JSON syntax `{

.status = "FAILED" &&

.errorDetails.category = "GatewayTimeout" && $.errorDetails.attempt > 2 }` correctly parses the log structure to filter relevant log entries, and the alarm monitors the resulting metric over the 5-minute interval.

Step-by-Step Solution

Analyze the log structure to determine the appropriate CloudWatch Logs filter syntax.

The log format is JSON with nested fields under `errorDetails`.

Since the log is structured JSON, the developer must use CloudWatch Logs JSON filter syntax using curly braces `{}` rather than space-delimited square brackets `[]`.

Define the JSON filter pattern using standard property selectors.

The pattern is defined as `{

.status = "FAILED" &&

.errorDetails.category = "GatewayTimeout" && $.errorDetails.attempt > 2 }`.

This matches events where the top-level field `status` equals `FAILED`, the nested field `category` equals `GatewayTimeout`, and the nested field `attempt` is strictly greater than 2.

Configure a CloudWatch Alarm on the custom metric created by the metric filter.

A CloudWatch Alarm is configured to monitor the custom metric, evaluating if the metric exceeds the threshold of 5 within a 5-minute window.

Alarms are required to notify or take action when a metric crosses a specified threshold over a defined period of time.

Key Concept

CloudWatch Logs Metric Filters syntax and structure for JSON logs

Question 54Question →

An application deployed on Amazon ECS using AWS Fargate starts successfully, but the application code fails with an AccessDeniedException when attempting to read messages from an Amazon SQS queue. The developer verifies that the SQS queue policy does not explicitly deny access. The task definition currently includes an IAM role specified in the executionRoleArn parameter which has the AmazonSQSReadOnlyAccess policy attached. Which of the following actions should the developer take to resolve this authorization failure?

Modify the trust policy of the ECS task execution role to allow the SQS service principal to assume the role.

Configure an Amazon Cognito Identity Pool to exchange the container's execution credentials for temporary SQS credentials.

Specify an IAM role with SQS permissions in the taskRoleArn parameter of the task definition.

Add sqs:ReceiveMessage permissions to the IAM role specified in the executionRoleArn parameter of the task definition.

Show answer & explanation

Answer: Specify an IAM role with SQS permissions in the taskRoleArn parameter of the task definition.

Answer

Specify an IAM role with SQS permissions in the taskRoleArn parameter of the task definition.

The correct answer is to specify the SQS permission policy on the task role (taskRoleArn). The ECS Task Role is designed to grant AWS API permissions to the application code running inside the container. In contrast, the ECS Task Execution Role (executionRoleArn) is used by the ECS container agent for actions like pulling container images from Amazon ECR and sending logs to CloudWatch.

Step-by-Step Solution

Identify the distinction between the ECS Task Execution Role and the ECS Task Role.

The Task Execution Role is used by the ECS container agent (e.g., to pull ECR images, send logs to CloudWatch, retrieve secrets), whereas the Task Role is assumed by the application code running inside the container.

Resolving permission issues requires identifying which role credentials the failing API call is using.

Locate where application-level permissions are configured in the ECS task definition.

The parameter taskRoleArn holds the IAM role containing permission policies for AWS services like SQS, S3, or DynamoDB invoked by the application.

Configuring permissions on executionRoleArn will result in authorization failures for the containerized application.

Assign the correct IAM role with SQS permissions to the taskRoleArn parameter and deploy the task.

The containerized application successfully receives credentials with sqs:ReceiveMessage permissions from the task metadata endpoint.

This links the correct permissions to the running application process.

Key Concept

ECS Task Role vs Task Execution Role permission boundaries

Estimated Time:1m 30s

Question 55Question →

An application logs processing metrics to Amazon CloudWatch Logs in JSON format. A developer needs to write an Amazon CloudWatch Logs Insights query to analyze application performance. The query must only include log events where the `durationMs` field is present. Additionally, the query must calculate both the average and the 95th percentile of `durationMs` grouped in 10-minute intervals. Which TWO CloudWatch Logs Insights query clauses must the developer include to meet these requirements?

Select all that apply

filter ispresent(durationMs)

stats avg(durationMs), pct(durationMs, 95) by bin(10m)

filter durationMs exists

stats mean(durationMs), pct(durationMs, 95) by bin(10m)

stats avg(durationMs), pct(durationMs, 95) by 10m

Show answer & explanation

Answer: filter ispresent(durationMs); stats avg(durationMs), pct(durationMs, 95) by bin(10m)

Answer

The correct query clauses are the filter clause with the ispresent function and the stats clause using the avg and pct functions grouped by the bin function.

The filter clause utilizing the ispresent function correctly filters for events where the specific field exists. The stats clause correctly calculates the average using avg and the percentile using pct, and groups them in 10-minute buckets using the bin function.

Step-by-Step Solution

Identify the clause needed to filter log events based on the existence of a field.

The query must use the filter command combined with the ispresent(field) function.

This excludes log events that do not contain the target field from the calculation.

Determine the correct aggregation functions for average and percentile calculations.

Use the avg() function for average and the pct() function for percentiles.

CloudWatch Logs Insights query syntax specifies avg and pct (or percentile) as the supported aggregation operations.

Determine the syntax to group logs into temporal buckets.

Use the by bin(10m) clause.

The bin function is required to group aggregate statistics into discrete time buckets like 10-minute intervals.

Key Concept

Writing syntactically correct CloudWatch Logs Insights queries to filter and aggregate log data.

Question 56Question →

A logistics routing application named ShipVerify processes shipment status updates and writes them to an Amazon DynamoDB table. The table uses ShipmentID as the partition key. During peak delivery hours, the application experiences a surge in updates for a small subset of high-volume merchant shipments. This results in frequent ProvisionedThroughputExceededException errors, even though the overall write capacity units consumed by the table are well below the provisioned limits. Which of the following actions should the developer take to resolve this issue?

Change the read operations in the application to execute a table Scan rather than a Query to locate shipment records.

Redesign the partition key schema by appending a random suffix to the partition key value for high-volume shipments to distribute writes across multiple partition keys.

Increase the visibility timeout of the Amazon SQS queue that feeds the updates to ensure messages are not retried too quickly.

Hardcode the AWS IAM access keys directly within the AWS SDK client configuration to reduce latency from credential retrieval.

Show answer & explanation

Answer: Redesign the partition key schema by appending a random suffix to the partition key value for high-volume shipments to distribute writes across multiple partition keys.

Answer

Redesign the partition key schema by appending a random suffix to the partition key value for high-volume shipments to distribute writes across multiple partition keys.

The correct answer is correct because appending a random suffix to the partition key (write sharding) distributes writes across multiple partitions. This prevents a single partition key from absorbing all the write volume and exceeding the per-partition throughput limit of DynamoDB.

Step-by-Step Solution

Analyze the error metrics and access patterns on the DynamoDB table.

Identify that the ProvisionedThroughputExceededException is concentrated on a small set of partition keys (hot keys) due to high-volume merchant shipments.

To pinpoint if the throttling is a result of hot partition limits rather than total table capacity limits.

Determine the strategy for distributing writes to resolve the hot partition.

Decide on appending a random suffix to the ShipmentID key value for high-volume shipments.

To distribute the writes for the same logical shipment across multiple physical partitions, which stays within individual partition throughput limits.

Adjust the write logic in the application to write keys with a random suffix, and query accordingly.

Traffic is successfully balanced across multiple partitions, eliminating ProvisionedThroughputExceededException errors.

To apply the write sharding design pattern which scales write throughput horizontally across partitions.

Key Concept

Write sharding using random suffixes to distribute traffic on a hot partition key in DynamoDB.

Question 57Question →

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 58Question →

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 59Question →

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 60Question →

A developer is troubleshooting an application where an AWS Lambda function processes batch orders from an Amazon SQS standard queue. The Lambda function is configured with a timeout of 45 seconds and a batch size of 10 messages. The SQS queue is configured with a visibility timeout of 60 seconds and a redrive policy targeting a Dead-Letter Queue (DLQ) with a maxReceiveCount of 3. During peak hours, the developer observes that some messages are processed multiple times by different Lambda invocations, and the DLQ receives an increased number of messages, even though no errors are logged by the function code. CloudWatch Logs indicate that some executions time out at 45 seconds under heavy database load, while others complete in under 5 seconds. Which of the following changes should the developer make to resolve these issues?

Enable 'Report Batch Item Failures' on the Lambda event source mapping, modify the function to return a list of failed message IDs in the response, and increase the SQS queue's visibility timeout to 270 seconds.

Deploy the Lambda function in a VPC with private subnets, configure an interface VPC Endpoint for Amazon SQS, and update the function's IAM execution role to allow SQS DeleteMessage actions.

Decrease the SQS queue's visibility timeout to 15 seconds to trigger faster retries when the database is congested, and increase the Lambda function memory size to 3008 MB.

Implement a global SQS client helper outside the Lambda handler to manually delete processed messages from the queue, and increase the Lambda function timeout to 90 seconds.

Show answer & explanation

Answer: Enable 'Report Batch Item Failures' on the Lambda event source mapping, modify the function to return a list of failed message IDs in the response, and increase the SQS queue's visibility timeout to 270 seconds.

Answer

Enabling 'Report Batch Item Failures' on the event source mapping and returning the `batchItemFailures` array containing the failed message IDs ensures that SQS deletes the successfully processed messages and only retries the ones that failed. Furthermore, increasing the SQS visibility timeout to 270 seconds aligns with the AWS recommendation of setting the visibility timeout to at least 6 times the Lambda function timeout (

6 \times 45 = 270

seconds) to accommodate processing delays and retries.

Step-by-Step Solution

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

The current visibility timeout is 60 seconds, which is only slightly higher than the Lambda timeout of 45 seconds. AWS best practice recommends that SQS visibility timeout should be configured to at least 6 times the Lambda function's timeout (

6 \times 45 = 270

seconds) to prevent messages from becoming visible again during retry cycles.

Ensuring the visibility timeout is appropriately scaled prevents duplicate processing of active invocations.

Analyze the cause of duplicate processing when Lambda times out on a batch of SQS messages.

By default, if a Lambda function times out or throws an error while processing a batch, SQS considers the entire batch of 10 messages to have failed. Consequently, successfully processed messages in that same batch are not deleted and will be reprocessed, causing duplicate writes.

Identifying why successfully processed messages are being sent back to the queue.

Determine the solution for handling partial batch failures.

Enabling 'Report Batch Item Failures' in the SQS event source mapping allows the Lambda function to return a list of failed message IDs (under the keys `batchItemFailures` and `itemIdentifier`). SQS then deletes only the successful messages from the queue and retries only the failed ones.

Configuring the Lambda function to safely handle partial failures without reprocessing successful messages.

Key Concept

SQS Event Source Mapping, Partial Batch Failures, and Visibility Timeout Alignment.

Estimated Time:3m 0s

PreviousPage 3 / 14Next

Troubleshooting and Optimization

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