Troubleshooting and Optimization

271 questions

Question 61Question

A developer is troubleshooting an AWS Lambda function that processes transaction files stored in an Amazon S3 bucket and updates a database running on an Amazon RDS MySQL DB instance. The RDS instance is deployed in 22 private subnets of a custom VPC.

To enable the Lambda function to access both Amazon S3 and the RDS instance, the developer configured the function to run within the VPC and associated it with the public subnets of the VPC. The Lambda function's security group is correctly allowed in the RDS security group's inbound rules.

During execution, the function fails with a timeout error. The logs show that the connection to the RDS DB instance is successful, but the function times out after 1515 seconds while attempting to connect to the Amazon S3 service endpoint.

Which two actions should the developer take to resolve this issue and follow AWS security best practices? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Associate the Lambda function with the private subnets of the VPC instead of the public subnets.; Create a Gateway VPC Endpoint for Amazon S3 and associate it with the route tables of the subnets where the Lambda function is deployed.

Answer

Associate the Lambda function with the private subnets of the VPC and create a Gateway VPC Endpoint for Amazon S3 associated with the route tables of those subnets.
To resolve the S3 timeout and secure the architecture, the developer must associate the Lambda function with the private subnets of the VPC and create a Gateway VPC Endpoint for Amazon S3. When a Lambda function is configured to run inside a VPC, it only receives private IP addresses on its Elastic Network Interfaces (ENIs). Consequently, it cannot route traffic to public AWS endpoints like Amazon S3 via the Internet Gateway, even if placed in a public subnet. Creating a Gateway VPC Endpoint for Amazon S3 allows the Lambda function to communicate with S3 over the private AWS network using the subnet's route tables. Moving the function to private subnets complies with security best practices.

Step-by-Step Solution

1
Analyze the network route paths for a Lambda function configured inside a VPC.
Understand that Lambda functions inside a VPC are allocated Elastic Network Interfaces (ENIs) with private IP addresses only. They do not get public IPs even if associated with public subnets.
Explain why the connection to the RDS DB instance inside the VPC succeeded (local routing), but the connection to S3 (public endpoint) failed.
2
Evaluate the security and architecture best practices for deploying Lambda functions that access VPC resources.
Determine that the Lambda function should be moved from the public subnets to the private subnets.
Lambda functions should always be placed in private subnets when connected to a VPC to reduce the attack surface and align with the principle of least privilege.
3
Configure a private connectivity mechanism for the Lambda function to access Amazon S3.
Create an Amazon S3 Gateway VPC Endpoint and associate it with the route tables of the private subnets.
This allows traffic destined for S3 to be routed internally through the AWS network backbone instead of attempting to go over the public internet, resolving the timeout error.

Key Concept

AWS Lambda functions running inside a VPC do not receive public IP addresses. To access public AWS services like Amazon S3, they must use VPC endpoints (such as a Gateway VPC Endpoint for S3) or route traffic through a NAT Gateway in a public subnet. For security, Lambda functions should always be associated with private subnets rather than public subnets.
Question 62Question

A developer has a Python-based worker application running on Amazon EC2 instances. The application manually polls an Amazon SQS queue for incoming messages, processes them, and writes the results to an Amazon DynamoDB table. The AWS X-Ray daemon is running on the EC2 instances, and the AWS SDK for Python (boto3) is instrumented. However, in the AWS X-Ray console, the developer observes that the traces for the SQS queue and the DynamoDB operations appear as separate, disconnected traces rather than a single end-to-end trace.

Which action should the developer take to correlate these traces?

Show answer & explanation

Answer: Extract the tracing header from the Amazon SQS message's `AWSTraceHeader` attribute, and use the AWS X-Ray SDK to create a segment using that header as the parent context before invoking the Amazon DynamoDB API.

Answer

Extract the tracing header from the Amazon SQS message's `AWSTraceHeader` attribute, and use the AWS X-Ray SDK to create a segment using that header as the parent context before invoking the Amazon DynamoDB API.
When a worker application manually polls an Amazon SQS queue, the tracing context from the producer is carried in the message's `AWSTraceHeader` attribute. Because context propagation is not automatic for manual polling, the developer must programmatically extract this header and use the AWS X-Ray SDK to create a segment with the correct parent trace ID. This links the worker's processing and any downstream AWS calls (like DynamoDB) to the original trace.

Step-by-Step Solution

1
Identify the mechanism for tracing context propagation through message queues.
Amazon SQS messages contain a trace header in the `AWSTraceHeader` attribute when sent from an instrumented upstream service.
Because the worker polls SQS manually, the context does not propagate automatically like it does in a direct AWS Lambda SQS event source trigger.
2
Use the AWS X-Ray SDK to parse the retrieved tracing header.
The SDK creates a new segment or subsegment using the extracted header as the parent context.
This establishes the parent-child relationship between the message producer and the worker's processing steps.
3
Execute downstream AWS SDK calls (DynamoDB write) within the context of the newly created segment.
The downstream calls are recorded as subsegments of the parent trace.
This ensures that all operations are correlated into a single, continuous trace on the X-Ray service map.

