Troubleshooting and Optimization

271 questions

All types271 Multiple choice138 Multiple select133

A logistics tracking application uses Amazon DynamoDB to store delivery status updates. During peak hours, the application frequently experiences read throttling ("ProvisionedThroughputExceededException") when querying the status of specific high-priority shipments, which are read repeatedly by multiple warehouse terminals using eventually consistent reads. The development team needs to implement a caching solution to reduce the load on the DynamoDB table and minimize tail latency while requiring minimal modifications to the existing application code. Which solution should the development team implement to meet these requirements?

Deploy an Amazon DynamoDB Accelerator (DAX) cluster and update the application code to use the DAX SDK client instead of the standard DynamoDB client.

Increase the table's provisioned Read Capacity Units (RCUs) and configure DynamoDB Auto Scaling to dynamically scale read capacity based on the spike in traffic.

Deploy an Amazon ElastiCache for Memcached cluster, and modify the application to perform a DynamoDB Scan operation with a FilterExpression to find the item on a cache miss, then populate the cache.

Create an Amazon ElastiCache for Redis cluster, and update the backend Lambda function to establish a new Redis client connection on every single invocation to retrieve the item status.

Show answer & explanation

Answer: Deploy an Amazon DynamoDB Accelerator (DAX) cluster and update the application code to use the DAX SDK client instead of the standard DynamoDB client.

Answer

Deploy an Amazon DynamoDB Accelerator (DAX) cluster and update the application code to use the DAX SDK client instead of the standard DynamoDB client.

Deploying an Amazon DynamoDB Accelerator (DAX) cluster and updating the application code to use the DAX SDK client is the optimal solution. DAX provides a fully managed, API-compatible, in-memory cache for DynamoDB. Because the reads are eventually consistent, DAX caches and serves them directly from the item cache, eliminating hot partition read throttling on the underlying DynamoDB table with minimal changes to application logic.

Step-by-Step Solution

Analyze the root cause of the DynamoDB throttling ("ProvisionedThroughputExceededException").

The throttling is caused by repeated reads of specific high-priority shipments (hot partition keys) using eventually consistent reads.

Identifying whether the bottleneck is due to overall capacity constraints or hot partitions determines the correct mitigation strategy.

Evaluate the consistency requirement and caching solutions.

Since the read requests are eventually consistent, they are eligible for item caching using either Amazon ElastiCache or Amazon DynamoDB Accelerator (DAX).

Strongly consistent reads bypass the DAX item cache, but eventually consistent reads are served directly from the cache, reducing read load on DynamoDB.

Select the caching solution that minimizes code changes and avoids anti-patterns.

Deploying DAX requires only replacing the standard DynamoDB client with the DAX client (API-compatible), whereas ElastiCache requires writing complex custom logic for cache-aside patterns and can lead to inefficient Scan patterns if designed poorly.

DAX is specifically built for DynamoDB caching, offering transparent API integration and automatic cache management without rewriting query logic.

Key Concept

Using DynamoDB Accelerator (DAX) to resolve read throttling on hot keys with minimal code changes.

Question 182Question →

A developer is testing a local Java application that uses the AWS SDK for Java v2 to retrieve messages from an Amazon SQS queue. The application is configured to use a profile named dev-profile. When running the application locally, it fails with the following error:

software.amazon.awssdk.core.exception.SdkClientException: Unable to load credentials from any of the providers in the chain

The developer verifies that the local AWS credentials and configuration files exist. Which TWO conditions could explain this credential loading failure? (Select TWO).

Select all that apply

The credentials file (~/.aws/credentials) defines the profile as [profile dev-profile] instead of [dev-profile].

The environment variable AWS_PROFILE is not set on the local machine, and the ~/.aws/credentials file does not contain a [default] profile.

The developer configured the credentials in the Systems Manager Parameter Store under the name dev-profile, which the SDK cannot retrieve locally.

The IAM role associated with the SQS queue has a trust policy that does not include the developer's local workstation IP address under the principal field.

The developer resolved the issue by hardcoding the access key and secret key strings directly as arguments in the SqsClient.builder() constructor.

Show answer & explanation

Answer: The credentials file (~/.aws/credentials) defines the profile as [profile dev-profile] instead of [dev-profile].; The environment variable AWS_PROFILE is not set on the local machine, and the ~/.aws/credentials file does not contain a [default] profile.

Answer

The credentials file (~/.aws/credentials) must define the profile without the 'profile' prefix, and the environment variable AWS_PROFILE must be set to the profile name if a default profile is not defined.

The correct options identify valid reasons for the SDK's inability to load credentials. First, in the shared credentials file (~/.aws/credentials), profiles must be declared as [profile_name] (e.g., [dev-profile]) without the 'profile' prefix, which is only used in the configuration file (~/.aws/config). If the prefix is included in the credentials file, the SDK will fail to resolve the profile. Second, if the AWS_PROFILE environment variable is not defined, the default credential provider chain looks for the [default] profile. If no default profile is configured, the chain fails and throws an SdkClientException.

Step-by-Step Solution

Examine the local system's environment variables to check if AWS_PROFILE is set.

If AWS_PROFILE is unset, the SDK default provider chain defaults to searching for credentials under the '[default]' profile header.

To understand which profile the Java SDK is attempting to load.

Inspect the content and structure of the ~/.aws/credentials file.

Identify if the target profile is defined correctly as '[dev-profile]' or incorrectly as '[profile dev-profile]'.

The credentials file does not support the 'profile' keyword prefix in brackets, which is a common syntax error that prevents the SDK from reading the credentials.

Key Concept

AWS SDK credential lookup precedence and configuration syntax rules for local development.

Question 183Question →

An e-commerce application named "FlashRetail" writes customer transaction records to an Amazon DynamoDB table. The table partition key is configured as the transaction date (format: $YYYY-MM-DD$ ). During a high-volume flash sale event, the application experiences write throttling and encounters $ProvisionedThroughputExceededException$ errors, even though the total consumed capacity is well below the table's overall provisioned write limit.

Which of the following actions should the developer take to resolve this throttling issue?

Modify the application retrieval logic to use Scan operations instead of Query operations.

Increase the overall provisioned Write Capacity Units (WCUs) of the DynamoDB table.

Redesign the partition key schema by appending a random suffix to the transaction date to distribute writes across multiple partition keys.

Increase the Amazon SQS visibility timeout for the queue processing the incoming transaction messages.

Show answer & explanation

Answer: Redesign the partition key schema by appending a random suffix to the transaction date to distribute writes across multiple partition keys.

Answer

Redesign the partition key schema by appending a random suffix to the transaction date to distribute writes across multiple partition keys.

