Troubleshooting and Optimization

271 questions

All types271 Multiple choice138 Multiple select133

An IoT telemetry ingestion application uses an AWS Lambda function to process device log files uploaded to an Amazon S3 bucket. The function parses the logs and sends alerts to an external monitoring API on the public internet. To securely query an Amazon ElastiCache Redis cluster, the Lambda function is configured to run inside private subnets of a VPC. The developer notices that the function successfully queries Redis but fails to send alerts to the external monitoring API, resulting in connection timeouts. Furthermore, under peak load, some executions are terminated prematurely before completion.

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

Select all that apply

Configure a NAT gateway in a public subnet of the VPC, and update the route table of the Lambda function's private subnets to route 0.0.0.0/0 to the NAT gateway.

Increase the function's execution timeout setting in the AWS Lambda configuration.

Enable the public IP assignment setting in the VPC configuration of the Lambda function.

Attach an Internet Gateway directly to the private subnets and update their route tables to direct 0.0.0.0/0 traffic to it.

Move the Redis connection initialization inside the Lambda handler function to prevent the execution context from reusing stale connections that cause timeouts.

Show answer & explanation

Answer: Configure a NAT gateway in a public subnet of the VPC, and update the route table of the Lambda function's private subnets to route 0.0.0.0/0 to the NAT gateway.; Increase the function's execution timeout setting in the AWS Lambda configuration.

Answer

The developer should configure a NAT gateway in a public subnet with a route in the private subnets' route table, and increase the execution timeout in the Lambda function's configuration.

To resolve the network connectivity issue, a NAT gateway must be set up in a public subnet, and the route table for the private subnets (where the Lambda function runs) must route outbound traffic (0.0.0.0/0) to the NAT gateway. To resolve the premature termination issue under peak load, the Lambda function's timeout configuration must be increased to allow enough time for processing larger logs.

Step-by-Step Solution

Diagnose the connection timeouts to the external API.

Identify that the Lambda function is in private subnets and lacks internet access because it does not have a route to a NAT gateway.

Lambda functions in a VPC require a NAT gateway or NAT instance to route traffic to the public internet.

Configure outbound internet access for the VPC private subnets.

Provision a NAT gateway in a public subnet and update the private subnets' route tables to send all 0.0.0.0/0 traffic to the NAT gateway.

This allows the Lambda function in the private subnets to send requests to the external monitoring API while retaining internal access to the ElastiCache cluster.

Diagnose the premature termination of Lambda executions under peak load.

Recognize that the execution time is exceeding the configured Lambda timeout limit.

Heavier payloads or peak traffic require longer processing times, so the Lambda execution timeout configuration must be increased.

Key Concept

Configuring VPC networking for Lambda internet access and managing Lambda execution timeouts

Question 122Question →

A developer is troubleshooting a local C# application that uses the AWS SDK for .NET to publish messages to an Amazon SNS topic. During local testing, the application publishes messages to the production AWS account instead of the development AWS account.

The developer has set the AWS_PROFILE environment variable to development-profile in the active terminal session. The local ~/.aws/credentials file is configured as follows:

ini
[default]
aws_access_key_id = AKIA_PROD_KEY
aws_secret_access_key = PROD_SECRET

[development-profile]
aws_access_key_id = AKIA_DEV_KEY
aws_secret_access_key = DEV_SECRET

Upon investigation, the developer discovers that the environment variables AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY are also set to the production keys within the same terminal session.

Why is the application using the production credentials, and how should the developer resolve this issue?

The AWS SDK loads credentials from the global configuration file before evaluating environment variables. To resolve this, the developer must modify the ~/.aws/config file to set profile_precedence = development-profile.

The AWS SDK default credential provider chain evaluates environment variables before looking up profiles in the shared credentials file. To resolve this, the developer must unset the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables in the terminal session.

The AWS SDK cannot parse the credentials file because the local developer's IAM user lacks a trust policy mapping. To resolve this, the developer must update the development IAM trust policy to allow the local machine to assume the role.

The AWS SDK retrieves the production credentials from AWS Systems Manager Parameter Store, which overrides local configuration settings. To resolve this, the developer must delete the production credentials parameters from the Parameter Store.

Show answer & explanation

Answer: The AWS SDK default credential provider chain evaluates environment variables before looking up profiles in the shared credentials file. To resolve this, the developer must unset the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables in the terminal session.

Answer

The AWS SDK default credential provider chain evaluates environment variables before looking up profiles in the shared credentials file. To resolve the issue, the developer must unset the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables in the terminal session.

The default credential provider chain in the AWS SDK resolves credentials in a specific order of precedence. Environment variables (such as AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY) are checked first. If they are present, the SDK uses them and stops looking. Shared credentials profiles (configured via AWS_PROFILE and ~/.aws/credentials) are evaluated later in the chain. Therefore, because the production keys were set in the environment variables, they took precedence over the AWS_PROFILE environment variable. Unsetting AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY from the environment allows the SDK to fall back to the credentials file and correctly use the profile specified by AWS_PROFILE.

Step-by-Step Solution

Analyze the active terminal environment variables and identify configured AWS credentials.

Discovered that the terminal has AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY set to production keys, alongside AWS_PROFILE set to the development profile.

The AWS SDK relies on the default credential provider chain, which checks environment variables first.

Evaluate the order of precedence in the AWS SDK default credential provider chain.

Identified that environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY) take precedence over the shared credentials file and the AWS_PROFILE setting.

Since environment variables are found first, the SDK uses them directly and ignores the AWS_PROFILE setting.

Unset the production credential environment variables in the terminal.

Executing 'unset AWS_ACCESS_KEY_ID' and 'unset AWS_SECRET_ACCESS_KEY' removes the environment-level overrides.

Removing these variables forces the AWS SDK to fall back to the next level in the provider chain, which is the shared credentials file, allowing it to correctly load the profile specified by AWS_PROFILE.

Key Concept

AWS SDK Default Credential Provider Chain Order of Precedence

Question 123Question →

A developer is troubleshooting a serverless application where an AWS Lambda function is triggered by an Amazon SQS queue. The Lambda function processes incoming messages, invokes a downstream third-party REST API using the Python `requests` library, and records metrics. During testing under high load, the developer notices two main issues:

1. Downstream third-party REST API calls do not appear as subsegments in the AWS X-Ray service map.
2. Many messages are being processed multiple times by the Lambda function, resulting in duplicate API calls and redundant traces.

Which two actions must the developer take to resolve these issues?

Select all that apply

Use the AWS X-Ray SDK for Python to patch the requests library at the start of the Lambda function code.