Key Concept

Manual propagation of AWS X-Ray tracing context across Amazon SQS message boundaries using the `AWSTraceHeader` attribute.
Estimated Time:1m 30s
Question 63Question

A developer is running a local Node.js application that uses the AWS SDK to read from an Amazon S3 bucket. During local testing, the application fails to connect to AWS and throws a credential loading error. Which two actions should the developer take to resolve this issue securely? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure the AWS Access Key ID and Secret Access Key in the shared AWS credentials file located at the default user profile path on the local machine.; Set the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables in the local shell session where the application is executed.

Answer

Configure the credentials in the shared AWS credentials file on the local machine, or set the access keys as environment variables in the local shell session.
The correct options are configuring the credentials in the shared AWS credentials file or setting the credentials as environment variables. The AWS SDK default credential provider chain automatically searches for environment variables first, followed by the shared credentials file. Both options are standard, secure ways to provide credentials to local applications without modifying the code.

Step-by-Step Solution

1
Identify that the AWS SDK requires valid credentials (access key ID and secret access key) to authenticate local API requests.
The application fails because no credentials are provided to the default credential provider chain.
By default, the SDK checks environment variables and local configuration files to locate credentials.
2
Apply a secure local credentials configuration method by either writing the credentials to the default shared AWS credentials file or exporting them as environment variables.
The SDK successfully loads the credentials automatically without hardcoding them in the source code.
Environment variables and the credentials file are high-priority locations checked by the default credential provider chain.

Key Concept

AWS SDK Default Credential Provider Chain and Local Authentication
Question 64Question

A developer is troubleshooting a local Python application that uses the Boto3 SDK to retrieve configuration parameters from AWS Systems Manager Parameter Store. The developer previously configured the local machine using the AWS CLI and confirmed that the shared credentials file (~/.aws/credentials) contains valid credentials under the default profile. However, when executing the script in a terminal session, the application returns a signature mismatch error (SignatureDoesNotMatch).

Which of the following is the most likely cause of this error?

Show answer & explanation

Answer: The terminal session has invalid or expired credentials set in the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables, which override the shared credentials file.

Answer

The terminal session contains active environment variables for AWS credentials that are invalid or expired, overriding the valid credentials configured in the shared credentials file.
The correct answer is correct because the AWS SDK default credential provider chain evaluates environment variables (such as AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY) before it checks the shared credentials file (~/.aws/credentials). If invalid or expired credentials are set in the terminal environment variables, the SDK will attempt to use them and fail, ignoring the valid credentials configured in the default profile of the shared credentials file.

Step-by-Step Solution

1
Analyze the error message and context.
The application returns a SignatureDoesNotMatch error, indicating that the AWS service rejected the signature generated by the SDK using the active credentials.
This error means the request was signed with an incorrect or corrupted access key/secret key combination, rather than missing credentials.
2
Determine the AWS SDK credential provider chain order.
The AWS SDK Default Credential Provider Chain looks for credentials in the following order: 1. Environment variables, 2. Shared credentials file, 3. Container credentials, 4. Instance profile credentials.
Understanding the lookup order helps identify which credentials the SDK actually loaded.
3
Identify the source of the invalid credentials.
Since environment variables have higher precedence than the shared credentials file, any credentials defined as environment variables in the current shell session will be used, even if the shared credentials file has valid credentials.
The presence of invalid environment variables explains why the valid profile credentials were ignored, resulting in the signature mismatch error.

Key Concept

AWS SDK Default Credential Provider Chain Precedence
Question 65Question

A developer is troubleshooting a local Java application that is failing to authenticate with Amazon DynamoDB. The developer has configured a profile in the shared credentials file (~/.aws/credentials) and also set the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables in the terminal session.

In which of the following locations will the default credential provider chain look to resolve credentials, and which has higher precedence? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Environment variables are evaluated first and have higher precedence than the shared credentials file.; The shared credentials file is evaluated after environment variables are checked.

Answer

The default credential provider chain evaluates environment variables first, and then evaluates the shared credentials file.
The Default Credentials Provider Chain in the AWS SDK evaluates credential sources in a specific order of precedence. Environment variables (such as AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY) are evaluated first, while the shared credentials file (~/.aws/credentials) is checked later in the chain.

Step-by-Step Solution

1
Determine the first locations checked by the Default Credentials Provider Chain.
The SDK checks environment variables (such as AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY) first.
Environment variables have higher precedence in the default credential chain than configuration files.
2
Determine where the SDK looks if environment variables are not present or to establish the next fallback.
The SDK checks the shared credentials file (~/.aws/credentials) next.
The shared credentials file is evaluated after environment variables.

Key Concept