The correct action is to redesign the partition key schema by appending a random suffix. The transaction date (

YYYY-MM-DD

) has low cardinality during a high-traffic event, causing all writes to target the same partition key. Appending a random suffix (sharding) distributes the write operations across multiple distinct partition key values (e.g.,

2026-07-14.1

2026-07-14.2

), resolving the hot partition bottleneck.

Step-by-Step Solution

Analyze the table's partition key design and write patterns during the event.

The partition key is the transaction date, which causes all write operations on a given day to target the exact same partition key value.

When all writes target a single partition key value, a hot partition is created, leading to local throttling even if the table-wide provisioned capacity is not fully consumed.

Evaluate remediation options to distribute the write load.

Adding a random suffix (e.g., a number from 1 to N) to the transaction date splits the single hot partition key into multiple distinct partition key values.

Distributing the writes across multiple partition key values ensures that traffic is spread across different physical partitions, resolving the single-partition throughput bottleneck.

Key Concept

Avoiding hot partitions in DynamoDB by distributing writes using partition key sharding (adding random suffixes).

Estimated Time:45s

Question 184Question →

A developer has deployed a Python Flask web application on Amazon EC2 instances. The application receives user requests, sends notifications to Amazon SNS, and queries an Amazon RDS PostgreSQL database. The AWS X-Ray daemon is running on the instances and has the necessary permissions. However, the X-Ray service map only shows the EC2 instances as nodes and does not display downstream nodes for Amazon SNS or the RDS database. Which two actions should the developer take to instrument the application and trace these downstream components? (Select TWO.)

Select all that apply

Call the patch_all() function from the aws_xray_sdk.core module at the start of the application to instrument boto3.

Use the database patching capabilities in the AWS X-Ray SDK to instrument the psycopg2 database connector.

Hardcode AWS credentials with the AWSXRayDaemonWriteAccess policy in the application's initialization code.

Increase the visibility timeout of the downstream Amazon SQS queue to match the database connection timeout.

Refactor the application's routing to parse incoming JSON payloads as API Gateway Lambda proxy integration events.

Show answer & explanation

Answer: Call the patch_all() function from the aws_xray_sdk.core module at the start of the application to instrument boto3.; Use the database patching capabilities in the AWS X-Ray SDK to instrument the psycopg2 database connector.

Answer

To instrument downstream calls, the developer must call the patch_all() function from the X-Ray SDK to instrument boto3 and patch the database connector (psycopg2) to trace RDS queries.

The correct choices involve using the AWS X-Ray SDK to patch the boto3 library and instrument the database connector (psycopg2). This allows the SDK to intercept and record tracing data for downstream services like Amazon SNS and Amazon RDS.

Step-by-Step Solution

Import and call patch_all() in the main Flask application entry point.

The boto3 library is patched, enabling X-Ray to record calls to Amazon SNS.

To capture metadata and segments for AWS service calls.

Patch the database connector (psycopg2) using the X-Ray SDK's dbapi instrumentation.

SQL queries executed against the RDS database are captured as subsegments.

To trace SQL database operations.

Key Concept

AWS X-Ray SDK patching and instrumentation for downstream service and database calls.

Question 185Question →

A developer is troubleshooting a cross-account deployment failure. A CI/CD pipeline using AWS CodePipeline in Account A ( $111111111111$ ) needs to deploy resources into Account B ( $222222222222$ ) by assuming a role named `CrossAccountDeployRole` in Account B.

The pipeline fails at the deploy stage with the error:
`CodePipeline is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::222222222222:role/CrossAccountDeployRole`

In Account B, the developer has configured the following trust policy for `CrossAccountDeployRole`:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "codepipeline.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}

Which two actions should the developer take to resolve this authorization failure?

Select all that apply

Attach an IAM policy to the CodePipeline service role in Account A that allows the `sts:AssumeRole` action on `arn:aws:iam::222222222222:role/CrossAccountDeployRole`.

Update the trust policy of `CrossAccountDeployRole` in Account B to replace the `codepipeline.amazonaws.com` service principal with the ARN of the CodePipeline service role in Account A.

Attach an identity-based permission policy to `CrossAccountDeployRole` in Account B that allows the `sts:AssumeRole` action on the CodePipeline service role in Account A.

Store a set of long-term IAM user access keys from Account B inside the CodePipeline configuration and pass them as environment variables.

Configure an Amazon Cognito Identity Pool in Account B to authenticate the CodePipeline service principal and issue temporary credentials.

Show answer & explanation

Answer: Attach an IAM policy to the CodePipeline service role in Account A that allows the `sts:AssumeRole` action on `arn:aws:iam::222222222222:role/CrossAccountDeployRole`.; Update the trust policy of `CrossAccountDeployRole` in Account B to replace the `codepipeline.amazonaws.com` service principal with the ARN of the CodePipeline service role in Account A.

Answer

Attach an IAM policy to the CodePipeline service role in Account A that allows the `sts:AssumeRole` action, and update the trust policy of `CrossAccountDeployRole` in Account B to trust the CodePipeline service role in Account A.

For cross-account role assumption, two permissions must be aligned: the initiator (CodePipeline service role in Account A) must have an identity policy allowing the `sts:AssumeRole` action on the target role, and the receiver (the target role in Account B) must have a trust policy listing the initiator's role ARN as a trusted principal. Using the service principal `codepipeline.amazonaws.com` is incorrect because cross-account actions are performed by the role executing the pipeline, not the service itself.

Step-by-Step Solution

Identify the principal attempting the assume-role action.

The AWS CodePipeline execution in Account A operates under the security context of the CodePipeline service role, not the generic service principal.

Understanding the security principal is essential for establishing cross-account access.

Configure the trust relationship on the target role in Account B.

Modify the trust policy of `CrossAccountDeployRole` in Account B to trust the specific IAM role ARN from Account A rather than the service principal.

A trust policy must trust the calling identity's ARN to allow cross-account access.

Configure permissions on the initiating role in Account A.

Attach an identity policy to the CodePipeline service role in Account A permitting `sts:AssumeRole` on the target role ARN in Account B.

IAM requires both the target trust policy and the caller's permission policy to allow cross-account operations.

Key Concept

Cross-account IAM role assumption requires both an identity-based permission policy in the source account allowing sts:AssumeRole, and a trust policy in the target account permitting the source principal to assume it.

Question 186Question →

A developer is configuring a CI/CD pipeline in AWS CodePipeline that uses AWS CodeDeploy to perform a blue/green deployment for a microservice running on Amazon ECS. The developer defines a set of deployment lifecycle hooks in the appspec.yaml file to run Lambda functions that perform integration tests. The pipeline fails during the deployment phase, and the CodeDeploy deployment log shows that the appspec.yaml contains an invalid lifecycle hook. The appspec.yaml includes the 'BeforeInstall', 'ApplicationStart', and 'AfterAllowTraffic' hooks. Which of the following is the primary cause of this deployment failure?