Increase the visibility timeout of the SQS queue to be at least

6

times the execution timeout of the Lambda function.

Reconfigure the Lambda integration in Amazon API Gateway from proxy integration to custom integration and manually map the HTTP headers in the integration request template.

Hardcode temporary AWS IAM credentials retrieved from AWS STS inside the Lambda function initialization code to authorize the X-Ray recorder client.

Increase the Lambda function's execution timeout to match the SQS queue's message retention period to prevent trace context loss during execution context reuse.

Show answer & explanation

Answer: Use the AWS X-Ray SDK for Python to patch the requests library at the start of the Lambda function code.; Increase the visibility timeout of the SQS queue to be at least $6$ times the execution timeout of the Lambda function.

Answer

To resolve these issues, the developer must patch the requests library using the AWS X-Ray SDK for Python and increase the SQS queue's visibility timeout to be at least

6

times the Lambda function's execution timeout.

To trace downstream HTTP calls made via the Python requests library, the developer must patch the library using the AWS X-Ray SDK for Python. This dynamically instruments HTTP client libraries to generate tracing subsegments for outgoing HTTP requests. Additionally, under high load, if the SQS queue's visibility timeout is too close to the Lambda function's execution timeout, messages may return to the queue and be processed by other concurrent invocations before the original execution finishes. Setting the SQS visibility timeout to at least

6

times the Lambda execution timeout prevents these duplicate invocations and the resulting redundant traces.

Step-by-Step Solution

Analyze downstream HTTP tracing requirement.

Identify that third-party HTTP libraries like Python requests are not automatically instrumented by X-Ray unless they are patched using the AWS X-Ray SDK.

Patching ensures that the HTTP client library intercepts outgoing calls and generates the appropriate subsegments in the trace.

Diagnose duplicate message processing under load.

Recognize that messages processed multiple times usually indicate that the SQS visibility timeout is shorter than the time Lambda takes to process and delete the message.

If the visibility timeout is too short, other Lambda invocations poll the same message before the original execution finishes, leading to duplicate executions.

Determine the correct configuration adjustments.

Patch the requests library using the SDK, and set the SQS queue's visibility timeout to at least

6

times the Lambda timeout.

This implements the recommended AWS best practice for SQS-Lambda integrations to prevent duplicate processing, and successfully captures downstream API tracing details.

Key Concept

Instrumenting HTTP libraries with AWS X-Ray SDK and configuring SQS visibility timeouts for Lambda integration.

Estimated Time:2m 30s

Question 124Question →

A developer has enabled active tracing on an AWS Lambda function that uses the AWS SDK for Python (boto3) to write data to an Amazon DynamoDB table. Although the Lambda function's execution is traced, the downstream calls to DynamoDB are missing from the AWS X-Ray service map. Which action must the developer take to include the DynamoDB calls in the X-Ray trace?

Instrument the AWS SDK by using the patch_all or patch function from the X-Ray SDK in the Lambda function code.

Increase the Lambda function's timeout configuration to allow the service execution context to persist longer.

Configure the API Gateway integration type to use Lambda Custom integration to pass raw request payloads.

Increase the Amazon SQS visibility timeout to prevent messages from returning to the queue during tracing.

Show answer & explanation

Answer: Instrument the AWS SDK by using the patch_all or patch function from the X-Ray SDK in the Lambda function code.

Answer

Instrument the AWS SDK by using the patch_all or patch function from the X-Ray SDK in the Lambda function code.

The correct answer is to instrument the AWS SDK by using the patch_all or patch function from the X-Ray SDK in the Lambda function code. While enabling active tracing on the Lambda function configuration creates the parent trace segment, the AWS SDK client inside the code must be instrumented using the X-Ray SDK so that outgoing API calls to services like DynamoDB are recorded as subsegments.

Step-by-Step Solution

Analyze the tracing configuration.

Active tracing is enabled on the Lambda function, which creates the main segment, but downstream AWS SDK calls are not being intercepted.

By default, enabling active tracing on Lambda only traces the function's entry, initialization, and execution. Outgoing calls via the AWS SDK require explicit library instrumentation.

Identify the mechanism for SDK instrumentation.

The AWS SDK client needs to be wrapped or patched by the AWS X-Ray SDK.

Instrumenting the SDK allows the X-Ray library to automatically capture subsegments for downstream AWS API requests (like DynamoDB) and link them to the parent segment.

Select the correct SDK function.

In Python, the developer should use the patch or patch_all function from the X-Ray SDK.

Calling patch_all() dynamically patches supported libraries, including boto3, ensuring all outgoing calls to DynamoDB are traced.

Key Concept

AWS X-Ray SDK Instrumentation

Estimated Time:45s

Question 125Question →

A client-side web application hosted on `https://portal.example.com` attempts to send a `DELETE` request to a resource on a REST API hosted on Amazon API Gateway. The API utilizes a Lambda Proxy Integration. The browser console displays an error stating that the request has been blocked by CORS policy because no 'Access-Control-Allow-Origin' header is present on the requested resource.

Which TWO actions must the developer take to resolve this issue?

Select all that apply

Enable CORS on the resource in the Amazon API Gateway console to configure the OPTIONS method.

Update the backend Lambda function response to include the Access-Control-Allow-Origin header.

Configure a CORS configuration rule on the Amazon S3 bucket hosting the web application to allow requests from the API Gateway domain.

Configure the API Gateway integration to return a raw text response rather than a structured JSON payload.

Create an API Gateway custom Lambda Authorizer that intercepts the preflight request and returns a policy allowing the origin.

Show answer & explanation

Answer: Enable CORS on the resource in the Amazon API Gateway console to configure the OPTIONS method.; Update the backend Lambda function response to include the Access-Control-Allow-Origin header.

Answer

Enable CORS on the resource in the Amazon API Gateway console to configure the OPTIONS method, and update the backend Lambda function response to include the Access-Control-Allow-Origin header.

Resolving a CORS issue for a DELETE request requires two configuration steps. First, configuring the OPTIONS preflight method in API Gateway ensures that preflight CORS verification passes. Second, because Lambda Proxy Integration is utilized, the Lambda function itself must return the Access-Control-Allow-Origin header in its response envelope.

Step-by-Step Solution

Configure the preflight response in API Gateway.

The OPTIONS method is enabled for the resource, returning the CORS headers needed to pass the initial preflight check.

Before sending a DELETE request, the browser performs a preflight OPTIONS check to verify if the destination server allows cross-origin requests.

Inject CORS headers in the Lambda proxy response.

The Lambda function returns a JSON response containing 'headers': {'Access-Control-Allow-Origin': 'https://portal.example.com'}.