AWS SDK Default Credentials Provider Chain precedence order
Estimated Time:1m 0s
Question 66Question

A developer is running a local Node.js application that uses the AWS SDK for JavaScript (v3) to read data from an Amazon DynamoDB table. The local machine has multiple AWS profiles defined in the `~/.aws/credentials` file. When executing the application, it fails with an `AccessDeniedException` because it attempts to use the default profile instead of a specific profile named `development-admin`. Which of the following actions can the developer take to resolve this issue? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Set the `AWS_PROFILE` environment variable to `development-admin` in the local terminal before executing the application.; Import the `fromIni` credential provider from the SDK and use it to explicitly instantiate the DynamoDB client with the `development-admin` profile.

Answer

Configure the local application to use the correct profile by setting the AWS_PROFILE environment variable or by explicitly loading the profile using the fromIni credential provider in the application code.
Setting the AWS_PROFILE environment variable forces the AWS SDK to look for the specified profile inside the shared credentials file. Alternatively, programmatically loading the profile via the fromIni credential provider configures the client to explicitly request credentials matching the development-admin profile.

Step-by-Step Solution

1
Analyze how the AWS SDK for JavaScript resolves local credentials.
Identify that the SDK uses the Default Credential Provider Chain, which looks for the AWS_PROFILE environment variable before falling back to the default profile in the credentials file.
Understanding credential precedence is key to routing local requests to the correct IAM profile.
2
Configure the execution environment using a named profile.
Setting the AWS_PROFILE environment variable instructs the SDK to use the development-admin profile from the shared configuration, resolving the AccessDeniedException.
Environment variables are evaluated early in the provider chain and require no code changes.
3
Implement code-based profile selection as an alternative.
Use the fromIni provider to programmatically select the development-admin profile from the credentials file.
This guarantees that the application consistently targets the correct profile, regardless of the developer's terminal environment variables.

Key Concept

AWS SDK Credential Provider Chain and Named Profiles
Estimated Time:1m 0s
Question 67Question

A developer is testing a Go application locally that reads messages from an Amazon SQS queue. The developer intends to run the application using a specific AWS CLI profile named `dev-profile` defined in the `~/.aws/credentials` file. However, when executing the application in the terminal, the application connects using credentials from a different AWS account. The developer notices that the environment variables `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` are currently set in the active terminal session. Which of the following actions will resolve this issue and force the Go SDK to use the configuration from `dev-profile`?

Show answer & explanation

Answer: Unset the `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` environment variables in the terminal, and set the `AWS_PROFILE` environment variable to `dev-profile`.

Answer

Unset the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables in the terminal, and set the AWS_PROFILE environment variable to dev-profile.
The AWS SDK credential provider chain evaluates environment variables (such as AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY) before checking the shared credentials file. Unsetting the active environment variables and defining AWS_PROFILE forces the SDK to retrieve credentials from the specified profile.

Step-by-Step Solution

1
Analyze the AWS SDK credential lookup order.
Environment variables have the highest precedence, followed by shared credentials/config files.
To force the SDK to look at the credentials file, any higher-precedence environment variables must be cleared or bypassed.
2
Select the target profile.
Set the AWS_PROFILE environment variable to dev-profile.
This instructs the SDK's default credential provider chain to look for the specific profile configuration in the credentials file.

Key Concept

AWS SDK Default Credential Provider Chain Precedence
Question 68Question

An AWS Lambda function is configured to upload generated reports to an Amazon S3 bucket. During execution, the Lambda function fails to write to the bucket and returns an 'Access Denied' error. How should the developer resolve this authorization failure?

Show answer & explanation

Answer: Attach an IAM policy to the Lambda execution role that grants the s3:PutObject action on the target S3 bucket ARN.

Answer

Attach an IAM policy to the Lambda execution role that grants the s3:PutObject action on the target S3 bucket ARN.
The correct option addresses the authorization failure by adding a policy to the Lambda execution role. In AWS, Lambda functions use an execution role to acquire temporary security credentials. Granting the 's3:PutObject' permission on the specific bucket ARN in this execution role permits the Lambda function to upload reports successfully.

Step-by-Step Solution

1
Identify the IAM role assigned as the Lambda function's execution role.
The execution role is located, which determines the identity and permissions of the executing function.
Permissions in Lambda are governed by the execution role.
2
Define an IAM policy document containing an 'Allow' statement for the 's3:PutObject' action on the S3 bucket's ARN.
A valid permission policy JSON or visual definition is created.
This policy specifies the exact resource and action that are currently failing due to authorization issues.
3
Attach the defined IAM policy to the identified Lambda execution role.
The Lambda execution role now possesses permissions to write to the S3 bucket.
Attaching the policy applies the permissions to the Lambda function's identity context, resolving the Access Denied error.

Key Concept

Resolving AWS permission failures by attaching identity-based IAM policies to execution roles.
Estimated Time:1m 0s
Question 69Question