The CodeDeploy service role lacks a trust policy allowing the Amazon ECS service to assume the role, preventing the validation of the lifecycle hooks.

The ECS Task Execution Role is missing the required permissions to execute the container commands defined under the ApplicationStart phase.

The 'ApplicationStart' hook is an EC2/On-Premises deployment lifecycle hook and is not supported in Amazon ECS deployments.

The CloudFormation stack managing the ECS service is currently in the ROLLBACK_COMPLETE state, blocking any new CodeDeploy lifecycle hooks from running.

Show answer & explanation

Answer: The 'ApplicationStart' hook is an EC2/On-Premises deployment lifecycle hook and is not supported in Amazon ECS deployments.

Answer

The 'ApplicationStart' hook is an EC2/On-Premises deployment lifecycle hook and is not supported in Amazon ECS deployments.

In Amazon ECS deployments, AWS CodeDeploy supports a specific, limited set of lifecycle hooks to run Lambda validation functions: BeforeInstall, AfterInstall, AfterAllowTestTraffic, BeforeAllowTraffic, and AfterAllowTraffic. The ApplicationStart hook is specific to EC2/On-Premises deployments (which also include ApplicationStop, BeforeInstall, Install, AfterInstall, ValidateService, etc.). Including ApplicationStart in an ECS appspec.yaml file results in a validation failure during the deployment phase.

Step-by-Step Solution

Identify the deployment target and configuration context from the error message.

The target is Amazon ECS using CodeDeploy, and the failure is caused by an invalid lifecycle hook in the appspec.yaml file.

Understanding the target environment (ECS vs EC2) determines which AppSpec structure and hook names are valid.

Compare the hook names provided in the scenario with the list of supported hooks for ECS deployments.

ECS deployments support hooks like BeforeInstall, AfterInstall, AfterAllowTestTraffic, BeforeAllowTraffic, and AfterAllowTraffic. The hook 'ApplicationStart' is only supported in EC2/On-Premises deployments.

Mismatched lifecycle hooks between platforms cause validation errors in AWS CodeDeploy.

Select the option that correctly identifies the invalid hook and the target compatibility mismatch.

The correct option is the one stating that 'ApplicationStart' is an EC2-specific hook and not supported in ECS.

This directly matches the root cause of the AppSpec parsing/validation failure in CodeDeploy.

Key Concept

AWS CodeDeploy AppSpec lifecycle hooks differ significantly between EC2/On-Premises and Amazon ECS deployment types.

Estimated Time:1m 30s

Question 187Question →

A developer is implementing an AWS Lambda function that processes customer feedback and calls a third-party translation API over the internet. The Lambda function is configured to run inside a custom VPC and is associated with two public subnets. The VPC has an Internet Gateway, and the route table for the public subnets contains a route pointing 0.0.0.0/0 to the Internet Gateway. During testing, the Lambda function fails to connect to the translation API and terminates after reaching its maximum timeout limit. What configuration change should the developer make to resolve this connection issue?

Enable the auto-assign public IP setting in the VPC subnets associated with the Lambda function to allow the function's network interfaces to receive public IP addresses.

Configure the Lambda function to run in private subnets, and route internet-bound traffic through a NAT Gateway.

Increase the execution timeout limit of the Lambda function and set the reserved concurrency to 1 to prevent connection pool exhaustion.

Attach an Internet Gateway directly to the Lambda function's network interface and update the security group rules to allow outbound HTTP/HTTPS traffic.

Show answer & explanation

Answer: Configure the Lambda function to run in private subnets, and route internet-bound traffic through a NAT Gateway.

Answer

Configure the Lambda function to run in private subnets, and route internet-bound traffic through a NAT Gateway.

The correct answer is to configure the Lambda function to run in private subnets and route internet-bound traffic through a NAT Gateway. This is because AWS Lambda functions configured within a VPC do not receive public IP addresses, even when associated with public subnets. As a result, they cannot route traffic directly to an Internet Gateway. Placing the Lambda function in private subnets and routing internet-bound traffic through a NAT Gateway (which has a public IP address) enables the function to reach external web APIs.

Step-by-Step Solution

Analyze the network configuration of the Lambda function.

The Lambda function is placed in public subnets with a route to an Internet Gateway.

To understand why the network connection to the public internet API is failing.

Determine how Lambda ENIs handle public routing.

Lambda ENIs are only assigned private IP addresses, regardless of whether they are deployed in a public or private subnet.

This explains why the Lambda function cannot communicate directly with the Internet Gateway (which requires a public IP address on the source interface).

Apply the standard serverless networking pattern for outbound internet access.

Move the Lambda function to private subnets and direct outbound traffic (0.0.0.0/0) to a NAT Gateway located in a public subnet.

The NAT Gateway performs network address translation using its elastic IP address, allowing the Lambda function to establish outbound connections to the internet.

Key Concept

AWS Lambda VPC networking and outbound internet access constraints

Question 188Question →

A developer is troubleshooting a Python application running on a local workstation. The application uses the AWS SDK for Python (Boto3) to read objects from an Amazon S3 bucket. To configure the correct development credentials, the developer creates a profile named 'dev-profile' in the local ~/.aws/credentials file and sets the environment variable AWS_PROFILE=dev-profile in the terminal. However, when executing the script, the developer receives an AccessDenied error indicating that access is denied for an old, incorrect IAM user that is not defined in the 'dev-profile'. Which of the following is the most likely cause of this behavior?

Active AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables are set in the terminal session, which take precedence over the AWS_PROFILE environment variable.

The Boto3 client initialization code explicitly specifies hardcoded, expired access keys in its parameters, which overrides the profile configuration.

The local workstation's IP address is not explicitly authorized under an IAM trust policy, which prevents Boto3 from reading profiles in the shared credentials file.

The application is attempting to retrieve access credentials from Systems Manager Parameter Store instead of AWS Secrets Manager, causing a fallback to default credentials.

Show answer & explanation

Answer: Active AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables are set in the terminal session, which take precedence over the AWS_PROFILE environment variable.

Answer

Active AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables are set in the terminal session, which take precedence over the AWS_PROFILE environment variable.

The correct option is correct because the AWS SDK credential provider chain evaluates explicit credential environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY) before the shared credentials file. If these environment variables are set in the active terminal session, Boto3 will use them and ignore the profile specified by the AWS_PROFILE environment variable.

Step-by-Step Solution