Under Lambda Proxy Integration, API Gateway does not alter the backend response to add CORS headers, so the Lambda function must return them explicitly.

Key Concept

Handling CORS with Lambda Proxy Integrations requires configuring both the preflight OPTIONS method in API Gateway and the custom response headers inside the backend Lambda code.

Estimated Time:1m 30s

Question 126Question →

A developer has deployed a Python-based AWS Lambda function that synchronizes real-time multiplayer game leaderboards with an external third-party API and retrieves player metadata from an Amazon ElastiCache (Memcached) cluster located in a private VPC subnet. The Lambda function is configured to run inside the VPC and is associated with the private subnet containing the ElastiCache cluster. During load testing, the developer observes two symptoms: 1. The function is able to connect to the ElastiCache cluster, but all requests to the external third-party leaderboard API fail with a connection timeout error. 2. Under sustained high concurrent load, subsequent invocations of the Lambda function occasionally process stale player metadata that was cached during earlier invocations of the same execution context. Which two actions should the developer take to resolve these issues? (Select TWO.)

Select all that apply

Configure the Lambda function to run in private subnets that have a route pointing to a NAT Gateway located in a public subnet of the VPC.

Modify the function code to clear or reinitialize global/module-level variables holding the cached player metadata at the start of each handler invocation.

Associate the Lambda function with a public subnet of the VPC and enable auto-assign public IP on the network interface to establish direct outbound routing.

Increase the Lambda function's timeout configuration to allow the global execution context to automatically refresh and purge its in-memory state between consecutive invocations.

Configure the Lambda execution role to allow the 'ec2:CreateNetworkInterface' and 'ec2:DescribeNetworkInterfaces' actions on the public subnets to bridge the external route.

Show answer & explanation

Answer: Configure the Lambda function to run in private subnets that have a route pointing to a NAT Gateway located in a public subnet of the VPC.; Modify the function code to clear or reinitialize global/module-level variables holding the cached player metadata at the start of each handler invocation.

Answer

Configure the Lambda function to run in private subnets that have a route pointing to a NAT Gateway located in a public subnet of the VPC, and modify the function code to clear or reinitialize global/module-level variables holding the cached player metadata at the start of each handler invocation.

The correct solution involves routing outbound traffic through a NAT Gateway for internet access (resolving the timeout to the external API) and reinitializing global variables within the handler (resolving the stale data issue caused by context reuse).

Step-by-Step Solution

Analyze the networking issue (Symptom 1)

Identify that the Lambda function is running in a private VPC subnet without outbound internet access, causing connections to the external API to time out.

VPC-connected Lambda functions require a NAT Gateway or VPC endpoints to access external endpoints.

Determine the required VPC networking configuration

Ensure the Lambda function is placed in private subnets whose route tables direct traffic to a NAT Gateway in a public subnet.

This establishes outbound internet connectivity while keeping the function securely isolated.

Analyze the state/cache issue (Symptom 2)

Identify that global variables are retaining player metadata across reused execution contexts.

AWS Lambda reuses containers (execution contexts) for performance, carrying over state declared outside the handler.

Implement the code fix for execution context reuse

Update the Lambda code to clear or reinitialize global metadata caches inside the handler method at the beginning of each execution.

This guarantees that each new request processes fresh data regardless of whether the execution context is new or reused.

Key Concept

AWS Lambda VPC networking outbound routing and execution context variable persistence.

Question 127Question →

A developer manages a CI/CD pipeline in AWS CodePipeline. The pipeline has an AWS CodeBuild project that packages an application and an AWS CloudFormation deploy stage that performs a stack update. During a execution, the pipeline fails with two errors:

1. The CodeBuild project fails during the pre-build phase with the error: 'An error occurred (AccessDenied) when calling the AssumeRole operation: Role: arn:aws:iam::111122223333:role/CrossAccountDeployRole is not authorized to perform: sts:AssumeRole'.
2. The CloudFormation deployment fails immediately because the target stack is stuck in the UPDATE_ROLLBACK_FAILED state due to a resource that failed to clean up during a previous rollback.

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

Select all that apply

Update the trust policy of the CrossAccountDeployRole in account 111122223333 to allow the CodeBuild service role in the source account to perform the sts:AssumeRole action.

Run the continue-update-rollback command on the CloudFormation stack, optionally specifying the failing resource to be skipped, to return the stack to a stable UPDATE_ROLLBACK_COMPLETE state.

Attach an identity-based permission policy to the CodeBuild service role that grants sts:AssumeRole on the CrossAccountDeployRole, without modifying the destination role's trust policy.

Perform a stack update directly on the CloudFormation stack using a modified template that excludes the failing resource to override the UPDATE_ROLLBACK_FAILED state.

Update the permissions policy of the CrossAccountDeployRole to allow the sts:AssumeRole action on the CodeBuild service role ARN.

Show answer & explanation

Answer: Update the trust policy of the CrossAccountDeployRole in account 111122223333 to allow the CodeBuild service role in the source account to perform the sts:AssumeRole action.; Run the continue-update-rollback command on the CloudFormation stack, optionally specifying the failing resource to be skipped, to return the stack to a stable UPDATE_ROLLBACK_COMPLETE state.

Answer

To resolve the failures, the developer must update the trust policy of the CrossAccountDeployRole to trust the CodeBuild service role, and run the continue-update-rollback command on the CloudFormation stack to bring it back to a stable UPDATE_ROLLBACK_COMPLETE state.

The correct options are to update the trust policy of the CrossAccountDeployRole to trust the CodeBuild service role, and to run the continue-update-rollback command to return the locked CloudFormation stack to the stable UPDATE_ROLLBACK_COMPLETE state. Updating the trust policy is required because cross-account access relies on the trusting resource granting permission to the external identity. Running the continue-update-rollback command is the only valid way to transition a stack out of the UPDATE_ROLLBACK_FAILED state so it can accept updates again.

Step-by-Step Solution

Diagnose the cross-account AccessDenied error during role assumption.

Identify that the CodeBuild service role is attempting to assume CrossAccountDeployRole but lacks authorization.

For cross-account role assumption, the target role must have a trust policy (trust relationship) that explicitly trusts the principal of the calling role.

Update the trust policy of the target role (CrossAccountDeployRole).

The target role now allows sts:AssumeRole calls from the CodeBuild service role principal.

This establishes trust between the two AWS accounts, allowing CodeBuild to successfully assume the role to perform cross-account actions.

Diagnose the CloudFormation deployment block in the UPDATE_ROLLBACK_FAILED state.