An application container deployed on Amazon ECS tasks is designed to read encrypted objects from an Amazon S3 bucket. The objects are encrypted using an AWS KMS customer managed key. During execution, the application receives an 'Access Denied' error when trying to retrieve and decrypt the files. Which two configurations should the developer verify or modify to resolve this authorization failure? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Add s3:GetObject and kms:Decrypt permissions to the IAM policy attached to the ECS Task Role.; Update the AWS KMS key policy to permit the ECS Task Role to perform the kms:Decrypt action.

Answer

Attach an IAM policy to the ECS Task Role granting s3:GetObject and kms:Decrypt permissions, and ensure the KMS key policy allows the ECS Task Role to execute the kms:Decrypt action.
The correct configuration requires identifying that the application running inside the container uses the ECS Task Role for accessing AWS services. Since the objects in the S3 bucket are encrypted with a customer managed KMS key, the Task Role needs permissions for both reading from S3 and decrypting with the KMS key. Additionally, the key policy of the customer managed key must be updated to allow the Task Role to perform the decryption operation, as KMS key policies must explicitly allow access to IAM roles.

Step-by-Step Solution

1
Distinguish between the ECS Task Role and the ECS Task Execution Role.
Identify that the application code running inside the container uses the ECS Task Role to access AWS resources, while the ECS agent uses the Task Execution Role.
This prevents assigning application permissions to the wrong role.
2
Configure permissions for the S3 and KMS actions on the ECS Task Role.
Apply an IAM policy to the Task Role that includes s3:GetObject and kms:Decrypt permissions.
The application needs identity-based permissions to read the S3 objects and decrypt them using the custom key.
3
Ensure the KMS key policy delegates access to the ECS Task Role.
Update the KMS key policy of the customer managed key to allow the Task Role's ARN to call kms:Decrypt.
Unlike AWS managed keys, customer managed KMS keys require the key policy to explicitly authorize the IAM role.

Key Concept

Resolving authorization issues when accessing KMS-encrypted S3 resources from ECS tasks requires distinguishing between ECS Task Roles and Task Execution Roles, and ensuring both IAM identity policies and KMS key policies permit the action.
Question 70Question

A developer is troubleshooting an AWS Lambda function that processes batch files. The function fails during execution, and the Amazon CloudWatch logs show the message: "Task timed out after 3.003.00 seconds". The developer realizes the function requires at least 44 minutes to process the files. Which configuration change will resolve this issue?

Show answer & explanation

Answer: Increase the Lambda function timeout setting from the default of 33 seconds to a value greater than 44 minutes.

Answer

Increase the Lambda function timeout setting from the default of 33 seconds to a value greater than 44 minutes.
The correct answer is to increase the Lambda function timeout setting from the default of 33 seconds to a value greater than 44 minutes. By default, Lambda functions have a 33-second timeout, which is insufficient for tasks requiring several minutes of processing. Adjusting the timeout configuration in the AWS Management Console, CLI, or infrastructure-as-code template resolves this issue.

Step-by-Step Solution

1
Analyze the error message from CloudWatch logs.
The message indicates a timeout after 3.003.00 seconds, which is the default timeout limit for Lambda functions.
Understanding the error symptom is the first step in identifying the root cause.
2
Compare the required execution time with the configured limit.
The function needs at least 44 minutes, but it is currently limited to 33 seconds.
This establishes that the timeout limit must be raised to cover the required execution window.
3
Modify the Lambda function's configuration.
Change the timeout configuration to a value greater than 44 minutes (e.g., 55 minutes or 300300 seconds).
Adjusting the timeout configuration allows the function to execute to completion.

Key Concept

AWS Lambda function timeout configuration and troubleshooting
Question 71Question

A developer is troubleshooting an AWS Lambda function that processes customer orders and writes them to an Amazon RDS PostgreSQL database located in a private subnet. The Lambda function is configured to run inside the same VPC and private subnets. Additionally, the Lambda function must call a third-party payment gateway endpoint on the public internet. During execution, the Lambda function successfully connects to the database but fails with a timeout error when attempting to reach the payment gateway. Which configuration change is required to resolve this execution issue?

Show answer & explanation

Answer: Deploy a NAT Gateway in a public subnet of the VPC, and add a route in the private subnet's route table directing destination traffic of 0.0.0.0/00.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 subnet's route table directing destination traffic of 0.0.0.0/00.0.0.0/0 to the NAT Gateway.
The correct answer is correct because AWS Lambda functions configured within a VPC do not receive public IP addresses on their elastic network interfaces (ENIs). Consequently, they cannot communicate directly with the internet through an Internet Gateway. To access public endpoints while remaining inside a VPC, the Lambda function must run in private subnets, and the outbound traffic must be routed through a NAT Gateway positioned in a public subnet.

Step-by-Step Solution