Evaluate the AWS SDK credential provider chain order.

The SDK looks first for credentials passed directly to the client constructor, followed by environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_SESSION_TOKEN), and then shared configuration and credential files (referenced by AWS_PROFILE).

This establishes which credential source takes precedence when multiple sources are configured.

Analyze the conflicting configurations in the scenario.

The developer configured AWS_PROFILE in the environment, but the application is still authenticating as an incorrect, old IAM user.

This indicates that a credential source with higher precedence than the credentials file (such as active credential environment variables) is active in the environment and overriding the AWS_PROFILE selection.

Identify the corrective action.

Unsetting the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables in the terminal session will allow the SDK to fall back to the credentials file and load the 'dev-profile' profile specified by AWS_PROFILE.

Removing the higher-precedence environment variables allows the lower-precedence profile credentials to be resolved successfully.

Key Concept

AWS SDK Credential Provider Chain Precedence

Question 189Question →

A Vue.js single-page application hosted on `https://dashboard.analyticsapp.io` receives a `502 Bad Gateway` error in the browser console when sending a `DELETE` request to an Amazon API Gateway REST API. The API Gateway resource is integrated with a Lambda function using Lambda Proxy Integration. While CloudWatch logs show the Lambda function executed successfully and returned the raw JSON `{"status": "success", "message": "Record deleted"}`, the API Gateway Execution logs reveal the error: 'Execution failed due to configuration error: Malformed Lambda proxy response'. Which of the following modifications should the developer make to resolve this error?

Modify the Integration Response in the API Gateway Console to parse the JSON object returned by the Lambda function and map it to a `200 OK` HTTP status code using a Velocity Template Language (VTL) mapping template.

Change the Lambda function code to return a JSON object with the keys `statusCode` as an integer, `headers` containing the required CORS headers, and a stringified JSON string of the payload in the `body` field.

Enable CORS on the Amazon S3 bucket hosting the Vue.js single-page application and add the domain `https://dashboard.analyticsapp.io` to the bucket's CORS configuration file.

Update the API Gateway integration request to use a Lambda Authorizer instead of Lambda Proxy Integration, and return an IAM policy that allows the `execute-api:Invoke` action on the `DELETE` method.

Show answer & explanation

Answer: Change the Lambda function code to return a JSON object with the keys `statusCode` as an integer, `headers` containing the required CORS headers, and a stringified JSON string of the payload in the `body` field.

Answer

Change the Lambda function code to return a JSON object with the keys statusCode as an integer, headers containing the required CORS headers, and a stringified JSON string of the payload in the body field.

The correct answer is to modify the Lambda function to return a formatted JSON object with `statusCode`, `headers`, and a stringified `body`. When using Lambda Proxy Integration, API Gateway requires the backend function to return a specific JSON schema. If the function returns a raw custom JSON object without these fields, API Gateway cannot construct the HTTP response, resulting in a `502 Bad Gateway` error with the 'Malformed Lambda proxy response' log. Additionally, because the client is a single-page application hosted on a different origin, the `headers` object must include the necessary CORS headers (e.g., `Access-Control-Allow-Origin`) to prevent browser CORS blocks.

Step-by-Step Solution

Analyze the API Gateway execution logs and client-side HTTP error.

The 502 Bad Gateway status and the log message 'Malformed Lambda proxy response' indicate that the backend Lambda function is integrated via Lambda Proxy Integration but did not return the schema expected by API Gateway.

API Gateway requires a specific output format from Lambda functions when using proxy integrations.

Differentiate between Lambda Proxy and Lambda Custom integration response handling.

Unlike Custom Integration, which allows the use of API Gateway Integration Response mapping templates (VTL) to format raw outputs, Proxy Integration requires the backend Lambda function to construct the complete HTTP response structure directly.

This establishes that the fix must be implemented within the Lambda function code rather than in the API Gateway configuration.

Identify the required schema fields for Lambda Proxy Integration.

The Lambda function response must be a JSON object with `statusCode` (integer), `headers` (map/object), and `body` (stringified payload).

Failing to supply these fields leads to a configuration execution failure in API Gateway.

Determine the CORS requirements for cross-origin frontend requests.

Because the request is initiated from `https://dashboard.analyticsapp.io` (a different origin), the function must return the CORS header `Access-Control-Allow-Origin` inside the `headers` key of the proxy response.

For Proxy Integrations, CORS headers enabled via the API Gateway console only apply to the mock OPTIONS preflight response, not to the actual integration response.

Key Concept

API Gateway Lambda Proxy Integration Response Structure and CORS Requirements

Estimated Time:2m 0s

Question 190Question →

A restaurant reservation system named TableReserve records guest bookings into an Amazon DynamoDB table. During peak hours, the application experiences performance degradation and receives multiple ProvisionedThroughputExceededException errors when writing reservation records. The table's partition key is ReservationDate (formatted as YYYY-MM-DD), causing all write requests for a specific date to target the same partition. Which TWO actions should the developer take to resolve these throttling issues and improve partition write distribution? (Select TWO.)

Select all that apply

Append a random hash or suffix to the partition key value when writing records to distribute the write load.

Migrate the DynamoDB table from provisioned capacity mode to on-demand capacity mode to handle traffic spikes automatically.

Increase the Amazon SQS queue visibility timeout to give the application more time to process the reservation messages.

Modify the application code to retrieve data using Scan operations instead of Query operations.

Hardcode static AWS credentials in the AWS SDK client initialization to eliminate request authorization latency.

Show answer & explanation

Answer: Append a random hash or suffix to the partition key value when writing records to distribute the write load.; Migrate the DynamoDB table from provisioned capacity mode to on-demand capacity mode to handle traffic spikes automatically.

Answer

The correct actions are appending a random suffix to the partition key value and migrating the table to on-demand capacity mode.

The correct solution involves appending a random suffix to the partition key (write sharding) to distribute writes across multiple partitions and migrating to on-demand capacity mode to handle reservation spikes dynamically.

Step-by-Step Solution

Analyze the DynamoDB partition key design.

Using ReservationDate (YYYY-MM-DD) results in a hot partition key because all reservations for a given day hit the same partition.

Identifying the root cause helps determine that the database throughput degradation is due to poor write distribution.

Apply write sharding by appending a random suffix to the partition key.