Recognize that the stack is locked in a failed rollback state and cannot accept update commands.

When a resource fails to clean up during a rollback, CloudFormation stops the rollback and sets the stack state to UPDATE_ROLLBACK_FAILED. The stack remains locked until the rollback is addressed.

Execute the continue-update-rollback action on the CloudFormation stack.

The rollback resumes, optionally skipping the problematic resource, and finishes with a status of UPDATE_ROLLBACK_COMPLETE.

This operation unlocks the stack and returns it to a stable state, allowing the pipeline to deploy subsequent stack updates successfully.

Key Concept

Troubleshooting cross-account IAM role delegation and resolving locked CloudFormation rollback states.

Question 128Question →

A developer has a serverless application where an Amazon API Gateway REST API integrates with an AWS Lambda function. The Lambda function processes incoming HTTP requests, sends messages to an Amazon SQS queue, and writes records to an Amazon DynamoDB table. Active tracing is enabled on both the API Gateway stage and the Lambda function. However, in the AWS X-Ray service map, downstream calls to SQS and DynamoDB are missing, and some messages in the SQS queue are being processed multiple times by downstream consumers. Which of the following actions should the developer take to ensure that downstream DynamoDB and SQS calls are properly traced in AWS X-Ray?

Instrument the AWS SDK client using the AWS X-Ray SDK in the Lambda function code to capture downstream calls.

Increase the tracing sampling rate in the API Gateway stage settings and rely on the active tracing enablement on the Lambda function to automatically trace downstream SDK calls.

Configure the SQS queue's visibility timeout to be shorter than the Lambda function's timeout to ensure that trace context propagation is completed before the message is deleted.

Hardcode the IAM User access key and secret key in the AWS SDK client configuration within the Lambda function code to authorize X-Ray trace context propagation.

Show answer & explanation

Answer: Instrument the AWS SDK client using the AWS X-Ray SDK in the Lambda function code to capture downstream calls.

Answer

Instrument the AWS SDK client using the AWS X-Ray SDK in the Lambda function code to capture downstream calls.

The correct answer is to instrument the AWS SDK client using the AWS X-Ray SDK in the Lambda function code. Active tracing on AWS Lambda only traces the incoming invocation and function overhead. To trace downstream calls made to services like SQS or DynamoDB, the developer must explicitly wrap or patch the AWS SDK client using the AWS X-Ray SDK.

Step-by-Step Solution

Identify why downstream calls are missing from the AWS X-Ray service map.

Realize that active tracing on AWS Lambda only covers the Lambda service and function execution, but does not auto-instrument SDK clients inside the code.

To capture calls to downstream services like DynamoDB and SQS, the AWS SDK client inside the application code must be wrapped or patched by the AWS X-Ray SDK.

Apply X-Ray SDK client instrumentation in the Lambda function.

The AWS SDK client is instrumented (e.g., using AWSXRay.captureAWS in Node.js or patch_all() in Python).

This configuration allows the X-Ray SDK to intercept and trace outbound requests made by the AWS SDK client.

Ensure that the Lambda function execution role has appropriate permissions.

The Lambda execution role has the AWSXrayWriteOnlyAccess policy attached.

The function must have IAM permissions to write trace data to AWS X-Ray.

Key Concept

AWS X-Ray SDK instrumentation of AWS SDK clients is required to trace downstream calls from AWS Lambda.

Estimated Time:1m 30s

Question 129Question →

A developer is configuring an AWS CodePipeline where an AWS CodeBuild stage runs automated unit tests. The CodeBuild project has been assigned a custom IAM service role with permission policies that grant access to target Amazon S3 buckets and Amazon CloudWatch Logs. However, when the pipeline runs, the CodeBuild execution fails during the start phase with the error message: `CodeBuild is not authorized to perform: sts:AssumeRole on the specified service role`. What is the correct action to troubleshoot and resolve this failure?

Update the trust policy of the custom IAM service role to allow the codebuild.amazonaws.com service principal to perform the sts:AssumeRole action.

Add the sts:AssumeRole action to the identity-based permission policy attached to the custom IAM service role.

Create a buildspec.yml file in the root of the source code repository and specify the sts:AssumeRole command under the pre_build phase.

Modify the AWS CodePipeline service role permissions to allow the pipeline to assume the container's Amazon ECS task execution role.

Show answer & explanation

Answer: Update the trust policy of the custom IAM service role to allow the codebuild.amazonaws.com service principal to perform the sts:AssumeRole action.

Answer

Update the trust policy of the custom IAM service role to allow the codebuild.amazonaws.com service principal to perform the sts:AssumeRole action.

The correct action is to update the trust policy of the custom IAM service role to allow the codebuild.amazonaws.com service principal to perform the sts:AssumeRole action. For AWS CodeBuild to execute a build, the CodeBuild service itself must be authorized to assume the role assigned to the project. This authorization is granted through the role's trust policy, not its permission policy.

Step-by-Step Solution

Identify the cause of the failure based on the error message.

The error `CodeBuild is not authorized to perform: sts:AssumeRole` indicates that AWS CodeBuild cannot assume the IAM role assigned to the project.

When CodeBuild starts a build, it must assume the specified service role using the Security Token Service (STS) to gain permissions to access other AWS services.

Locate and edit the IAM service role in the AWS Management Console or via CLI.

Access the Trust Relationships tab of the custom IAM role.

The trust policy defines which entities (services, users, or accounts) are allowed to assume the role.

Configure the trust policy to allow the CodeBuild service principal.

Add 'codebuild.amazonaws.com' as a trusted service principal with the 'sts:AssumeRole' action.

This establishes the necessary trust relationship, resolving the authorization error and allowing CodeBuild to run the project successfully.

Key Concept

AWS CodeBuild Service Role Trust Relationships

Question 130Question →

An IoT application managed by AeroFleet Logistics tracks real-time location data for thousands of delivery vehicles. The application writes updates to an Amazon DynamoDB table. The table's partition key is `vehicle_status` (which only contains values such as `ACTIVE`, `INACTIVE`, or `MAINTENANCE`), and the sort key is a timestamp. During peak hours, the application frequently receives `ProvisionedThroughputExceededException` errors during writes. A review of CloudWatch metrics shows that the overall table-level consumed Write Capacity Units (WCUs) are far below the provisioned WCU limit, but writes are heavily skewed to a single partition key value. Which of the following combinations of actions should the developer take to resolve these throttling issues and make the application more resilient to transient write failures? (Select TWO options.)

Select all that apply

Redesign the partition key schema by appending a calculated or random suffix (e.g.,

1

N

) to the `vehicle_status` partition key to distribute write operations across multiple physical partitions.