1
Analyze the symptoms and network path.
The Lambda function successfully connects to the RDS database in the private subnet but fails to reach the external public internet endpoint, resulting in a timeout.
This confirms that VPC-internal routing is functional, but outbound internet routing from the Lambda's private subnets is blocked or missing.
2
Evaluate Lambda networking constraints in a VPC.
Understand that Lambda ENIs lack public IP addresses and cannot utilize an Internet Gateway directly, even if placed in a public subnet.
To communicate with the public internet from within a VPC, Lambda requires a NAT Gateway or NAT instance located in a public subnet.
3
Configure the private subnet routing.
Configure a NAT Gateway in a public subnet and add a route for 0.0.0.0/00.0.0.0/0 pointing to this NAT Gateway in the private subnet's route table.
This configuration allows the Lambda function to route its internet-bound traffic through the NAT Gateway, resolving the connection timeout.

Key Concept

VPC Networking for AWS Lambda Functions
Question 72Question

A developer has configured a microservice to perform actions in a different AWS account by assuming an IAM role. The microservice's execution role has an IAM policy that allows the sts:AssumeRole action on the target role's ARN. During execution, the microservice fails to assume the target role and receives an AccessDenied error. Which of the following is the most likely cause of this authorization failure?

Show answer & explanation

Answer: The trust policy of the target IAM role does not list the microservice's execution role ARN as a trusted principal.

Answer

The trust policy of the target IAM role does not list the microservice's execution role ARN as a trusted principal.
For an identity to successfully assume an IAM role (especially in another account), two conditions must be met: the calling identity must have permission to call sts:AssumeRole on the target role, and the target role's trust policy must list the calling identity as a trusted principal. Since the caller already has the necessary permission policy, the failure is due to the trust policy of the target IAM role missing the caller's execution role ARN as a trusted principal.

Step-by-Step Solution