Writes are distributed across multiple partitions (e.g., YYYY-MM-DD#1, YYYY-MM-DD#2).

This distributes the workload uniformly and resolves hot partition throttling.

Configure the table to use on-demand capacity mode.

DynamoDB dynamically scales to handle peak booking traffic automatically.

This accommodates spikes in reservations without manual capacity provisioning adjustments.

Key Concept

Resolving DynamoDB throttling issues by redesigning the partition key schema (sharding) and adjusting the table capacity mode.

Question 191Question →

A developer has deployed an AWS Lambda function inside the private subnets of a custom VPC. The function processes metadata uploads, writes records to an Amazon Aurora PostgreSQL database located in the same private subnets, and notifies an external analytics endpoint (https://analytics.example.com/api/log) via HTTPS. During testing, the developer notices that the Lambda function intermittently fails due to execution timeouts when calling the external API. Additionally, under heavy concurrent load, the Aurora database runs out of available connections, causing subsequent invocations to fail. The database connection client is currently initialized inside the Lambda handler function.

Which two actions should the developer take to resolve the timeout failures and prevent database connection exhaustion? (Select TWO.)

Select all that apply

Update the route table associated with the Lambda function's subnets to route traffic destined for 0.0.0.0/0 to a NAT Gateway.

Initialize the database connection client outside of the Lambda handler function, allowing the connection to be reused across warm execution contexts.

Move the Lambda function to the public subnets of the VPC to grant it direct access to the Internet Gateway.

Increase the Lambda function's timeout configuration to 15 minutes to allow sufficient time for new database connections to be established.

Configure the security group attached to the Lambda function to allow inbound HTTPS traffic from the external analytics service's IP addresses.

Show answer & explanation

Answer: Update the route table associated with the Lambda function's subnets to route traffic destined for 0.0.0.0/0 to a NAT Gateway.; Initialize the database connection client outside of the Lambda handler function, allowing the connection to be reused across warm execution contexts.

Answer

Update the route table associated with the Lambda function's subnets to route traffic destined for 0.0.0.0/0 to a NAT Gateway, and initialize the database connection client outside of the Lambda handler function to reuse it across executions.

The correct options are updating the private subnet route table to point default traffic to a NAT Gateway and initializing the database connection client outside the handler. The NAT Gateway provides the outbound route required for the Lambda function to reach the external analytics endpoint. Moving the database connection logic outside the handler leverages Lambda's execution context reuse, preserving database connection limits.

Step-by-Step Solution

Address the external API timeout issue by configuring network routing.

The Lambda function inside the private VPC subnet can access the internet to call the external HTTP endpoint.

VPC-enabled Lambda functions lack internet access by default. To reach the internet, they must be deployed in private subnets with a route table rule pointing 0.0.0.0/0 traffic to a NAT Gateway located in a public subnet.

Address the database connection limit exhaustion by optimizing connection reuse.

Database connections are reused across sequential Lambda invocations on the same execution environment, drastically reducing the total concurrent connection count on the Aurora database.

Initializing connections inside the handler function creates a new PostgreSQL connection per invocation. Moving the initialization outside the handler ensures execution context reuse, meaning warm containers keep their database connections active and reuse them.

Key Concept

Configuring outbound VPC routing for Lambda and utilizing execution context reuse for resource connection management.

Question 192Question →

A developer is configuring an AWS Lambda function to process events from an Amazon SQS queue. The queue is encrypted using an AWS Key Management Service (AWS KMS) customer managed key. The Lambda function's execution role has the following IAM policy attached:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sqs:ReceiveMessage",
"sqs:DeleteMessage",
"sqs:GetQueueAttributes"
],
"Resource": "arn:aws:sqs:us-east-1:123456789012:QueueA"
}
]
}

The KMS customer managed key has the following key policy:

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Allow administration of the key",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/KeyManager"
},
"Action": "kms:*",
"Resource": "*"
}
]
}

When the Lambda event source mapping attempts to poll the queue, the function is not triggered, and CloudWatch logs indicate that the Lambda service is unauthorized to decrypt the SQS messages.

Which of the following modifications is required to resolve this authorization failure?

Modify the trust policy of the AWS KMS key to list the Lambda service principal lambda.amazonaws.com as a trusted entity allowed to assume the KMS key.

Add kms:Decrypt permissions targeting the KMS key to the Lambda execution role's policy, and update the KMS key policy to allow the Lambda execution role to perform kms:Decrypt operations.

Initialize the AWS SDK client inside the Lambda function by hardcoding the AWS access credentials of the KeyManager IAM user to decrypt the SQS message payload.

Configure an Amazon Cognito Identity Pool to authenticate the Lambda function, and attach a policy allowing the Cognito authenticated role to perform kms:Decrypt on the KMS key.

Show answer & explanation

Answer: Add kms:Decrypt permissions targeting the KMS key to the Lambda execution role's policy, and update the KMS key policy to allow the Lambda execution role to perform kms:Decrypt operations.

Answer

Add kms:Decrypt permissions targeting the KMS key to the Lambda execution role's policy, and update the KMS key policy to allow the Lambda execution role to perform kms:Decrypt operations.

The correct action is to add the kms:Decrypt permission to both the Lambda execution role and the KMS key policy. This is because AWS KMS customer managed keys require explicit authorization in the key policy itself if they do not delegate permission management to the account root principal. Without the key policy explicitly permitting the Lambda execution role, and the execution role explicitly permitting the action, the decryption request will fail.

Step-by-Step Solution

Analyze the IAM execution role of the Lambda function and notice it lacks kms:Decrypt permissions on the customer managed key used to encrypt the SQS queue.

Identify that the Lambda function execution role cannot decrypt the messages fetched from SQS.

AWS SQS queues encrypted with customer managed keys require KMS decrypt permissions for the consumer principal.

Analyze the customer managed KMS key policy and notice it only grants administrative permissions to a specific user, without delegating authorization to the account root or the Lambda execution role.

Identify that adding kms:Decrypt only to the IAM role is insufficient; the key policy must also explicitly allow it.

KMS key policies are the primary authorization mechanism for KMS keys and must explicitly allow the caller unless delegation to the account root is configured.

Update both the Lambda execution role policy and the KMS key policy to permit the kms:Decrypt operation.

The Lambda event source mapping successfully decrypts SQS payloads and triggers the Lambda function.

Providing permissions at both the IAM identity layer and the KMS key resource layer satisfies AWS evaluation logic for customer managed KMS keys.

Key Concept

AWS KMS evaluation logic requires that customer managed keys explicitly grant permissions to the IAM caller in the key policy, in addition to permissions in the identity-based policy.

Question 193Question →

A developer is troubleshooting a local Node.js application that uses the AWS SDK for JavaScript (v3) to query an Amazon DynamoDB table in a development environment. The developer has configured a local profile named 'dev-profile' in the ~/.aws/credentials file and specified the target region as 'us-west-2' in ~/.aws/config under the same profile. The developer runs the application after setting the AWS_PROFILE environment variable to 'dev-profile'. However, the application fails to connect to the development DynamoDB table, throwing access denied errors because it is attempting to connect to the us-east-1 region using credentials associated with a production account. Upon checking the environment, the developer discovers that the AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_REGION (set to us-east-1) environment variables are also set in the current shell session. Which two actions should the developer take to ensure the local application correctly uses the credentials and region defined in the 'dev-profile' profile?