Configure the application SDK client to implement exponential backoff with jitter for write requests to handle throttling during write spikes gracefully.

Increase the visibility timeout of the upstream Amazon SQS queue that feeds the location updates to avoid duplicate writes during database throttling events.

Modify the application to perform parallel Scan operations with Segment parameters to quickly identify and remove inactive vehicle status records.

Hardcode the IAM access key and secret key directly into the application SDK initialization code to speed up authentication and reduce connection latency.

Show answer & explanation

Answer: Redesign the partition key schema by appending a calculated or random suffix (e.g., $1$ to $N$ ) to the `vehicle_status` partition key to distribute write operations across multiple physical partitions.; Configure the application SDK client to implement exponential backoff with jitter for write requests to handle throttling during write spikes gracefully.

Answer

Redesign the partition key schema by appending a calculated or random suffix to the partition key, and configure the SDK client to implement exponential backoff with jitter.

The correct response involves redesigning the partition key schema by appending a calculated suffix (write-sharding) and modifying the client SDK retry configurations. Adding a suffix distributes writes across multiple partition keys, mitigating hot partition problems. Implementing exponential backoff with jitter ensures that retry attempts do not overwhelm the partition during traffic surges.

Step-by-Step Solution

Diagnose the root cause using CloudWatch metrics.

Confirmed that partition key cardinality is too low, causing skewed traffic to a single partition, exceeding the limit of

1000

WCUs per partition.

To verify that the ProvisionedThroughputExceededException is due to hot partitions rather than overall table WCU exhaustion.

Introduce write sharding using synthetic suffixes.

Append a randomized or calculated suffix (e.g.,

1

N

) to the `vehicle_status` partition key, shifting the key structure from single values to distributed partitions.

To distribute write throughput evenly across multiple physical partitions and eliminate hot partition bottlenecks.

Implement exponential backoff and jitter in the application SDK.

Client retries are spaced out progressively and randomized rather than hitting the database simultaneously.

To gracefully manage temporary spikes in database load and avoid retry storms that worsen throttling.

Key Concept

Write sharding via synthetic key suffixes to distribute traffic across physical partitions, combined with client-side retry policies (exponential backoff with jitter) to build resilient database integrations.

Estimated Time:3m 0s

Question 131Question →

A developer is troubleshooting an AWS Lambda function written in Node.js that processes contact form submissions. The function is configured to process one message at a time. The developer notices that when multiple forms are submitted in quick succession, the logs contain duplicate and combined messages from different users. The developer finds that a global array used to accumulate message parts is declared outside the Lambda handler function. Which of the following explains the cause of this issue and the correct resolution?

The Lambda execution context is reused across sequential invocations, causing the global array to retain data from previous executions. The developer should declare and initialize the array inside the handler function.

The Lambda function is configured to run inside a public subnet in a VPC without a NAT Gateway, causing routing loops that duplicate the events. The developer should configure the function to run inside private subnets with a NAT Gateway.

The AWS SDK client is reusing outdated session credentials stored in the global execution context. The developer should disable connection reuse by setting the AWS_SDK_LOAD_CONFIG environment variable to false.

AWS X-Ray active tracing is enabled, but the function fails to propagate the tracing context to the global scope, causing downstream requests to overlap. The developer should import and configure the X-Ray SDK at the beginning of the code.

Show answer & explanation

Answer: The Lambda execution context is reused across sequential invocations, causing the global array to retain data from previous executions. The developer should declare and initialize the array inside the handler function.

Answer

The execution context is reused for sequential invocations, meaning any global variables defined outside the handler will persist. To prevent data from leaking or duplicating between runs, variables containing request-specific data must be defined inside the handler.

Step-by-Step Solution

Analyze the scope of the stateful variables in the Lambda function.

The array is declared outside the handler function (globally).

Variables declared in the global scope are initialized once during the cold start and persist during execution context reuse.

Identify the behavior under sequential invocations.

Consecutive invocations reuse the same container, meaning subsequent executions append data to the existing global array rather than starting with an empty array.

AWS Lambda reuses container environments to optimize execution time (warm starts), preserving the state of the global variables.

Determine the resolution to isolate data per invocation.

Move the declaration and initialization of the array inside the handler function.

This guarantees that the array is recreated as an empty array at the beginning of every separate execution, preventing data leaks.

Key Concept

Lambda execution context reuse and global state retention

Question 132Question →

A developer is implementing a serverless data-processing pipeline. An AWS Lambda function is configured to run inside a VPC, associated with two private subnets. The function reads telemetry metadata from an Amazon ElastiCache for Redis cluster in the same VPC, uses AWS Key Management Service (AWS KMS) to decrypt payload fields, and writes the results to an Amazon DynamoDB table. During testing, the Lambda function consistently times out after its configured limit of 15 seconds. The function's IAM execution role contains permissions for KMS decryption and DynamoDB writing, and the security group associated with the Lambda function allows all outbound traffic. What is the root cause of these execution timeouts?

The private subnets do not have a route to a NAT Gateway, and no VPC Endpoints are configured for AWS KMS and DynamoDB, preventing the function from reaching their public endpoints.

The Lambda function is not configured to run in public subnets of the VPC with an assigned public IP address, which is required to establish direct outbound connections to public AWS endpoints.

The Lambda execution context is reusing the KMS client across warm starts, causing the client connection pool to exhaust socket descriptors and block subsequent requests.

The AWS SDK clients for KMS and DynamoDB within the Lambda function are not explicitly initialized with static AWS access keys, which is required for authentication when executing inside a VPC.

Show answer & explanation

Answer: The private subnets do not have a route to a NAT Gateway, and no VPC Endpoints are configured for AWS KMS and DynamoDB, preventing the function from reaching their public endpoints.

Answer

The private subnets do not have a route to a NAT Gateway, and no VPC Endpoints are configured for AWS KMS and DynamoDB, preventing the function from reaching their public endpoints.

The correct answer is the option indicating that the private subnets lack a route to a NAT Gateway or the necessary VPC Endpoints. When a Lambda function is configured to run inside a VPC, it loses its default internet access. To connect to public AWS services such as AWS KMS and DynamoDB, the function's subnets must route traffic through a NAT Gateway or utilize VPC Endpoints (Interface Endpoint for KMS, and Gateway Endpoint for DynamoDB) to keep the traffic within the AWS network. Without this routing, calls to KMS and DynamoDB will hang and cause the function to time out.

Step-by-Step Solution

Analyze the network placement of the Lambda function and the target endpoints.