1
Analyze the IAM role assumption request flow.
The caller (microservice's execution role) calls the AWS Security Token Service (STS) AssumeRole API on the target role.
This establishes that permissions are required on both the caller side (identity-based permission policy) and the callee side (resource-based trust policy).
2
Verify identity-based permissions.
The microservice's execution role already has a policy allowing sts:AssumeRole on the target role.
This rules out a permission failure on the caller's side.
3
Verify resource-based trust policy permissions.
Identify that the target role must have a trust policy granting assume-role permission to the caller principal.
Without the trust policy explicitly listing the caller's ARN, STS rejects the role assumption, causing an AccessDenied error.

Key Concept

IAM AssumeRole Trust Policies
Question 73Question

An AWS Lambda function is configured to run inside private subnets of a custom VPC. The function needs to call a public external payment gateway API and also write results to an Amazon DynamoDB table. During testing, the function successfully connects to DynamoDB via a VPC gateway endpoint, but the connection attempts to the external payment gateway API consistently fail with connection timeout errors. The Lambda function's execution role has the AWSLambdaVPCAccessExecutionRole policy attached, and its security group allows all outbound traffic. Which two actions must the developer take to resolve the external API connectivity issue?

Select all that apply

Show answer & explanation

Answer: Deploy a NAT Gateway in a public subnet of the VPC.; Add a route in the private subnets' route table that directs destination 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 internet-bound traffic (0.0.0.0/0) to the NAT Gateway.
For an AWS Lambda function inside a VPC to access the public internet, it must be associated with private subnets. The private subnets must have a route in their route table (0.0.0.0/0) pointing to a NAT Gateway that is hosted in a public subnet. The public subnet must have a route to an Internet Gateway.

Step-by-Step Solution

1
Analyze the connectivity issue.
The function can access DynamoDB (via VPC Gateway Endpoint) but times out accessing a public external API, meaning there is no route to the public internet.
Identify if the issue is a networking path limitation or resource configuration.
2
Select the correct NAT gateway deployment.
A NAT Gateway must be provisioned in a public subnet which has internet connectivity.
Lambda functions in private subnets require a NAT Gateway to route traffic to public endpoints.
3
Configure the route table for the private subnets.
A default route (0.0.0.0/0) is added pointing to the NAT Gateway.
Ensure outbound traffic from the private subnet is directed correctly to the NAT Gateway.

Key Concept

VPC Networking for AWS Lambda
Estimated Time:1m 0s
Question 74Question

A serverless order processing application utilizes an AWS Lambda function to send confirmation emails via a third-party API. The function is also configured to access an Amazon Aurora PostgreSQL database in a private subnet. The developer has configured the Lambda function to run inside the private subnets of the VPC to enable database access.

During testing, the developer observes two issues:
1. The Lambda function fails to connect to the third-party email API.
2. The database connection pool is frequently exhausted, and Lambda execution logs show connection timeouts during concurrent invocations.

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

Select all that apply

Show answer & explanation

Answer: Initialize the database connection client outside the Lambda handler function to enable connection reuse across invocations.; Provision a NAT Gateway in a public subnet, and configure the route table of the Lambda private subnets to route outbound internet traffic through the NAT Gateway.

Answer

To resolve the issues, the developer must initialize the database connection client outside the Lambda handler function to enable connection reuse, and provision a NAT Gateway in a public subnet to route outbound internet traffic from the private subnets.
The correct solution involves reusing database connections by instantiating the client outside the handler, and establishing internet connectivity for the private subnet using a NAT Gateway.

Step-by-Step Solution

1
Analyze the connectivity failure to the third-party email API.
Recognize that because the Lambda function is placed in a private subnet within a VPC to access Aurora, it lacks access to the public internet by default.
VPC-associated Lambda functions require a NAT Gateway or NAT Instance in a public subnet, with appropriate route tables, to establish outbound connections to external endpoints.
2
Diagnose the database connection pool exhaustion.
Identify that the database client initialization code is situated inside the handler function.
Placing the connection logic inside the handler function forces Lambda to create a new database connection on every single invocation, rapidly depleting the database's available connections. Placing it outside the handler allows subsequent invocations in the same execution environment to reuse the connection.
3
Apply the VPC routing and code updates.
Create the NAT Gateway in a public subnet, add a route in the private subnet route table pointing `0.0.0.0/0` traffic to the NAT Gateway, and refactor the Lambda code to instantiate the database client during the initialization phase.
This combined approach resolves both the internet egress restriction and the connection leak under load.

Key Concept

Troubleshooting VPC egress routing for Lambda functions and optimizing resource utilization through execution context reuse.
Question 75Question

A backend service uses an AWS Lambda function to process 15 MB15\text{ MB} data files uploaded to Amazon S3. During execution, the function stops processing before completing, and the Amazon CloudWatch logs report that the function reached its configured execution limit of 15 seconds15\text{ seconds}. Which action should the developer take to resolve this issue?

Show answer & explanation

Answer: Increase the timeout configuration parameter of the Lambda function.

Answer

Increase the timeout configuration parameter of the Lambda function.
The correct action is to increase the timeout configuration of the Lambda function. When a Lambda function hits its configured execution limit, AWS Lambda terminates the container. If the workload simply requires more time to run (e.g., parsing a larger file), the configuration must be updated to a higher timeout value.

Step-by-Step Solution

1
Analyze the error message from the CloudWatch logs.
The log indicates the function timed out after 15 seconds15\text{ seconds}, which is its currently configured maximum execution limit.
Understanding the failure symptom shows that the execution is aborted by AWS Lambda because the processing time exceeded the timeout configuration.
2
Evaluate the workload requirements.
Processing a 15 MB15\text{ MB} file requires more CPU time and network transfer time than the default 15 seconds15\text{ seconds} configuration allows.
Determining if the code is stuck in an infinite loop or simply needs more time to run is necessary to choose the correct remediation step.
3
Adjust the Lambda function configuration.
Increase the timeout setting (up to the maximum limit of 15 minutes15\text{ minutes}) to accommodate the processing time of larger files.
Modifying the configuration settings allows the function to execute longer without being terminated mid-process.

Key Concept

AWS Lambda execution timeout configuration
Question 76Question

A developer has configured an AWS Lambda function in AWS Account A to send messages to an Amazon Simple Queue Service (Amazon SQS) queue located in AWS Account B. During execution, the Lambda function fails with an AccessDenied error when attempting to write to the queue. Which two actions are required to resolve this authorization failure? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Add a policy to the Lambda function's IAM execution role in Account A that allows the sqs:SendMessage action on the queue in Account B.; Update the SQS queue policy in Account B to grant the Lambda function's IAM execution role in Account A permission to perform the sqs:SendMessage action.

Answer

Add a policy to the Lambda function's IAM execution role in Account A that allows the sqs:SendMessage action on the queue in Account B, and update the SQS queue policy in Account B to grant the Lambda function's IAM execution role in Account A permission to perform the sqs:SendMessage action.
The correct answers describe the two necessary steps for cross-account resource access: granting identity-based permissions to the caller's IAM execution role in the source account and granting resource-based permissions in the queue's policy in the target account to allow access from that execution role principal.

Step-by-Step Solution

1
Add the appropriate SQS permission to the Lambda execution role.
The execution role in Account A now has identity-based permission to call sqs:SendMessage on the SQS queue in Account B.
For cross-account access, the requesting identity must explicitly be allowed to perform the action in its own policy.
2
Add permissions to the SQS queue resource policy.
The SQS queue policy in Account B allows the execution role ARN from Account A to perform sqs:SendMessage.
Cross-account access requires explicit permission on the resource-based policy of the target resource to allow access from an external account.

Key Concept

Cross-account resource access requires authorization in both the caller's IAM identity-based policy and the target's resource-based policy.
Estimated Time:1m 0s
Question 77Question

An application uses an AWS Lambda function associated with private subnets of a VPC to perform write operations on an Amazon RDS PostgreSQL database. The function also needs to write tracking data to an Amazon DynamoDB table, but the write operations to DynamoDB are failing with connection timeout errors. Which two actions should a developer take to resolve this connectivity issue? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Create a Gateway VPC Endpoint for Amazon DynamoDB and associate it with the route table used by the Lambda function's subnets.; Deploy a NAT Gateway in a public subnet of the VPC, and add a route pointing to it in the private subnet's route table.

Answer

To resolve the connection timeout issue, the developer must either create a Gateway VPC Endpoint for Amazon DynamoDB and associate it with the private subnet's route table, or deploy a NAT Gateway in a public subnet and route the private subnet's internet-bound traffic through it.
The Lambda function is failing to reach the public DynamoDB endpoint because it is running inside private subnets of a VPC without access to public endpoints. The two correct options resolve this: one by establishing a Gateway VPC Endpoint that routes DynamoDB traffic internally, and the other by establishing a NAT Gateway in a public subnet to allow outbound internet access for resources in private subnets.

Step-by-Step Solution

1
Analyze the error symptom.
The Lambda function is experiencing connection timeout errors, indicating a network routing block rather than an IAM permission (AccessDenied) block.
Correctly identifying the nature of the error prevents unnecessary IAM configuration changes and focuses troubleshooting on VPC routing.
2
Evaluate the current network configuration.
The Lambda function resides in private VPC subnets to access RDS. Private subnets do not have direct access to the public internet where DynamoDB resides.
Understanding the isolation of private subnets explains why traffic cannot reach DynamoDB without a gateway helper.
3
Select valid network routing solutions.
A Gateway VPC Endpoint or a NAT Gateway allows private subnet traffic to reach DynamoDB.
A Gateway VPC Endpoint routes traffic to DynamoDB internally within the AWS network, while a NAT Gateway routes traffic to public endpoints via a public subnet.

Key Concept

VPC Networking for AWS Lambda Functions
Estimated Time:1m 30s
Question 78Question

A developer is containerizing a Python microservice that uses the AWS SDK (Boto3) to retrieve objects from an Amazon S3 bucket. During local development on a macOS host, the developer runs the application in a Docker container using Docker Desktop. The container fails to authenticate with AWS and throws a `NoCredentialsError`. The host machine's AWS CLI is configured with a default profile and a named profile `local-dev` that contains active credentials.

Which TWO actions should the developer perform to resolve this authentication failure and allow the containerized application to use the `local-dev` credentials? (Choose two.)

Select all that apply

Show answer & explanation

Answer: Mount the host machine's ~/.aws directory to the home directory of the user running inside the container (e.g., /root/.aws) and set the AWS_PROFILE environment variable to local-dev in the container runtime environment.; Pass the AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_SESSION_TOKEN environment variables from the host's active shell session directly into the container using container runtime environment flags.

Answer

Mount the host machine's credentials directory while setting the profile environment variable, or pass the active shell credential environment variables to the container at runtime.
The correct options provide valid, secure mechanisms to supply credentials to a local container without exposing secrets. Mounting the host's credential directory (~/.aws) into the container's user directory combined with the profile variable allows the SDK to resolve credentials from the configuration file. Alternatively, injecting active environment variables into the container environment allows the SDK's credential provider chain to resolve credentials from environment variables directly.

Step-by-Step Solution

1
Analyze the environment boundary.
The containerized application is isolated from the host's files and environment variables, resulting in the Boto3 SDK being unable to find any credentials in its default search path.
By default, Docker containers do not share the host's home directory or environment variables where AWS credentials are configured.
2
Evaluate configuration mounting options.
Mounting the host's ~/.aws folder to the container's user home directory makes the configuration and credentials files visible to Boto3.
Setting the AWS_PROFILE environment variable inside the container to 'local-dev' instructs Boto3 to read from the mounted named profile rather than falling back to the default profile.
3
Evaluate environment variables injection options.
Passing AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_SESSION_TOKEN environment variables into the container environment allows Boto3 to load credentials directly.
Environment variables are evaluated first in the AWS SDK default credentials provider chain, overriding other local file configuration paths.

Key Concept

AWS SDK Default Credentials Provider Chain in Container Environments
Question 79Question

A telemetry ingestion system uses an AWS Lambda function to write incoming data to an Amazon RDS PostgreSQL database instance. To optimize performance and reduce database connection overhead, the developer initializes a single database connection pool outside the Lambda handler function (in the global scope). During testing, the function runs successfully under continuous load. However, during periods of low traffic, subsequent invocations of the Lambda function fail, resulting in a `Task timed out after 15.02 seconds` error. CloudWatch logs indicate that the function hangs at the database query execution line. Which of the following is the most likely cause of this issue, and how should it be resolved?

Show answer & explanation

Answer: The database closed the idle connections during the period of inactivity, leaving stale connections in the pool. The developer should configure the connection pool to validate connection liveness before executing queries, or implement error handling to re-establish the connections.

Answer

The database closed the idle connections during the period of inactivity, leaving stale connections in the pool. The developer should configure the connection pool to validate connection liveness before executing queries, or implement error handling to re-establish the connections.
AWS Lambda reuses execution environments for subsequent warm starts, which preserves any connection pools defined in the global scope. During low-traffic periods, the database server closes these idle connections due to its configured timeout settings. The Lambda function is unaware of this and attempts to reuse the stale connection, causing the database driver to hang indefinitely until the Lambda function's timeout is reached. The appropriate fix is to validate connection liveness before borrowing a connection from the pool, or to catch the connection error and re-establish the connection.

Step-by-Step Solution

1
Analyze the symptom and error behavior
The Lambda function times out only during low traffic, and logs show it hangs at the database query execution step.
This indicates that network connectivity to the database is functional, but the connection being used is unresponsive.
2
Evaluate the initialization context
The connection pool is initialized in the global scope (outside the handler function).
The Lambda runtime maintains the global scope state across warm starts to optimize subsequent executions through context reuse.
3
Identify the root cause of connection failure
During periods of low traffic, connections remain idle longer than the database's idle timeout threshold, causing the database to silently close them.
Because the Lambda execution environment remains warm, the local pool still holds references to these terminated sockets, causing the application to hang when attempting to write data.
4
Select the correct mitigation strategy
Configure connection liveness testing (e.g., test-on-borrow) or handle connection drops by clearing and rebuilding the pool dynamically.
This guarantees that any stale connection is discarded and replaced before a query is executed, preventing the application from hanging.

Key Concept

Lambda execution context reuse and database connection pool management
Estimated Time:2m 0s
Question 80Question

A developer is troubleshooting an AWS Lambda function that processes incoming sensor telemetry. The function is configured to run inside a custom VPC and must write data to an Amazon Aurora PostgreSQL database located in a private VPC subnet. Additionally, the Lambda function must call a public HTTPS endpoint of an external device registry for validation on each invocation.

The function configuration is associated with two subnets: `subnet-0a` (a private subnet with a route to a NAT Gateway) and `subnet-0b` (a public subnet with a route to an Internet Gateway). During execution, the developer observes that connection attempts to the Aurora database succeed 100%100\% of the time. However, approximately 50%50\% of the Lambda invocations fail due to connection timeouts when the function attempts to call the external validation API.

Which of the following actions will resolve the execution timeouts while maintaining access to both the database and the external API?

Show answer & explanation

Answer: Modify the Lambda function configuration to associate only with the private subnet (subnet-0a), removing the association with the public subnet (subnet-0b).

Answer

Modify the Lambda function configuration to associate only with the private subnet (subnet-0a), removing the association with the public subnet (subnet-0b).
The correct answer is to modify the Lambda function configuration to associate only with the private subnet and remove the association with the public subnet. When a Lambda function is configured to run inside a VPC, AWS provisions Elastic Network Interfaces (ENIs) in the specified subnets. These ENIs only receive private IP addresses. If an ENI is placed in a public subnet, outbound internet traffic is directed to the Internet Gateway, which drops the traffic because it cannot map the private IP address to a public source. By removing the public subnet and using only the private subnet associated with a NAT Gateway, all internet-bound traffic goes through the NAT Gateway, which successfully translates the private IP to a public IP and routes the traffic.

Step-by-Step Solution

1
Analyze the network paths and routing configurations for the subnets associated with the Lambda function.
Lambda ENIs are distributed across both `subnet-0a` (private with NAT Gateway) and `subnet-0b` (public with Internet Gateway).
To determine why only 50%50\% of internet connections fail while all database connections succeed.
2
Evaluate the IP allocation behavior of Lambda ENIs within VPC subnets.
Lambda ENIs are assigned only private IP addresses. They do not receive public IP addresses even when deployed in a public subnet.
To verify if outbound traffic from the public subnet can traverse the Internet Gateway.
3
Identify the routing path for outbound traffic from each subnet.
Traffic from `subnet-0a` goes through the NAT Gateway (succeeds). Traffic from `subnet-0b` goes to the Internet Gateway with a private source IP, which is dropped (fails). Database traffic is internal to the VPC and succeeds from both subnets.
To locate the root cause of the intermittent 50%50\% packet drop.
4
Reconfigure the Lambda subnets to exclude the public subnet.
By associating the function only with the private subnet, all ENIs are created in `subnet-0a` and route outbound traffic through the NAT Gateway, achieving 100%100\% success.
To ensure consistent routing and resolve the connection timeouts.

Key Concept

Lambda VPC Networking and Outbound Internet Routing

Alternative Method

Instead of a NAT Gateway, you can configure an interface VPC Endpoint (AWS PrivateLink) for the external API if the third-party provider supports it or if it is an AWS service, which would keep the traffic entirely within the AWS network.
Estimated Time:3m 0s
PreviousPage 4 / 14Next