Select all that apply

Unset the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables in the local shell session.

Unset the AWS_REGION environment variable in the local shell session.

Hardcode the AWS access keys directly in the DynamoDB client initialization options in the application code.

Modify the trust policy of the production IAM role to allow the local workstation's public IP address to assume the role.

Store the development access keys as plaintext strings in AWS Systems Manager Parameter Store and retrieve them during application initialization.

Show answer & explanation

Answer: Unset the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables in the local shell session.; Unset the AWS_REGION environment variable in the local shell session.

Answer

Unset the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables in the local shell session, and unset the AWS_REGION environment variable in the local shell session.

Unsetting the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables forces the AWS SDK credentials provider chain to fall back to the next source, which is the shared credentials file profile indicated by AWS_PROFILE. Similarly, unsetting the AWS_REGION environment variable allows the SDK to read the region property defined under the profile configuration in ~/.aws/config instead of being overridden by the environment.

Step-by-Step Solution

Analyze the AWS SDK credential provider chain resolution order.

The SDK checks environment variables (AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY) before checking shared credentials files.

Because credentials environment variables are set, they override the AWS_PROFILE setting, causing the application to use production credentials.

Analyze the AWS SDK region configuration resolution order.

The SDK checks the AWS_REGION environment variable before checking profile-specific configurations in ~/.aws/config.

Because the AWS_REGION environment variable is set to us-east-1, it overrides the us-west-2 setting specified in the dev-profile profile.

Unset the overriding environment variables in the active shell environment.

The environment variables are cleared, and the SDK successfully falls back to retrieving credentials and region configuration from the dev-profile configurations.

Clearing the environment variables enables the default provider chain to locate and use the profile settings correctly.

Key Concept

AWS SDK Credential and Configuration Resolution Precedence

Question 194Question →

A developer has a payment-processing application implemented as an AWS Lambda function. During peak hours, this function occasionally fails because it exceeds its configured timeout limit of 15 seconds. The developer needs to configure an Amazon CloudWatch Logs metric filter to count these timeout occurrences and trigger an alarm. The log group contains both application-generated JSON logs and standard Lambda platform logs. The Lambda platform writes the timeout log as a plain text string:

`2026-07-14T17:20:32.123Z 88a381cf-192a-4a6f-9988-51fcf5498bd6 Task timed out after 15.02 seconds`

Which of the following is the correct configuration or filter pattern for this metric filter?

Set the filter pattern to { $.message = "Task timed out*" } to extract the message field from the platform log.

Set the filter pattern to "Task timed out" to match the plain text log line generated by the Lambda service.

Catch the timeout exception within the Lambda function code using a try-catch block, write a custom JSON log with a status of "timeout", and set the filter pattern to { $.status = "timeout" }.

Set the filter pattern to [timestamp, request_id, message = "*Task timed out*"] to parse the space-delimited log line.

Show answer & explanation

Answer: Set the filter pattern to "Task timed out" to match the plain text log line generated by the Lambda service.

Answer

Set the filter pattern to "Task timed out" to match the plain text log line generated by the Lambda service.

The correct answer is to use a simple text/phrase filter pattern. The Lambda platform writes timeout logs as plain text rather than JSON. An exact phrase match in double quotes like "Task timed out" will correctly scan the log group and match these events.

Step-by-Step Solution

Analyze the log format of the target event

The target event is a standard Lambda platform timeout log, which is a plain text string: `2026-07-14T17:20:32.123Z 88a381cf-192a-4a6f-9988-51fcf5498bd6 Task timed out after 15.02 seconds`.

Understanding the format (JSON vs. plain text) is critical to selecting the correct CloudWatch Logs filter pattern type.

Determine if application-level handling is possible

Since execution timeouts are enforced by the Lambda service, the execution context is immediately halted. Application code cannot catch the timeout to write a custom JSON log.

This rules out relying on custom JSON logs for timeout monitoring.

Select the correct filter pattern syntax for plain text logs

Since the log is plain text, JSON filter syntax cannot be used. A simple phrase match pattern like "Task timed out" must be used to match the exact substring.

Using double quotes ensures an exact, case-sensitive phrase match for the plain text log line.

Key Concept

Monitoring and Analyzing Logs with Amazon CloudWatch

Estimated Time:2m 0s

Question 195Question →

An AWS Lambda function is configured to run inside private subnets of a custom VPC to retrieve records from an Amazon RDS PostgreSQL database. After retrieving the records, the function attempts to upload a compiled report to an Amazon S3 bucket. The function successfully connects to the database but consistently times out when attempting to write to the S3 bucket. The VPC has no NAT Gateway or internet connectivity. Which action should the developer take to resolve this execution issue?

Move the Lambda function to a public subnet within the VPC and enable the auto-assign public IP configuration.

Increase the Lambda function's execution timeout limit to 15 minutes to allow the connection retry attempts to succeed.

Create a Gateway VPC Endpoint for Amazon S3 and associate it with the route table of the Lambda function's subnets.

Modify the Lambda function's IAM execution role to include the s3:PutObject permission for the target S3 bucket.

Show answer & explanation

Answer: Create a Gateway VPC Endpoint for Amazon S3 and associate it with the route table of the Lambda function's subnets.

Answer

Create a Gateway VPC Endpoint for Amazon S3 and associate it with the route table of the Lambda function's subnets.

The correct answer is to create a Gateway VPC Endpoint for Amazon S3. When a Lambda function runs inside a custom VPC without internet egress (no NAT Gateway), it can communicate locally but cannot reach public AWS endpoints. A Gateway VPC Endpoint establishes private connectivity to Amazon S3 directly from the private subnet's route table.

Step-by-Step Solution

Analyze execution symptoms

Database access succeeds, but S3 upload hangs and times out.

Since database access works, the function's VPC configuration is correct for internal routing, but the lack of public access blocks direct S3 uploads.

Check VPC egress design

Identify that the VPC has no NAT Gateway or public internet route.

S3 is a public service, so requests to it from a private VPC subnet require either NAT egress or a direct VPC endpoint.

Configure a Gateway VPC Endpoint

A Gateway VPC Endpoint for S3 is provisioned and linked to the subnet's route table.

Gateway endpoints allow secure, private routing of S3 traffic without routing traffic over the public internet.

Key Concept

Debugging network routing for Lambda functions configured inside a custom VPC