The Lambda function is placed inside private VPC subnets to communicate with ElastiCache for Redis (a VPC resource). It also needs to connect to AWS KMS and DynamoDB, which are public AWS services.

Understanding the destination of outbound network calls helps identify if they require public internet access or VPC endpoint routing.

Evaluate the default network behavior of VPC-enabled Lambda functions.

Once a Lambda function is attached to a VPC, all its outbound internet access is disabled by default.

This explains why the function can reach ElastiCache (local to the VPC) but cannot reach public AWS endpoints without additional configuration.

Determine the necessary routing configuration to restore access to public endpoints.

To access public endpoints, the VPC must have a NAT Gateway in a public subnet with a route in the private subnet's route table, or VPC Endpoints (Gateway for DynamoDB, Interface for KMS) must be provisioned inside the VPC.

Without a NAT Gateway or VPC Endpoints, the TCP connection attempts to AWS KMS and DynamoDB will hang indefinitely, leading to execution timeouts.

Key Concept

VPC Networking for AWS Lambda and Access to Public AWS Services

Question 133Question →

A developer is attempting to deploy an application update using AWS CloudFormation. The initial creation of the stack failed due to a misconfigured resource, leaving the stack in the ROLLBACK_COMPLETE state. When the developer attempts to run the `aws cloudformation update-stack` command with a corrected template, the command fails with a ValidationError. Which of the following actions must the developer take to successfully deploy the corrected template?

Create and execute a CloudFormation change set against the existing stack to apply the template changes.

Modify the trust policy of the CloudFormation execution role to explicitly allow the UpdateStack action on the resource.

Delete the existing CloudFormation stack and then create a new stack using the corrected template.

Move the buildspec.yml file to a subdirectory in the source repository to trigger a pipeline execution that bypasses the stack rollback.

Show answer & explanation

Answer: Delete the existing CloudFormation stack and then create a new stack using the corrected template.

Answer

Delete the existing CloudFormation stack and then create a new stack using the corrected template.

The correct answer is to delete the existing stack and create a new one. When a stack fails its initial creation, it rolls back to the ROLLBACK_COMPLETE state. Stacks in this state cannot be updated or modified via change sets. The only way to redeploy under the same stack name is to delete the failed stack and run a new creation process.

Step-by-Step Solution

Identify the current state of the failed CloudFormation stack.

The stack is found to be in the ROLLBACK_COMPLETE state following a failed initial creation attempt.

Understanding the exact state helps determine whether the stack can accept updates or must be deleted.

Delete the existing failed stack using the AWS Management Console or the AWS CLI.

The stack in the ROLLBACK_COMPLETE state is completely removed from the AWS account.

AWS CloudFormation does not allow updates to stacks that failed their initial creation and rolled back.

Run the create-stack command using the corrected CloudFormation template.

A new stack is successfully created with the resource configurations applied.

Creating a new stack is the only way to deploy the resource once the blocked stack is removed.

Key Concept

Handling CloudFormation ROLLBACK_COMPLETE state

Estimated Time:1m 30s

Question 134Question →

A developer attempts to create a new AWS CloudFormation stack. The stack creation fails due to a resource configuration error, and the stack status transitions to ROLLBACK_COMPLETE. After correcting the error in the template, the developer attempts to update the stack with the corrected template, but the operation fails. Which of the following actions must the developer take to successfully deploy the resources?

Delete the failed stack and create a new stack using the corrected template.

Run drift detection on the stack and resolve any out-of-band changes before retrying the update.

Modify the IAM trust policy of the CloudFormation role to allow the stack to transition out of the rollback state.

Add a buildspec.yml file to the root directory containing instructions for the rollback phase.

Show answer & explanation

Answer: Delete the failed stack and create a new stack using the corrected template.

Answer

Delete the failed stack and create a new stack using the corrected template.

When the initial creation of a CloudFormation stack fails, the stack rolls back and enters the ROLLBACK_COMPLETE state. A stack in this state cannot be updated or recovered. The only way to deploy the resources with a corrected template is to delete the failed stack and create a new one.

Step-by-Step Solution

Analyze the CloudFormation stack state.

The stack is in the ROLLBACK_COMPLETE state after failing its initial creation.

Understanding the current state of the stack determines whether an update is possible.

Determine if a stack update can be performed in this state.

CloudFormation does not allow updates to stacks that failed initial creation and rolled back.

Stacks in the ROLLBACK_COMPLETE status must be deleted before the resources can be created again.

Identify the correct resolution step.

Delete the failed stack and create a new one using the corrected template.

This removes the failed stack and allows a clean creation attempt with the fixed template.

Key Concept

CloudFormation Rollback States and Stack Lifecycle

Estimated Time:45s

Question 135Question →

A developer has deployed a Node.js Express application on AWS Elastic Beanstalk. The application has the AWS X-Ray daemon enabled via a configuration file in the .ebextensions directory. The application handles incoming client requests and uses the AWS SDK for JavaScript (v3) to read and write items in an Amazon DynamoDB table. While the X-Ray service map shows the incoming HTTP requests to the Express application, the downstream calls to DynamoDB are completely missing from the traces. Which action should the developer take to ensure the DynamoDB calls are traced and associated with the incoming requests?

Wrap the DynamoDB client instance using the captureAWSv3Client function from the AWS X-Ray SDK for Node.js.

Initialize the DynamoDB client with hardcoded AWS access keys in the application code to allow the SDK to authenticate with the X-Ray daemon.

Increase the Amazon SQS visibility timeout configuration to ensure messages are not reprocessed before the DynamoDB client completes.

Set up API Gateway to use a Lambda proxy integration and return the tracing headers in the JSON response payload.

Show answer & explanation

Answer: Wrap the DynamoDB client instance using the captureAWSv3Client function from the AWS X-Ray SDK for Node.js.

Answer

Wrap the DynamoDB client instance using the captureAWSv3Client function from the AWS X-Ray SDK for Node.js.

The correct answer is correct because AWS SDK v3 for JavaScript requires explicit wrapping of service client instances using the captureAWSv3Client function from the AWS X-Ray SDK. Once wrapped, the client automatically records metadata and subsegments for every downstream call, associating them with the active trace context in the environment.

Step-by-Step Solution

Identify the missing tracing data source.

The incoming HTTP requests to Elastic Beanstalk are traced, but downstream calls to DynamoDB are missing.

This indicates that context propagation from the incoming HTTP request wrapper to the downstream client is not occurring because the SDK client itself is not instrumented.

Apply the appropriate instrumentation method for AWS SDK for JavaScript (v3).

Import the captureAWSv3Client function from 'aws-xray-sdk-core' and wrap the DynamoDB client during initialization.

In SDK v3, unlike SDK v2 which supported patching the entire AWS module, individual client instances must be wrapped explicitly using captureAWSv3Client.

Key Concept

AWS X-Ray SDK Client Instrumentation for JavaScript (v3)

Question 136Question →

A developer is troubleshooting a PDF generation Lambda function. The function is configured to run inside private subnets of a VPC. It must retrieve document templates from an external public HTTPS endpoint and then save transaction logs to an Amazon RDS PostgreSQL database instance located in another private subnet of the same VPC. During testing, the developer observes two symptoms: the function consistently times out when attempting to reach the external HTTPS endpoint, and the RDS database runs out of available connection slots during concurrent test runs. Which two actions should the developer take to resolve these issues?

Select all that apply

Move the database connection client initialization code outside of the Lambda handler function.

Configure a NAT Gateway in a public subnet of the VPC and route internet-bound traffic from the private subnets through this gateway.

Associate the Lambda function with the public subnets of the VPC and configure it to request public IP addresses.

Create a route in the private subnet's route table pointing directly to the VPC's Internet Gateway for destination 0.0.0.0/0.

Increase the Lambda function's timeout and memory configuration to force automatic garbage collection of the database connection pools on each invocation.

Show answer & explanation

Answer: Move the database connection client initialization code outside of the Lambda handler function.; Configure a NAT Gateway in a public subnet of the VPC and route internet-bound traffic from the private subnets through this gateway.

Answer

Initialize the database connection client outside of the Lambda handler function, and configure a NAT Gateway in a public subnet to route internet-bound traffic from the private subnets.

To resolve the RDS connection exhaustion, the database connection client must be initialized outside of the handler function. This enables the Lambda service to leverage execution context reuse, retaining the database connection pool across warm invocations rather than recreating it on every request. To resolve the internet connectivity issue, the Lambda function residing in the private subnet needs outbound internet access. Since Lambda functions do not receive public IP addresses, they cannot use an Internet Gateway directly; instead, traffic destined for the internet must be routed through a NAT Gateway situated in a public subnet.

Step-by-Step Solution

Diagnose the database connection exhaustion issue.

The database connection client is likely being initialized inside the Lambda handler function, causing a new database connection to open on every single invocation under load.

Identifying that new connections are opened per request guides the developer to optimize code structure using execution context reuse.

Diagnose the outbound internet connectivity timeout.

The Lambda function is placed in a private subnet and has no pathway to the public internet because it cannot communicate directly with an Internet Gateway without a public IP.

Understanding VPC routing rules explains why the connection to the external HTTPS endpoint is timing out.

Apply the solutions to both network and execution context issues.

Initialize the database client globally (outside the handler) to reuse connections, and route private subnet traffic through a NAT Gateway in a public subnet to enable internet access.

These steps address both the resource depletion and the networking blockages identified.

Key Concept

Debugging Lambda execution context reuse and VPC networking configurations.

Question 137Question →

An e-commerce platform uses an Amazon DynamoDB table to store product inventory details. During flash sales, the application experiences a massive surge in read requests, resulting in intermittent ProvisionedThroughputExceededException errors. To reduce read latency to sub-milliseconds, the developer integrates an Amazon DynamoDB Accelerator (DAX) cluster. However, the developer notices that several critical inventory check operations, which must retrieve the most up-to-date quantities using strongly consistent reads, continue to suffer from high latency and still trigger throttling on the underlying DynamoDB table. Additionally, some reporting scripts perform full scans of the inventory and are also experiencing performance issues. Which of the following is the most appropriate explanation and resolution for this behavior?

The application's IAM execution role lacks the dax:GetItem permission, causing the DAX client to fail open and default to standard DynamoDB calls. To resolve this, update the IAM policy and adjust the Lambda function's timeout configuration to prevent execution contexts from being prematurely terminated during spikes.

The DAX cluster is experiencing throttling because the inventory check queries are hitting a hot partition key that exceeds the DAX node capacity. To resolve this, scale up the provisioned write capacity of the underlying DynamoDB table and keep using Scan operations to distribute the read load evenly across all partitions.

Strongly consistent reads are not cached by DAX and are passed directly through to the DynamoDB table, consuming provisioned read throughput. To resolve the throttling and latency, modify the inventory checks to use eventually consistent reads so they are served from the DAX item cache, and rewrite the reporting scripts to retrieve items using Query operations instead of Scan operations.

Strongly consistent reads bypass the DAX cache only if they are executed within a DynamoDB transaction. To resolve this, wrap the inventory checks in a TransactGetItems API call and configure the reporting scripts to execute Scan operations with a smaller Limit parameter to prevent ProvisionedThroughputExceededException.

Show answer & explanation

Answer: Strongly consistent reads are not cached by DAX and are passed directly through to the DynamoDB table, consuming provisioned read throughput. To resolve the throttling and latency, modify the inventory checks to use eventually consistent reads so they are served from the DAX item cache, and rewrite the reporting scripts to retrieve items using Query operations instead of Scan operations.

Answer

Strongly consistent reads are not cached by DAX and are passed directly through to the underlying DynamoDB table, which consumes read capacity units (RCUs) and can lead to throttling. Modifying the read operations to use eventual consistency allows DAX to serve these requests from the item cache, significantly reducing latency and protecting the DynamoDB table from throttling. Additionally, rewriting full table scans to use Query operations targets specific partition keys, reducing read capacity usage.

Step-by-Step Solution

Analyze how DAX handles strongly consistent reads vs eventually consistent reads.

DAX does not cache strongly consistent reads; it passes them directly to DynamoDB, consuming Provisioned Throughput.

To determine why the inventory checks bypass the DAX cluster and hit DynamoDB.

Identify the caching solution for read operations.

Change the inventory check reads from strongly consistent to eventually consistent.

Eventually consistent reads are cached in the DAX item cache, lowering latency and removing load from DynamoDB.

Evaluate the reporting scripts' data retrieval strategy.

Replace Scan operations with targeted Query operations.

Scan operations retrieve all items in a table, whereas Query operations search using partition key attributes, significantly reducing RCU consumption.

Key Concept

DAX Caching Behavior and Read Consistency

Question 138Question →

A developer is attempting to deploy a new application stack using AWS CloudFormation for the first time. The stack creation fails during the creation of an Amazon S3 bucket due to a naming conflict, and the stack status changes to ROLLBACK_COMPLETE. Which two actions should the developer take to successfully deploy the stack with the corrected S3 bucket name?

Select all that apply

Delete the CloudFormation stack that is in the ROLLBACK_COMPLETE state.