Question 196Question →

A developer is troubleshooting an application where messages are being processed multiple times from an Amazon SQS queue. The developer suspects that the consumer AWS Lambda function is timing out during execution, causing messages to return to the queue. The developer wants to monitor and analyze these timeouts using Amazon CloudWatch Logs.

Which of the following actions should the developer take to correctly identify and track these execution timeouts? (Select TWO.)

Select all that apply

Create a CloudWatch metric filter on the Lambda function's log group using the filter pattern "\"Task timed out\"" to increment a custom metric.

Use Amazon CloudWatch Logs Insights to run a query with the command "filter @message like /Task timed out/" on the Lambda function's log group.

Create a CloudWatch metric filter on the log group using the filter pattern "Task timed out" (without double quotes) to count the occurrences of the timeout message.

Implement a try-catch block within the Lambda function handler to catch the execution timeout and write a custom log entry to CloudWatch Logs.

Configure a CloudWatch metric filter using the JSON pattern "{ $.errorMessage = \"Task timed out*\" }" to extract the error details.

Show answer & explanation

Answer: Create a CloudWatch metric filter on the Lambda function's log group using the filter pattern "\"Task timed out\"" to increment a custom metric.; Use Amazon CloudWatch Logs Insights to run a query with the command "filter @message like /Task timed out/" on the Lambda function's log group.

Answer

Create a CloudWatch metric filter with the quoted pattern "Task timed out" to count occurrences of timeouts, and use CloudWatch Logs Insights to query the log group with a filter mapping the timeout phrase.

The correct options involve creating a CloudWatch metric filter using the exact phrase search pattern enclosed in double quotes (which allows tracking the exact phrase written by the Lambda service), and using CloudWatch Logs Insights with a string match filter to query these plain text timeout logs.

Step-by-Step Solution

Understand how AWS Lambda reports execution timeouts in CloudWatch Logs.

Identify that the Lambda service appends a plain text log line containing 'Task timed out after X seconds' when a function times out.

Since the function is abruptly terminated, the application itself cannot catch the timeout, making CloudWatch Logs analysis the only direct way to verify timeouts.

Select the correct pattern matching syntax for CloudWatch metric filters.

Use double quotes around the phrase "Task timed out" to perform an exact match query on the plain text log events.

Unquoted terms act as an OR condition (Task OR timed OR out), which will match other log lines and trigger false alarms.

Use CloudWatch Logs Insights to query historical logs.

Write a query utilizing the 'like' operator to search log streams for the timeout message.

Logs Insights allows rapid searching and analysis of log events without having to manually read through individual log streams.

Key Concept

Monitoring plain text Lambda runtime logs in CloudWatch using exact phrase metric filters and Logs Insights queries.

Question 197Question →

An accounting application named LedgerSync records daily business transactions into an Amazon DynamoDB table. The table is configured with a partition key of `TransactionDate` (formatted as `YYYY-MM-DD`) and a sort key of `TransactionId`. The table is provisioned with $1,000$ Write Capacity Units (WCUs). During end-of-month reconciliation, batch processing writes hundreds of thousands of transactions for the same calendar date within a 10-minute window. Even though the total write request rate is well below the table's overall provisioned $1,000$ WCUs, the application repeatedly encounters `ProvisionedThroughputExceededException` errors. Which of the following approaches is the most effective way to resolve this throughput issue while maintaining cost efficiency?

Redesign the partition key schema by appending a calculated or random suffix to the date, distributing the write load across multiple logical partitions, and adjust queries to target those partitioned keys.

Increase the overall Provisioned Write Capacity Units (WCUs) of the DynamoDB table to

10,000

during the reconciliation window to scale partition capacity limits.

Modify the application logic to use DynamoDB Scan operations instead of Query operations to retrieve transaction records in parallel during reconciliation.

Increase the visibility timeout of the Amazon SQS queue that buffers the incoming transaction writes to allow consumers more time to execute writes to the DynamoDB table.

Show answer & explanation

Answer: Redesign the partition key schema by appending a calculated or random suffix to the date, distributing the write load across multiple logical partitions, and adjust queries to target those partitioned keys.

Answer

The correct answer is correct because DynamoDB enforces a strict limit of

1,000

Write Capacity Units (WCUs) per partition. When all incoming writes target a single partition key value (such as the same `TransactionDate`), they are directed to the same partition, exceeding its throughput limit and triggering `ProvisionedThroughputExceededException`. Appending a synthetic suffix (such as a random or calculated number) to the partition key distributes the write load across multiple logical keys and physical partitions, raising the effective throughput limit for that date while keeping the table cost-effective.

Step-by-Step Solution

Analyze the workload and table schema.

Identify that the partition key is `TransactionDate`. During reconciliation, all writes for a specific date target a single partition key value (e.g., '2026-06-30').

This concentrates all writes into a single logical partition key, creating a hot partition key.

Evaluate DynamoDB partition limits against the workload requirements.

Realize that a single partition key has a maximum throughput limitation of

1,000

WCUs (or

1,000

writes/sec). Total table capacity does not bypass this individual key limit.

Knowing this limit explains why provisioned throughput exceeded errors occur despite having sufficient overall capacity.

Apply a sharding strategy (adding a synthetic suffix) to partition keys.

Append a suffix (e.g., a random number between

1

and

10

) to `TransactionDate` before saving, yielding keys like `2026-06-30_1` to `2026-06-30_10`.

This distributes the writes across multiple logical partitions, allowing up to

10 \times 1,000 = 10,000

WCUs for that day's data.

Key Concept

Mitigating DynamoDB hot partition key bottlenecks via write sharding (adding a synthetic suffix).

Estimated Time:2m 0s

Question 198Question →

A gaming application uses an Amazon DynamoDB table to store real-time player profiles. During a global tournament, the application experiences a massive spike in read traffic, resulting in `ProvisionedThroughputExceededException` errors due to hot partitions on popular player profiles. The development team decides to deploy an Amazon DynamoDB Accelerator (DAX) cluster to resolve the throttling and improve read latency.

Which actions must the developers take to ensure the application successfully utilizes the DAX cluster to resolve the read throttling? (Select two.)

Select all that apply

Update the application code to initialize and use the Amazon DynamoDB Accelerator (DAX) client SDK instead of the standard DynamoDB client.

Configure the read requests to use eventually consistent reads so that the data is served from the DAX item cache.

Increase the provisioned Read Capacity Units (RCUs) on the DynamoDB table to handle the overall peak load.

Change the application lookup mechanism to use Scan operations instead of Query operations to retrieve cached profiles.

Initialize the DAX client by hardcoding AWS access keys and secret keys directly in the initialization code to avoid authorization overhead.