Update the bucket name in the CloudFormation template to a unique value and create a new stack.

Perform a stack update directly on the existing ROLLBACK_COMPLETE stack using the corrected template.

Modify the trust policy of the CloudFormation service role to allow the s3:CreateBucket action.

Run drift detection on the ROLLBACK_COMPLETE stack to import the conflicting bucket name.

Show answer & explanation

Answer: Delete the CloudFormation stack that is in the ROLLBACK_COMPLETE state.; Update the bucket name in the CloudFormation template to a unique value and create a new stack.

Answer

To resolve the issue, delete the failed stack in the ROLLBACK_COMPLETE state, update the bucket name in the CloudFormation template to a globally unique value, and create a new stack.

When a CloudFormation stack fails initial creation and enters the ROLLBACK_COMPLETE status, it cannot be updated. The developer must delete the failed stack. To resolve the root cause, which is a naming conflict for the S3 bucket (S3 requires globally unique bucket names across all AWS accounts), the developer must modify the bucket name in the template to be unique and create a new stack.

Step-by-Step Solution

Check the CloudFormation console stack events to confirm the resource failure reason.

The events show that the S3 bucket creation failed because the bucket name is already occupied globally.

This identifies the root cause of the stack creation failure.

Delete the failed stack which is in the ROLLBACK_COMPLETE status.

The stack resources are cleaned up and the stack is removed.

AWS CloudFormation does not allow stack updates on stacks that failed during their initial creation.

Change the bucket name in the CloudFormation template to a unique string and create a new stack.

The template is successfully validated and the new stack is created without errors.

S3 buckets require globally unique names, and a new stack must be initiated since the previous one was deleted.

Key Concept

CloudFormation initial stack creation failure recovery and S3 naming requirements.

Estimated Time:1m 0s

Question 139Question →

A developer has deployed a Python web application on an Amazon EC2 instance. The developer wants to use AWS X-Ray to trace incoming HTTP requests and downstream AWS service calls. Which two actions must the developer take to instrument the application and successfully send trace data to X-Ray? (Select TWO.)

Select all that apply

Install and run the AWS X-Ray daemon on the Amazon EC2 instance to collect and upload trace data.

Use the AWS X-Ray SDK to patch supported libraries in the Python code to record outgoing HTTP and AWS SDK calls.

Initialize the AWS SDK clients by hardcoding an IAM user's access keys that have permissions to write trace segments.

Rely solely on enabling active tracing in the EC2 console, which automatically instruments the application code without SDK configuration.

Configure a custom execution timeout on the Amazon EC2 instance configuration to allow the Lambda environment to flush trace segments.

Show answer & explanation

Answer: Install and run the AWS X-Ray daemon on the Amazon EC2 instance to collect and upload trace data.; Use the AWS X-Ray SDK to patch supported libraries in the Python code to record outgoing HTTP and AWS SDK calls.

Answer

Install and run the AWS X-Ray daemon on the Amazon EC2 instance to collect and upload trace data, and use the AWS X-Ray SDK to patch supported libraries in the Python code to record outgoing HTTP and AWS SDK calls.

For an application hosted on an Amazon EC2 instance to use AWS X-Ray, the host must run the X-Ray daemon to collect and forward trace segment documents to the AWS X-Ray API. Additionally, the application code must use the AWS X-Ray SDK to patch outgoing libraries (such as boto3) to capture downstream context and API calls.

Step-by-Step Solution

Deploy and execute the AWS X-Ray daemon on the EC2 instance.

The daemon starts running and listens on UDP port 2000 to collect trace data segments.

EC2 is an unmanaged hosting environment, so the X-Ray daemon must be manually run to aggregate and upload trace data.

Use the AWS X-Ray SDK in the Python code to patch libraries like boto3.

The SDK automatically intercepts outgoing calls and generates trace segments.

Explicit patching or instrumentation is required in Python code to automatically propagate tracking IDs and capture metadata for downstream dependencies.

Key Concept

To enable X-Ray tracing on Amazon EC2, the developer must manually install and run the X-Ray daemon and instrument the application code using the X-Ray SDK.

Question 140Question →

A developer is troubleshooting an AWS Lambda function that performs real-time currency conversion for a financial auditing application. The function is configured to run inside a VPC and is associated with two private subnets. It must read transaction data from an Amazon Aurora MySQL database cluster in the same VPC and fetch the latest exchange rates from a public API endpoint over the internet. While the database queries succeed, all HTTP requests to the public exchange rate API fail with connection timeout errors. Which of the following actions should the developer take to resolve this connectivity issue?

Deploy a NAT Gateway in a public subnet of the VPC, and add a route in the private subnets' route table directing outbound internet traffic (0.0.0.0/0) to the NAT Gateway.

Associate the Lambda function with public subnets of the VPC, enabling direct internet access through the VPC Internet Gateway.

Create an Egress-Only Internet Gateway in the VPC and add a route in the private subnets' route table directing outbound IPv4 traffic to it.

Increase the Lambda function's execution timeout limit to allow the execution context to persist stale database connections and avoid outbound socket timeouts.

Show answer & explanation

Answer: Deploy a NAT Gateway in a public subnet of the VPC, and add a route in the private subnets' route table directing outbound internet traffic (0.0.0.0/0) to the NAT Gateway.

Answer

Deploy a NAT Gateway in a public subnet of the VPC, and add a route in the private subnets' route table directing outbound internet traffic (0.0.0.0/0) to the NAT Gateway.

The correct answer is to deploy a NAT Gateway in a public subnet and add a route in the private subnets' route table. Since Lambda functions inside a VPC only receive private IP addresses from the subnets they are associated with, they cannot communicate with the internet directly. By routing outbound traffic through a NAT Gateway in a public subnet, the Lambda function can securely access the public API.

Step-by-Step Solution

Analyze the network configuration of the Lambda function.

The Lambda function is associated with private subnets in a VPC. It can access internal resources like the database but lacks internet connectivity.

Since Lambda functions do not receive public IP addresses, they cannot communicate directly with the internet even if associated with a public subnet.

Identify the resource needed to route private subnet traffic to the internet.

A NAT Gateway must be deployed in a public subnet of the VPC.

A NAT Gateway translates private IP addresses to a public IP to enable outbound internet connectivity for private resources.

Configure routing for the private subnets.

Add a route for 0.0.0.0/0 pointing to the NAT Gateway in the private subnets' route table.

This directs all non-VPC internet-bound traffic from the private subnets through the NAT Gateway.

Key Concept

VPC Networking for AWS Lambda Functions

Estimated Time:2m 0s

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