Show answer & explanation

Answer: Update the application code to initialize and use the Amazon DynamoDB Accelerator (DAX) client SDK instead of the standard DynamoDB client.; Configure the read requests to use eventually consistent reads so that the data is served from the DAX item cache.

Answer

To successfully optimize read performance using DAX, the developers must use the DAX SDK client instead of the standard DynamoDB client, and configure read operations to use eventually consistent reads so that the results can be retrieved from the cache rather than bypassing it.

To successfully route and cache read operations through DAX, the standard DynamoDB client must be replaced with the DAX SDK client. In addition, the read requests must be configured as eventually consistent. Strongly consistent reads bypass the DAX cache and hit the DynamoDB table directly, which would fail to alleviate the hot partition throttling.

Step-by-Step Solution

Analyze the nature of the throttling error.

The error is caused by hot partitions on specific player profiles due to localized high read volume.

Identifying the root cause ensures that the caching solution is designed to offload reads from the hot partitions of the DynamoDB table.

Select the correct SDK client for DAX.

Initialize the DAX-specific client inside the application code.

DAX requires a custom SDK client to intercept calls and route them to the DAX cluster nodes instead of DynamoDB directly.

Adjust read consistency settings.

Modify DynamoDB read requests in the application to use eventually consistent reads.

DAX does not serve strongly consistent reads from its cache; strongly consistent reads are passed directly to DynamoDB, which would continue to throttle the hot partition.

Key Concept

DAX Caching Requirements and SDK Client

Question 199Question →

A developer is running a Python application locally using the AWS SDK for Python (Boto3) to retrieve objects from an Amazon S3 bucket.

The developer's local terminal has the following environment variables configured:

bash
export AWS_ACCESS_KEY_ID=AKIA111111111EXAMPLE
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
export AWS_PROFILE=staging

The shared AWS credentials file (`~/.aws/credentials`) contains:

ini
[staging]
aws_access_key_id = AKIA222222222EXAMPLE
aws_secret_access_key = userSecretKeyStagingExample

The application code is initialized as follows:

python
import boto3
s3 = boto3.client('s3')
response = s3.list_objects_v2(Bucket='my-staging-bucket')

When the developer runs the application, it fails with an `AccessDenied` error. The IAM user represented by `AKIA111111111EXAMPLE` does not have access to the S3 bucket, but the IAM user in the `staging` profile (`AKIA222222222EXAMPLE`) has full S3 permissions.

What is the reason for this failure, and how should the developer resolve it?

The default credential provider chain ignores environment variables when a profile is specified. The developer must modify the application code to hardcode the credentials by passing the aws_access_key_id and aws_secret_access_key parameters directly to the client constructor.

The staging profile credentials cannot be used locally because the IAM user has not configured a trust policy that allows the local workstation's IP address. The developer must add a trust policy to the IAM user permitting access from the local public IP.

The default credential provider chain evaluates the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables before evaluating AWS_PROFILE. The developer should unset the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables in the terminal.

The SDK requires local developer credentials to be retrieved dynamically from Systems Manager Parameter Store with automatic rotation configured. The developer must migrate the local credentials to Parameter Store and fetch them in the code.

Show answer & explanation

Answer: The default credential provider chain evaluates the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables before evaluating AWS_PROFILE. The developer should unset the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables in the terminal.

Answer

The correct answer explains that the AWS SDK's default credential provider chain resolves explicit credentials set in environment variables (such as AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY) prior to checking the profile configuration via the AWS_PROFILE environment variable. Unsetting the direct credential environment variables allows the SDK to process the rest of the provider chain, falling back to the credentials file to load the staging profile's authorized keys.

Step-by-Step Solution

Analyze the SDK's credential provider chain precedence.

The AWS SDK checks credentials in a specific order: first direct client parameters, then environment variables (AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY), and then the shared credentials file using the profile set in AWS_PROFILE.

To identify which credentials the Boto3 client is actually loading at runtime.

Identify the conflict between active environment variables.

Because AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY are set, the SDK uses them immediately and never looks at the staging profile specified by AWS_PROFILE.

To explain why the unauthorized credentials (AKIA111111111EXAMPLE) are being used instead of the staging credentials.

Remove the overriding environment variables.

Unsetting AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY in the terminal forces the credential provider chain to fall back to reading ~/.aws/credentials for the 'staging' profile.

To resolve the credential conflict and allow the application to authenticate using the correct credentials.

Key Concept

AWS SDK Default Credential Provider Chain Precedence

Estimated Time:1m 30s

Question 200Question →

A developer is troubleshooting an AWS Lambda function that is configured to access an Amazon RDS DB instance inside a private subnet of a custom VPC. The function also needs to call an external billing API over the public internet. During testing, the developer observes two issues: the function cannot establish a connection to the external billing API, and the database experiences connection exhaustion due to a high volume of database connections being created during peak traffic. Which two actions should the developer take to resolve these configuration and performance issues? (Select TWO.)

Select all that apply

Configure a NAT Gateway in a public subnet of the VPC and add a route pointing to it in the private subnet's route table.

Initialize the database connection client outside of the Lambda handler function to reuse connections across execution contexts.

Deploy the Lambda function in a public subnet and enable the public IP assignment configuration on the function.

Create a Gateway VPC Endpoint for the external billing API and associate it with the private subnet's route table.

Add code inside the Lambda handler to explicitly close the connection and force execution context recycling after every invocation.

Show answer & explanation

Answer: Configure a NAT Gateway in a public subnet of the VPC and add a route pointing to it in the private subnet's route table.; Initialize the database connection client outside of the Lambda handler function to reuse connections across execution contexts.

Answer

Configure a NAT Gateway in a public subnet of the VPC, add a route pointing to it in the private subnet's route table, and initialize the database connection client outside of the Lambda handler function.

To enable internet access for a Lambda function in a private VPC subnet, a NAT Gateway must be set up in a public subnet, and the private subnet's route table must route traffic bound for the internet to the NAT Gateway. Additionally, database connection clients should be declared globally outside the handler function to allow reuse of existing connections across subsequent warm executions of the same Lambda container instance.

Step-by-Step Solution

Analyze the network configuration of the Lambda function.

The Lambda function is inside a private subnet and cannot access the public internet directly.

To connect to the external billing API, the private subnet requires a route to a NAT Gateway located in a public subnet.

Analyze the database connection lifecycle within the Lambda function code.

Database connections are currently created inside the handler function on every invocation.

Declaring the database client globally (outside the handler) allows the connection to be reused across multiple warm execution context invocations, mitigating database connection exhaustion.

Key Concept

VPC Lambda internet access configurations and execution context reuse strategies.

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