All practice questions

1542 questions

All types1,542 Multiple choice782 Multiple select746 Ordering14

An application team wants to minimize unnecessary backend processing by validating client requests directly at the API Gateway layer before invoking a downstream AWS Lambda function. The REST API must verify that client requests contain a valid JSON payload matching a specific schema, and automatically reject invalid requests with an HTTP $400$ Bad Request error. Which two configuration steps should the developer perform in Amazon API Gateway to achieve this? (Select TWO.)

Select all that apply

Create a Model in the API Gateway console that defines the JSON Schema of the expected request payload.

In the Method Request settings, select a Request Validator that validates the request body, and associate the request body content type with the created Model.

In the Integration Request settings, configure a mapping template that uses Apache Velocity Template Language (VTL) to validate the payload structure and reject invalid requests.

Create a custom Lambda Authorizer that receives the request payload, validates the schema, and returns an IAM policy with a Deny effect if required fields are missing.

In the Method Response settings, define a Gateway Response of type Bad Request Body and map it to the execution role of the backend Lambda function.

Show answer & explanation

Answer: Create a Model in the API Gateway console that defines the JSON Schema of the expected request payload.; In the Method Request settings, select a Request Validator that validates the request body, and associate the request body content type with the created Model.

Answer

To perform request validation in API Gateway, the developer must create a Model that defines the expected JSON Schema of the payload and configure the Method Request settings by selecting a Request Validator for the request body while mapping the content type to the created Model.

To perform request body validation in API Gateway before invoking a backend Lambda function, the developer must define the structure of the request payload using a Model (defined via JSON Schema) and enable request validation in the Method Request settings by selecting a Request Validator (e.g., 'Validate body') and associating the content type (e.g., 'application/json') with that Model. This ensures that malformed requests are rejected immediately at the API Gateway level, saving backend resources.

Step-by-Step Solution

Define the schema model

A Model is created in API Gateway containing the JSON Schema defining required fields and types.

API Gateway needs a schema definition to know what fields and structure to enforce on the incoming request.

Configure method request validator

The Request Validator is set to 'Validate body' in the Method Request settings.

This instructs API Gateway to intercept and inspect the incoming payload body against the specified validator rules.

Map content type to the model

The request body content type (e.g., 'application/json') is mapped to the newly created Model.

This tells API Gateway which model to use when validating payloads of that specific content type.

Key Concept

Request Validation using API Gateway Models and Request Validators

Estimated Time:2m 0s

Question 1522Question →

A developer is configuring an application running on an Amazon EC2 instance in Account B ( $444455556666$ ) to read objects from an Amazon S3 bucket named `data-bucket` located in Account A ( $111122223333$ ). The EC2 instance uses an IAM instance profile with an IAM role named `ReaderRole`.

The developer has attached the following IAM policy to `ReaderRole` in Account B:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": "arn:aws:s3:::data-bucket/*"
}
]
}

However, the application receives an AccessDenied error when attempting to download objects from `data-bucket`.

Which action should the developer take to resolve this error?

Update the trust policy of ReaderRole in Account B to allow the Amazon S3 service principal (s3.amazonaws.com) to assume the role.

Embed the AWS access key and secret access key of an IAM user from Account A directly into the application's initialization code.

Add a bucket policy to data-bucket in Account A that grants s3:GetObject permissions to the principal arn:aws:iam::444455556666:role/ReaderRole.

In Account A, add a bucket policy to data-bucket that grants s3:GetObject permissions, specifying the EC2 Instance Profile ARN as the principal.

Show answer & explanation

Answer: Add a bucket policy to data-bucket in Account A that grants s3:GetObject permissions to the principal arn:aws:iam::444455556666:role/ReaderRole.

Answer

Add a bucket policy to the S3 bucket in Account A that explicitly allows the IAM role from Account B to access the objects.

For cross-account S3 access, permissions must be granted in two locations: the identity-based IAM policy in the trusted account (Account B) must allow the action, and the resource-based S3 bucket policy in the trusting account (Account A) must trust the caller's identity. Because the identity-based policy is already correctly configured in Account B, adding the bucket policy in Account A that references the caller's IAM role ARN resolves the authorization gap.

Step-by-Step Solution

Analyze cross-account permissions requirements.

Determine that cross-account S3 access requires authorization from both the identity-based policy in the caller's account (Account B) and the resource-based policy in the resource owner's account (Account A).

By default, cross-account access is denied unless both accounts explicitly grant permission.

Draft a bucket policy for the S3 bucket in Account A.

Identify that the principal in the bucket policy must target the specific IAM role ARN (arn:aws:iam::444455556666:role/ReaderRole) rather than the instance profile or the entire account.

Specifying the IAM role ARN follows the principle of least privilege, restricting access only to the container/instance running the application.

Apply the bucket policy in Account A.

The bucket policy is applied, linking the IAM role to the S3 resource permission, resolving the AccessDenied error.

With both policies permitting the action, the IAM evaluation engine successfully authorizes the request.

Key Concept

Cross-Account IAM Resource Authorization

Question 1523Question →

A developer is designing a fleet management system that tracks delivery drone telemetry. Telemetry data is ingested into an Amazon DynamoDB table with the following schema:

* Base Table: `DroneTelemetry`
* Partition Key: `DroneID` (String)
* Sort Key: `ReadingTimestamp` (Number, Unix epoch time)
* Attributes: `BatteryLevel` (Number), `Latitude` (Number), `Longitude` (Number), `Status` (String)

The developer needs to implement the following requirements:
1. Retrieve all telemetry data for a specific drone within the last $3$ hours to plot its flight path.
2. Periodically identify drones that currently have a `Status` of `'Critical'` across the entire fleet.

Which two strategies should the developer implement to meet these requirements with optimal performance and minimum Read Capacity Unit (RCU) consumption? (Choose two.)

Select all that apply

Perform a Query operation on the base table using a key condition expression specifying the DroneID and a range condition on the ReadingTimestamp.

Create a Global Secondary Index (GSI) with Status as the partition key and ReadingTimestamp as the sort key, then perform a Query operation on the GSI.

Perform a Scan operation on the base table using a FilterExpression to retrieve telemetry records where the status is 'Critical'.

Increase the provisioned read capacity units (RCUs) on the base table to resolve ProvisionedThroughputExceededException throttling errors.

Initialize the AWS SDK client in the application by hardcoding the IAM access key ID and secret access key directly in the initialization code.

Show answer & explanation

Answer: Perform a Query operation on the base table using a key condition expression specifying the DroneID and a range condition on the ReadingTimestamp.; Create a Global Secondary Index (GSI) with Status as the partition key and ReadingTimestamp as the sort key, then perform a Query operation on the GSI.

Answer

The correct strategy is to perform a Query operation on the base table using a key condition expression specifying the DroneID and a range condition on the ReadingTimestamp to fetch the drone's telemetry, and to create a Global Secondary Index (GSI) with Status as the partition key to perform a Query operation to retrieve drones with a critical status.

The correct strategy combines a direct Query operation on the base table with a GSI-based Query. A base table Query is optimal because it specifies the exact partition key (DroneID) and filters using the sort key (ReadingTimestamp). For the status check, a GSI with Status as the partition key allows the application to query only the matching records, which eliminates the need to scan the entire dataset and saves substantial read capacity.

Step-by-Step Solution

Analyze the query requirement for drone flight paths.

The query targets a specific partition key (DroneID) and a range of the sort key (ReadingTimestamp).

Performing a Query operation on the base table directly uses the primary key attributes, which returns matches efficiently without scanning irrelevant data.

Analyze the query requirement for identifying critical drones.

Since the status attribute is not part of the primary key of the base table, a GSI is required to avoid a Scan operation.

Creating a GSI with Status as the partition key enables querying the status attribute directly, which restricts the scanned items only to those matching the partition key value.

Evaluate and eliminate incorrect approaches.

Identify Scan operations, incorrect scaling solutions, and security violations.

Scan operations read the entire table and waste read capacity. Scaling provisioned throughput does not fix hot partition throttling. Hardcoding credentials violates security best practices.

Key Concept

Optimizing read operations in DynamoDB using base table Query operations and Global Secondary Indexes (GSIs) to avoid costly Scan operations.

Question 1524Question →

A developer is designing a decoupled backend architecture for a banking application to process real-time transaction events. The application requires that transaction events are processed in the strict order they occur, and duplicate transactions must be prevented. The developer configures an Amazon SNS FIFO topic to receive transaction events. The developer wants to fan out these events to two different backend consumer services: a ledger service and a fraud detection service. To support this, the developer creates an Amazon SQS FIFO queue named LedgerQueue.fifo and an Amazon SQS Standard queue named FraudQueue. When attempting to subscribe both queues to the SNS FIFO topic, the subscription for FraudQueue fails. How can the developer resolve this subscription failure while maintaining the application's strict ordering and duplication requirements?

Convert the fraud detection queue to an Amazon SQS FIFO queue, rename it to FraudQueue.fifo, and subscribe it to the Amazon SNS FIFO topic.

Initialize the AWS SDK client used by the publisher with hardcoded AWS access keys that have IAM policy permissions to bypass Amazon SNS FIFO delivery restrictions.

Configure the standard queue's visibility timeout to 0 seconds to ensure immediate message delivery from the Amazon SNS FIFO topic.

Create an intermediate AWS Lambda function with a custom timeout that reads from the topic and writes to the standard queue, relying on Lambda execution context reuse to maintain ordering.

Show answer & explanation

Answer: Convert the fraud detection queue to an Amazon SQS FIFO queue, rename it to FraudQueue.fifo, and subscribe it to the Amazon SNS FIFO topic.

Answer

Convert the fraud detection queue to an Amazon SQS FIFO queue, rename it to FraudQueue.fifo, and subscribe it to the Amazon SNS FIFO topic.

Amazon SNS FIFO topics can only deliver messages to Amazon SQS FIFO queues to maintain end-to-end message ordering and deduplication. Therefore, the standard SQS queue must be converted to a FIFO queue with the .fifo suffix in order to successfully subscribe to the SNS FIFO topic.

Step-by-Step Solution

Analyze the subscription error between Amazon SNS FIFO and SQS queues.

Identify that the standard SQS queue (FraudQueue) is incompatible with the SNS FIFO topic.

AWS restricts SNS FIFO topic subscriptions to SQS FIFO queues only to guarantee end-to-end FIFO delivery.

Select the correct SQS queue type to support the required integration.

Determine that FraudQueue must be re-created as a FIFO queue with the .fifo suffix.

FIFO SQS queues support strict ordering and deduplication, satisfying both application requirements and SNS FIFO topic requirements.

Subscribe both FIFO SQS queues to the SNS FIFO topic.

LedgerQueue.fifo and FraudQueue.fifo are successfully subscribed to the SNS FIFO topic.

Both endpoints are now SQS FIFO queues, which is a supported configuration for SNS FIFO delivery.

Key Concept

Amazon SNS FIFO and Amazon SQS FIFO integration constraints

Estimated Time:1m 30s

Question 1525Question →

A developer is configuring an Amazon API Gateway REST API that integrates with an external HTTP backend service. The client sends a GET request containing a query string parameter named `id`. The backend service requires a POST request with a JSON payload in the format `{"customerId": "value"}`. Which configuration should the developer implement in API Gateway to meet these requirements?

Set the integration type to HTTP, set the integration method to POST, and configure an integration request mapping template for the application/json content type that extracts the ID using $input.params('id').

Set the integration type to HTTP Proxy, set the integration method to POST, and configure method request parameter mapping to forward the ID query parameter.

Set the integration type to HTTP, configure a Lambda authorizer to extract the ID query parameter, and map it to the backend request headers.

Enable CORS on the resource, set the integration type to Mock integration, and define a response mapping template to forward the request body.

Show answer & explanation

Answer: Set the integration type to HTTP, set the integration method to POST, and configure an integration request mapping template for the application/json content type that extracts the ID using $input.params('id').

Answer

To transform an incoming GET request with a query parameter into a POST request with a JSON payload for an HTTP backend, the developer must use a custom HTTP integration. Under the integration request settings, the integration method is set to POST, and a mapping template for the application/json content type is defined. The VTL utility `$input.params('id')` is used to dynamically extract the query parameter value and insert it into the JSON request body.

Step-by-Step Solution

Determine the integration type requirements based on the backend communication pattern.

Since request transformation (converting GET query parameter to POST JSON body) is required for an external HTTP endpoint, a custom HTTP integration (non-proxy) must be selected.

Proxy integrations do not support request mapping templates.

Configure the integration request settings in API Gateway.

Set the integration method to POST to match the backend expectation.

This overrides the client's HTTP method for the backend invocation.

Create a mapping template for the application/json content type under Integration Request.

Define the VTL template mapping the customer ID: `{"customerId": "$input.params('id')"}`.

The utility function extracts the parameter from the request parameters (query string, path, or headers) and outputs it into the JSON payload body.

Key Concept

API Gateway integration request mapping templates allow developers to transform incoming client requests (e.g., query strings, headers) into the specific format and HTTP method required by a backend service.

Question 1526Question →

A company is deploying a serverless microservice that requires access to an Amazon RDS database. The database credentials must be rotated every 30 days. The design requires that the microservice retrieves these credentials securely, minimizes latency during invocations, and minimizes Secrets Manager API call costs. Which two actions should be taken to meet these requirements? (Select two.)

Select all that apply

Store the database credentials in AWS Secrets Manager and configure automatic rotation.

Retrieve and cache the credentials in a global variable outside of the Lambda handler function to reuse them across subsequent warm invocations.

Store the database credentials in AWS Systems Manager Parameter Store as a Standard String parameter and enable native scheduled parameter rotation.

Call the Secrets Manager API to retrieve the credentials at the beginning of the handler function on every invocation to guarantee the most up-to-date credentials.

Hardcode the database credentials directly within the Lambda function code and restrict access to the Lambda console using an IAM trust policy.

Show answer & explanation

Answer: Store the database credentials in AWS Secrets Manager and configure automatic rotation.; Retrieve and cache the credentials in a global variable outside of the Lambda handler function to reuse them across subsequent warm invocations.

Answer

Store the database credentials in AWS Secrets Manager with automatic rotation, and retrieve and cache the credentials in a global variable outside of the Lambda handler function.

Storing the credentials in AWS Secrets Manager allows native integration with Amazon RDS for automated rotation. Retrieving the secret outside the handler function allows the Lambda execution context to cache the credentials in memory, meaning subsequent invocations (warm starts) do not need to make costly and high-latency API calls to Secrets Manager.

Step-by-Step Solution

Store the database credentials securely in AWS Secrets Manager, which natively supports automatic rotation for Amazon RDS databases using a Lambda rotation helper.

Secrets are encrypted at rest and can be rotated automatically without application downtime.

This fulfills the requirement of secure storage and automatic rotation.

In the Lambda function code, write the API call to retrieve the secret outside of the handler function, storing the result in a global or static variable.

The secret is fetched once during the function's cold start (initialization phase) and remains in memory for subsequent warm invocations.

This minimizes the number of API calls to Secrets Manager, lowering costs and reducing latency by reusing the execution context.

Key Concept

AWS Lambda execution context reuse can be leveraged to cache static configuration and credentials retrieved from AWS Secrets Manager, optimizing performance and reducing external API call costs.

Question 1527Question →

A developer is configuring a Lambda function named `DataProcessor` in AWS Account A ( $111122223333$ ) to write records to an Amazon DynamoDB table in AWS Account B ( $444455556666$ ). The Lambda function's execution role is named `LambdaExecutionRole`.

To facilitate cross-account access, the developer creates an IAM role named `CrossAccountDynamoDbRole` in Account B with a permission policy that allows writing to the DynamoDB table. The trust policy for `CrossAccountDynamoDbRole` in Account B is configured as follows:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/LambdaExecutionRole"
},
"Action": "sts:AssumeRole"
}
]
}

Which TWO additional actions must the developer take to enable the Lambda function to write to the DynamoDB table? (Select TWO.)

Select all that apply

Attach a permission policy to the Lambda execution role in Account A that allows the sts:AssumeRole action on the ARN of the IAM role in Account B.

Modify the Lambda function code to call the sts:AssumeRole API operation to retrieve temporary credentials, and use those credentials to instantiate the DynamoDB client.

Attach an identity-based policy to the Lambda execution role in Account A that allows dynamodb:PutItem on the ARN of the DynamoDB table in Account B.

Update the trust policy of the IAM role in Account B to include a statement that allows the dynamodb:PutItem action on the DynamoDB table.

Configure the Lambda function environment variables to store the access key ID and secret access key of an IAM user in Account B who has access to the DynamoDB table.

Show answer & explanation

Answer: Attach a permission policy to the Lambda execution role in Account A that allows the sts:AssumeRole action on the ARN of the IAM role in Account B.; Modify the Lambda function code to call the sts:AssumeRole API operation to retrieve temporary credentials, and use those credentials to instantiate the DynamoDB client.

Answer

Attach a permission policy to the Lambda execution role in Account A that allows the sts:AssumeRole action on the IAM role in Account B, and modify the Lambda function code to retrieve temporary credentials using the sts:AssumeRole API operation to initialize the DynamoDB client.

To successfully establish cross-account access via role assumption, a developer must configure both sides of the relationship: the trusting account (Account B) must allow the trusted entity (the Lambda execution role in Account A) to assume the role, and the trusted entity must have permissions to perform the assumption action. Finally, the application code must actively assume the role to acquire temporary credentials for accessing the target resource.

Step-by-Step Solution

Configure the identity-based policy in Account A.

Attached a policy to the Lambda execution role that grants permission to assume the cross-account role.

Before an IAM role can be assumed, the caller (Lambda execution role) must be explicitly granted the sts:AssumeRole permission in its identity-based policy.

Implement role assumption in the Lambda function code.

The Lambda function uses the AWS SDK to call the sts:AssumeRole API.

Retrieving temporary security credentials for the target role allows the application to authenticate using an identity from the target account (Account B).

Initialize the DynamoDB client with temporary credentials.

The DynamoDB client is instantiated using the temporary Access Key ID, Secret Access Key, and Session Token.

This ensures that subsequent PutItem API requests to the DynamoDB table in Account B are authorized under the permissions of the assumed role.

Key Concept

Cross-account IAM role assumption

Question 1528Question →

An AWS Lambda function in Account A ( $111111111111$ ) uses its execution role, `LambdaExecutionRole`, to retrieve parameters from AWS Systems Manager Parameter Store in Account B ( $222222222222$ ). To perform this task, the function's code executes an AWS STS `AssumeRole` API call targeting an IAM role in Account B named `ParameterReaderRole`. Although `LambdaExecutionRole` is granted permissions to perform `sts:AssumeRole` on the target resource, the invocation fails with an `AccessDenied` error. The trust policy for `ParameterReaderRole` is configured as follows:

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

How should the developer modify the trust policy of `ParameterReaderRole` to resolve this issue?

Attach a resource-based policy directly to the Systems Manager Parameter Store parameters in Account B to allow access from the Lambda execution role in Account A.

Modify the Lambda function code to use the AWS SDK to authenticate using a hardcoded AWS access key and secret access key associated with an IAM user in Account B.

Change the Principal block in the trust policy of ParameterReaderRole to reference the Lambda function's execution role ARN: "AWS": "arn:aws:iam::111111111111:role/LambdaExecutionRole".

Modify the trust policy of ParameterReaderRole to specify the Systems Manager service principal "Service": "ssm.amazonaws.com" as the allowed principal.

Show answer & explanation

Answer: Change the Principal block in the trust policy of ParameterReaderRole to reference the Lambda function's execution role ARN: "AWS": "arn:aws:iam::111111111111:role/LambdaExecutionRole".

Answer

Change the Principal block in the trust policy of ParameterReaderRole to reference the Lambda function's execution role ARN: "AWS": "arn:aws:iam::111111111111:role/LambdaExecutionRole".

The correct answer is the option proposing to change the Principal block to reference the Lambda function's execution role ARN. When a Lambda function runs code that calls `sts:AssumeRole`, the identity making the request is the function's execution role. Therefore, the trust policy of the target role in Account B must explicitly specify that execution role as a trusted principal to allow the cross-account role assumption to succeed.

Step-by-Step Solution

Identify the caller initiating the sts:AssumeRole API call.

The caller is the Lambda function running under the credentials of its execution role: arn:aws:iam::111111111111:role/LambdaExecutionRole.

When a Lambda function executes code to assume a role, the execution role is the IAM identity that performs the action.

Analyze the existing trust policy of the destination IAM role (ParameterReaderRole) in Account B.

The trust policy currently trusts the service principal 'lambda.amazonaws.com'.

This configuration allows the Lambda service itself to assume the role (e.g., as a function execution role), but does not trust the execution role of a specific function in another account.

Modify the trust policy principal to match the caller.

The principal block is updated to trust the ARN of the Lambda execution role in Account A.

To establish a cross-account trust relationship, the trust policy in the target account must explicitly list the trusted IAM entity (the execution role) from the source account as the principal.

Key Concept

Cross-Account IAM Role Assumption and Trust Policies

Estimated Time:1m 30s

Question 1529Question →

A developer is building a serverless web application using Amazon API Gateway and an AWS Lambda function with a Lambda proxy integration. During testing, client HTTP requests receive an HTTP 502 Bad Gateway error. The CloudWatch logs show that the Lambda function completed its execution successfully and returned the application data as a plain JSON string. How can the developer resolve this issue?

Configure a body mapping template in API Gateway to extract the properties from the Lambda function's plain JSON response.

Enable CORS in the API Gateway method response and define the Access-Control-Allow-Origin header value to match the client's origin.

Modify the Lambda function response to return a JSON object containing a statusCode integer and a stringified JSON payload in the body field.

Modify the Lambda function's IAM execution role to trust the API Gateway service principal to assume the role.

Show answer & explanation

Answer: Modify the Lambda function response to return a JSON object containing a statusCode integer and a stringified JSON payload in the body field.

Answer

Modify the Lambda function response to return a JSON object containing a statusCode integer and a stringified JSON payload in the body field.

The correct solution is to modify the Lambda function's response. In Amazon API Gateway Lambda proxy integration, API Gateway expects the backend Lambda function to return a response in a specific JSON format. This format must include the statusCode integer field and the response payload as a stringified JSON within the body field. If the Lambda function returns a plain JSON string directly, API Gateway cannot map it to an HTTP response and fails with a 502 Bad Gateway error.

Step-by-Step Solution

Analyze the 502 Bad Gateway error message and the successful Lambda execution logs.

Identify that the Lambda function execution succeeded but API Gateway failed to parse the returned payload.

A 502 Bad Gateway error with successful execution logs indicates that the communication between API Gateway and Lambda succeeded, but the response format from Lambda is incompatible with the integration type.

Check the integration type configured in API Gateway.

Confirm that Lambda proxy integration is enabled.

Lambda proxy integration mandates a strict response format from the backend, whereas custom integration allows returning raw payloads mapped via templates.

Update the Lambda function code to return a JSON object conforming to the proxy integration response contract.

The function now returns an object with a statusCode integer and a stringified payload in the body key.

This format allows API Gateway to successfully parse the response and construct the final HTTP response for the client.

Key Concept

API Gateway Lambda Proxy Integration Response Format

Alternative Method

If modifying the Lambda function code is not possible or desired, the developer can change the API Gateway integration type from Lambda proxy integration to Lambda custom integration. This allows API Gateway to accept the plain JSON payload and map it to an HTTP response using Integration Response mapping templates.

Estimated Time:1m 30s

Question 1530Question →

A developer is building a fleet management system that tracks real-time vehicle locations. The telemetry data is stored in an Amazon DynamoDB table with `VehicleID` as the partition key and `Timestamp` as the sort key. The developer needs to retrieve the location data for a specific vehicle over the past $24$ hours. Which of the following approaches should the developer use to retrieve this data with the lowest latency and minimal Read Capacity Unit (RCU) consumption?

Perform a Scan operation on the table with a filter expression specifying both the VehicleID and a range comparison on the Timestamp.

Configure the AWS SDK client with hardcoded access keys to scan the table and filter the location records in the application memory.

Perform a Query operation on the table with a key condition expression specifying the VehicleID and a range comparison on the Timestamp.

Create a Global Secondary Index (GSI) with Timestamp as the partition key, and perform a Query on the GSI for the specific vehicle.

Show answer & explanation

Answer: Perform a Query operation on the table with a key condition expression specifying the VehicleID and a range comparison on the Timestamp.

Answer

Perform a Query operation on the table with a key condition expression specifying the VehicleID and a range comparison on the Timestamp.

Performing a Query operation on the table with a key condition expression specifying the partition key (VehicleID) and a range comparison on the sort key (Timestamp) is the most efficient method. DynamoDB queries target only the physical partition where the specific partition key's items reside and read the sorted items sequentially, consuming Read Capacity Units (RCUs) proportional only to the returned items.

Step-by-Step Solution

Analyze the access pattern and the primary key schema.

The access pattern requires retrieving data for a specific vehicle (VehicleID) over a time range (Timestamp). The table is already structured with VehicleID as the partition key and Timestamp as the sort key.

Identifying the alignment between the query requirements and the table's key schema helps determine the most direct retrieval operation.

Compare DynamoDB read operations (Query vs. Scan).

A Query operation can target a single partition using the partition key and filter the sort key. A Scan operation examines every partition and item in the table.

Selecting Query over Scan ensures that only relevant items are read, reducing cost (RCUs) and latency.

Formulate the Query operation parameters.

Use the KeyConditionExpression parameter with VehicleID = :v_id AND #ts BETWEEN :t1 AND :t2.

This targets the correct partition and uses the sort key to return only the telemetry data from the desired 24-hour window.

Key Concept

DynamoDB Query vs Scan efficiency and primary key design.

Estimated Time:1m 30s

Question 1531Question →

A developer is configuring a serverless application where an Amazon Simple Queue Service (Amazon SQS) queue triggers an AWS Lambda function to process messages. During integration testing, the developer notices that some messages are being processed multiple times by different Lambda invocations, even though the Lambda function eventually runs successfully. The Lambda function is currently configured with an execution timeout of $15\text{ seconds}$ . Which two actions should the developer take to resolve this issue? (Select two.)

Select all that apply

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

90\text{ seconds}

Ensure the Lambda function's execution timeout is configured to be greater than the maximum time required to process the batch of messages.

Set the SQS queue's visibility timeout to a value less than

15\text{ seconds}

to ensure that failed messages are quickly retried by other invocations.

Modify the Lambda function's IAM trust policy to grant the `sqs:ReceiveMessage` and `sqs:DeleteMessage` permissions to the SQS queue service principal.

Configure the Lambda function to run inside a private VPC subnet without a NAT Gateway or VPC endpoint to restrict SQS traffic to the internal AWS network.

Show answer & explanation

Answer: Increase the visibility timeout of the Amazon SQS queue to at least $90\text{ seconds}$ .; Ensure the Lambda function's execution timeout is configured to be greater than the maximum time required to process the batch of messages.

Answer

To resolve the duplicate processing issue, the developer must increase the SQS visibility timeout to at least 6 times the Lambda function's timeout (

90\text{ seconds}

) and ensure the Lambda function's execution timeout is configured to be greater than the maximum time required to process the batch of messages.

To prevent duplicate processing of SQS messages by Lambda, the SQS queue's visibility timeout must be set to at least 6 times the Lambda function's timeout. With a

15\text{ seconds}

Lambda timeout, the visibility timeout must be at least

90\text{ seconds}

(

15 \text{ seconds} \times 6

). Additionally, the Lambda execution timeout itself must be configured to be greater than the maximum time needed to process a batch of messages to prevent premature termination.

Step-by-Step Solution

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

Identify that if the SQS visibility timeout is shorter than the Lambda execution time (or not scaled correctly), SQS will make the message visible again before the Lambda function completes, leading to duplicate invocations.

This determines why messages are being reprocessed while the original invocation is still running.

Configure the SQS visibility timeout based on the Lambda timeout.

Increase the SQS visibility timeout to at least 6 times the Lambda timeout (

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

This satisfies the AWS recommended best practice and prevents concurrent duplicate processing of messages that are still active.

Review and adjust the Lambda function timeout.

Ensure the Lambda function timeout is greater than the maximum batch processing time.

This prevents premature function termination, which would otherwise result in a failed execution and subsequent message reprocessing.

Key Concept

Integrating Amazon SQS with AWS Lambda event source mapping and managing visibility timeout and execution timeout relationships.

Question 1532Question →

A developer is building a medical monitoring application that stores periodic heart rate readings from wearable sensors in an Amazon DynamoDB table. The table uses `DeviceID` as the partition key and `Timestamp` as the sort key. The developer needs to retrieve all heart rate readings for a specific device that are greater than $100\text{ bpm}$ within a specific $24$ -hour window. Which two actions should the developer take to achieve this requirement?

Select all that apply

Perform a `Query` operation on the table using the `DeviceID` and `Timestamp` in the key condition expression.

Perform a `Scan` operation on the table, using a filter expression on `DeviceID` and `Timestamp`.

Use a `FilterExpression` in the `Query` operation to return only the records with a heart rate greater than

100\text{ bpm}

Hardcode an IAM user's access keys directly in the AWS SDK client initialization code to bypass any read authorization latency.

Perform a `Scan` operation on a newly created Global Secondary Index (GSI) that has the heart rate as the partition key.

Show answer & explanation

Answer: Perform a `Query` operation on the table using the `DeviceID` and `Timestamp` in the key condition expression.; Use a `FilterExpression` in the `Query` operation to return only the records with a heart rate greater than $100\text{ bpm}$ .

Answer

To retrieve the heart rate data efficiently, the developer should perform a `Query` operation on the table using the `DeviceID` and `Timestamp` in the key condition expression, and use a `FilterExpression` in the `Query` operation to return only the records with a heart rate greater than

100\text{ bpm}

To retrieve data efficiently from DynamoDB, the developer should use the `Query` operation. By specifying the partition key (`DeviceID`) and the sort key (`Timestamp`) in the key condition expression, the query only reads the items that belong to that specific device and time window. Because heart rate is a non-key attribute, a filter expression is used to discard items that do not meet the criteria (greater than

100\text{ bpm}

) before the response is returned to the client, which reduces network utilization.

Step-by-Step Solution

Identify the primary keys of the table.

The table has `DeviceID` as the partition key and `Timestamp` as the sort key.

This allows targeting a specific device and time range directly.

Select the appropriate API operation.

A `Query` operation is selected instead of a `Scan` operation.

A `Query` operation reads only the required partition and sort key range, while a `Scan` operation reads all items in the table, wasting Read Capacity Units (RCUs).

Determine how to filter non-key attributes.

Use a `FilterExpression` in the query to restrict the response to items where the heart rate is greater than

100\text{ bpm}

Since heart rate is not a key attribute, it cannot be in the key condition expression, but a filter expression will discard non-matching items on the server side to reduce network data transfer.

Key Concept

Optimizing DynamoDB retrieval using Query operations and FilterExpressions instead of full table Scans, and following secure credential management.

Question 1533Question →

A developer is building a high-throughput transaction ledger consumer that runs as a containerized service on Amazon ECS. The service polls messages from an Amazon SQS FIFO queue, processes the transactions, and writes the results to an external database.

The queue is configured with a default visibility timeout of $30$ seconds. Under heavy load, the database response times slow down, and processing a batch of messages can take up to $50$ seconds. Consequently, transaction records are being duplicated in the database because messages are returning to the queue before processing is complete. Additionally, the ECS task is experiencing performance degradation due to client initialization overhead.

Which of the following actions should the developer take to resolve the duplication issues and optimize client performance? (Select TWO.)

Select all that apply

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

60

seconds to ensure messages remain invisible to other consumers until processing is completed.

Instantiate the SQS client and database connection pools outside the message processing loop to reuse them across multiple execution cycles.

Decrease the default visibility timeout of the SQS queue to

10

seconds to force the consumer to poll and process the messages more frequently.

Initialize a new instance of the AWS SDK client inside the message processing loop for every message to ensure credentials are refreshed.

Migrate the consumer logic to an AWS Lambda function triggered by the SQS queue, and set the Lambda function timeout to

15

seconds.

Show answer & explanation

Answer: Increase the default visibility timeout of the SQS queue to at least $60$ seconds to ensure messages remain invisible to other consumers until processing is completed.; Instantiate the SQS client and database connection pools outside the message processing loop to reuse them across multiple execution cycles.

Answer

The correct actions are to increase the default visibility timeout of the SQS queue to at least

60

seconds and to instantiate the SQS client outside the message processing loop.

Increasing the queue's default visibility timeout to at least

60

seconds ensures the message remains hidden from other consumers while the

50

-second processing completes. Instantiating the client and connection pool outside the main processing loop allows the application to reuse connections across multiple message polls, avoiding CPU and network overhead.

Step-by-Step Solution

Analyze the cause of message duplication.

The message processing time of

50

seconds exceeds the visibility timeout of

30

seconds, meaning messages return to the queue before the worker finishes processing.

This identifies the configuration parameter that must be changed to prevent concurrent duplicate deliveries.

Calculate and apply the correct SQS visibility timeout.

Increase the visibility timeout to at least

60

seconds to exceed the maximum processing duration of

50

seconds.

The visibility timeout must be set to a value greater than the maximum expected message processing time.

Resolve the performance degradation in the ECS container.

Move the SQS client and database pool initialization outside the message processing loop.

Reusing clients across polling iterations avoids repeated connection setup and credential retrieval overhead.

Key Concept

Configuring SQS visibility timeout based on consumer processing time and optimizing AWS SDK client reuse.

Estimated Time:2m 0s

Question 1534Question →

A developer is building a movie ticket booking platform. The ticket reservation details are stored in an Amazon DynamoDB table with $ReservationID$ as the partition key. To generate real-time metrics, the application must frequently retrieve all reservations associated with a specific $ShowID$ . The query must be highly performant and cost-effective as the database grows.

Which solution meets these requirements with the lowest latency and resource consumption?

Create a Global Secondary Index (GSI) with

ShowID

as the partition key, and perform a Query operation on the GSI.

Perform a Scan operation on the base table using a FilterExpression on the

ShowID

attribute to retrieve the matching reservations.

Initialize the AWS SDK client by hardcoding temporary credentials in the application source code to perform parallel Scan operations on the base table.

Increase the provisioned Read Capacity Units (RCUs) on the base table to resolve any throughput throttling, and continue to run Scan operations to filter by

ShowID

Show answer & explanation

Answer: Create a Global Secondary Index (GSI) with $ShowID$ as the partition key, and perform a Query operation on the GSI.

Answer

Create a Global Secondary Index (GSI) with the target query attribute as the partition key, and perform a Query operation on the GSI.

Creating a Global Secondary Index (GSI) with the target query attribute as the partition key is the correct approach. It enables the application to use the Query API instead of Scan, ensuring that only the items associated with the target attribute value are read. This consumes minimal Read Capacity Units (RCUs) and executes with low, predictable latency regardless of the table's overall size.

Step-by-Step Solution

Analyze the table primary key structure and retrieval requirements.

The base table uses a simple primary key with a partition key of

ReservationID

. Querying by

ShowID

directly on the base table is not supported because

ShowID

is a non-key attribute.

DynamoDB only allows Query operations on the primary key attributes (partition key and optional sort key) of the table or an index.

Determine the optimal indexing strategy for the non-key attribute.

Create a Global Secondary Index (GSI) with

ShowID

as the partition key.

Since the partition key of the base table is different from the search attribute, a GSI is required to allow direct querying on the new partition key.

Select the correct API operation for retrieval.

Perform a Query operation against the GSI using the specific

ShowID

A Query operation is much more efficient than a Scan because it only reads the items matching the key value, reducing Read Capacity Unit (RCU) consumption and latency.

Key Concept

Using Global Secondary Indexes (GSIs) and Query operations to efficiently retrieve data from Amazon DynamoDB tables on non-primary key attributes.

Question 1535Question →

A developer is configuring an AWS Lambda function to process messages from an Amazon SQS standard queue. The Lambda function has a timeout of 20 seconds. The SQS queue has a default visibility timeout of 20 seconds. During testing, the developer observes that some messages are processed more than once by different Lambda executions. Which configuration change should the developer make to resolve this issue?

Increase the default visibility timeout of the SQS queue to 120 seconds.

Increase the Lambda function timeout to 120 seconds.

Decrease the default visibility timeout of the SQS queue to 5 seconds.

Initialize the SQS client inside the Lambda function handler and hardcode temporary credentials to delete messages before processing.

Show answer & explanation

Answer: Increase the default visibility timeout of the SQS queue to 120 seconds.

Answer

Increase the default visibility timeout of the SQS queue to 120 seconds.

Increasing the SQS visibility timeout to 120 seconds (which is 6 times the Lambda function's timeout of 20 seconds) ensures that a message remains invisible to other consumers long enough for the Lambda function to finish processing, retry if necessary, and delete the message from the queue.

Step-by-Step Solution

Identify the current configuration of the Lambda function and the SQS queue.

Lambda timeout is 20 seconds, and SQS visibility timeout is 20 seconds.

To determine the relationship between function execution duration and message visibility.

Apply AWS best practices for SQS queue visibility timeout when integrated with Lambda.

The SQS visibility timeout should be set to at least 6 times the Lambda function timeout.

This recommendation prevents duplicate message processing by ensuring that if a batch fails or is retried, the message does not become visible to other instances too quickly.

Calculate the recommended visibility timeout and update the queue configuration.

20 seconds multiplied by 6 equals 120 seconds.

To set the queue's default visibility timeout to 120 seconds.

Key Concept

Integrating Amazon SQS with AWS Lambda requires setting the queue's visibility timeout to at least 6 times the Lambda function's timeout to prevent duplicate processing.

Estimated Time:1m 30s

Question 1536Question →

An e-commerce order fulfillment system uses an Amazon SQS standard queue to trigger an AWS Lambda function for invoice generation. The third-party invoicing API can take up to $25$ seconds to respond, so the developer configures the Lambda function's timeout to $30$ seconds. During high-traffic periods, customers report receiving duplicate invoices for a single order. Additionally, the developer must ensure that the Lambda function can authenticate with SQS securely without storing access keys in the codebase.

Which two actions should the developer take to resolve the duplication issue and ensure secure credentials management? (Select TWO.)

Select all that apply

Increase the visibility timeout of the SQS queue to at least

180

seconds to prevent message processing overlaps.

Assign an IAM execution role with permissions to access the SQS queue to the Lambda function, and initialize the SQS SDK client without specifying hardcoded credentials.

Decrease the SQS queue's visibility timeout to

15

seconds to allow other Lambda instances to immediately retry failed invoice generations.

Store the AWS access keys in the Lambda function's environment variables and initialize the SQS SDK client by passing these keys directly into the client constructor.

Extend the Lambda function's timeout to

10

minutes and cache the processed invoice IDs in a global variable in the execution context to prevent duplicates.

Show answer & explanation

Answer: Increase the visibility timeout of the SQS queue to at least $180$ seconds to prevent message processing overlaps.; Assign an IAM execution role with permissions to access the SQS queue to the Lambda function, and initialize the SQS SDK client without specifying hardcoded credentials.

Answer

The developer should increase the SQS queue's visibility timeout to at least 180 seconds and configure the Lambda function with an IAM execution role, initializing the SDK client without hardcoded credentials.

Increasing the SQS visibility timeout to at least

180

seconds (six times the Lambda function's timeout of

30

seconds) ensures that the message remains hidden from other consumers for the entire duration of the Lambda function's execution. Using an IAM execution role assigned to the Lambda function allows the AWS SDK to retrieve temporary security credentials from the instance metadata service automatically, preventing credentials from being hardcoded.

Step-by-Step Solution

Determine the optimal SQS visibility timeout to prevent duplicates during processing.

Identify that the SQS visibility timeout must be set to at least

6

times the Lambda function timeout plus any batch window. Since the Lambda timeout is

30

seconds, the visibility timeout should be at least

180

seconds.

This prevents messages from becoming visible to other pollers while the Lambda function is still executing.

Implement a secure credential management strategy for the SQS consumer client.

Configure an IAM role with SQS access permissions and assign it as the Lambda function's execution role, then instantiate the SQS client using default credentials.

This eliminates the need to store AWS access keys in the codebase or configuration environment variables.

Key Concept

Configuring SQS visibility timeout to match Lambda execution limits and implementing IAM-based SDK authentication.

Estimated Time:1m 30s

Question 1537Question →

A developer is implementing a web analytics pipeline where user interaction events are sent to a custom Amazon EventBridge event bus. The developer configures an EventBridge rule to route these events to an Amazon Kinesis Data Stream for real-time analytics. The stream has 10 active shards to handle the expected volume. The developer wants to ensure that all events for any given user session are processed in chronological order by the consumer application, while also distributing the write load evenly across all shards to prevent write throttling.

Which target configuration in EventBridge meets these requirements?

Configure the target with a PartitionKeyPath pointing to the user session ID field ($.detail.sessionId) in the event payload.

Configure the target with a PartitionKeyPath pointing to the event type field ($.detail.eventType) in the event payload.

Omit the PartitionKeyPath setting, allowing EventBridge to assign a static default string as the partition key.

Route the events to an AWS Lambda function that writes to the stream using the current timestamp as the partition key.

Show answer & explanation

Answer: Configure the target with a PartitionKeyPath pointing to the user session ID field ($.detail.sessionId) in the event payload.

Answer

Configure the target with a PartitionKeyPath pointing to the user session ID field ($.detail.sessionId) in the event payload.

Configuring the EventBridge target with a PartitionKeyPath pointing to the user session ID ensures that all events from a given session share the same partition key. Kinesis Data Streams maps records with the same partition key to the same shard, preserving the order of execution. Because there are many unique user sessions (high cardinality), the traffic is distributed evenly across all shards, preventing throttling.

Step-by-Step Solution

Analyze the requirements for stream ingestion and processing.

The solution requires two things: preserving chronological ordering of events within a user session, and distributing events evenly across Kinesis shards.

Understanding these twin constraints is necessary to choose the correct partition key configuration.

Determine the mechanism for ordering and load distribution in Kinesis Data Streams.

Kinesis determines the destination shard by hashing the partition key of each record. Records with the same partition key are sent to the same shard and processed in order.

This shows that the partition key must represent the logical grouping that requires ordering (the user session).

Evaluate the cardinality of potential partition keys.

A high-cardinality key like user session ID distributes events evenly across 10 shards. A low-cardinality key or static string causes hot shards. A timestamp fails to guarantee that all events of a specific session land on the same shard.

Selecting the high-cardinality session ID via PartitionKeyPath meets both the scaling and ordering requirements.

Key Concept

Selecting high-entropy partition keys using PartitionKeyPath on EventBridge targets is crucial for Kinesis Data Streams to achieve balanced shard utilization and maintain order.

Question 1538Question →

A developer is building a collaborative project management application where team members can assign tasks to each other. The application stores task details in an Amazon DynamoDB table with ` $ProjectID$ ` as the partition key and ` $TaskID$ ` as the sort key.

The developer needs to implement two requirements:
1. Retrieve all tasks within a specific project that have a status of 'In Progress'.
2. Retrieve all tasks across all projects assigned to a specific team member using their ` $AssigneeID$ `.

Additionally, the developer must initialize the AWS SDK DynamoDB client securely within an AWS Lambda function that executes these queries.

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

Select all that apply

Perform a `Query` operation on the base table using a `KeyConditionExpression` on `

ProjectID

` and a `FilterExpression` on the status attribute.

Create a Global Secondary Index (GSI) with `

AssigneeID

` as the partition key, and perform a `Query` operation against this GSI.

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

AssigneeID

` to retrieve tasks assigned to a specific team member.

Pass hardcoded IAM User access keys and secret access keys directly to the SDK DynamoDB client constructor within the Lambda function code.

Create a Local Secondary Index (LSI) with `

AssigneeID

` as the partition key to retrieve tasks across all projects.

Show answer & explanation

Answer: Perform a `Query` operation on the base table using a `KeyConditionExpression` on ` $ProjectID$ ` and a `FilterExpression` on the status attribute.; Create a Global Secondary Index (GSI) with ` $AssigneeID$ ` as the partition key, and perform a `Query` operation against this GSI.

Answer

To retrieve tasks by project status, perform a Query operation on the base table with a KeyConditionExpression on the partition key and a FilterExpression on the status. To retrieve tasks by assignee across all projects, create a Global Secondary Index with the assignee ID as the partition key and perform a Query against it. Additionally, initialize the DynamoDB client without hardcoding credentials, allowing it to use the Lambda execution role.

The correct approach is to use a Query operation on the base table for project-specific queries since the partition key is known. To query across different partitions (projects) by assignee, a Global Secondary Index is required because it allows a different partition key. For security, the DynamoDB client should rely on the Lambda function's IAM execution role instead of hardcoded credentials.

Step-by-Step Solution

Analyze the query pattern for project tasks.

Querying by `

ProjectID

` uses the base table's partition key, so a `Query` operation with a `KeyConditionExpression` and a `FilterExpression` is the most efficient choice.

This avoids scanning the entire table and limits the read to a single partition.

Analyze the query pattern for assignee tasks across all projects.

Since the query needs to span multiple projects (different partition keys), a Global Secondary Index (GSI) must be created with `

AssigneeID

` as the partition key.

Local Secondary Indexes require the same partition key as the base table, so only a GSI can query across different projects.

Evaluate security best practices for SDK client initialization in AWS Lambda.

Initialize the client using the default credential provider chain, which automatically uses the Lambda function's IAM execution role.

This avoids hardcoding credentials in the code, which is a severe security vulnerability.

Key Concept

Data Store Operations with Amazon DynamoDB

Question 1539Question →

A developer is building a serverless application where an AWS Lambda function writes records to a legacy on-premises database. The database can handle a maximum of 10 concurrent connections. During peak hours, traffic spikes cause the Lambda function to scale, which overloads the database and causes connections to drop. How should the developer configure the Lambda function to prevent overloading the database?

Initialize the database client inside the handler method and set the Lambda execution timeout to 10 seconds.

Set the reserved concurrency limit of the Lambda function to 10.

Place an Amazon SQS queue in front of the Lambda function and set the SQS visibility timeout to 10 seconds.

Deploy the Lambda function inside a private VPC subnet and configure the security group to limit the outbound concurrent connections to 10.

Show answer & explanation

Answer: Set the reserved concurrency limit of the Lambda function to 10.

Answer

Configure the Lambda function's reserved concurrency limit to 10 to restrict the maximum number of concurrent execution environments.

Setting the reserved concurrency limit of the Lambda function to 10 restricts the maximum number of concurrent instances of the function that can execute at any given time. This effectively limits the maximum number of concurrent database connections to 10, preventing the function from overloading the legacy database.

Step-by-Step Solution

Analyze the database's connection limits and Lambda's automatic scaling behavior.

Identify that rapid horizontal scaling of Lambda functions during traffic spikes results in too many concurrent connection attempts, crashing the database.

By default, Lambda scales to meet demand, which can easily exceed the limits of downstream traditional or legacy systems.

Evaluate configuration methods to control the concurrent scaling of AWS Lambda.

Determine that reserved concurrency caps the maximum number of concurrent instances allowed to execute for a specific function.

Restricting the concurrent executions directly limits the maximum number of active database connections the function can establish.

Apply the configuration changes by setting the reserved concurrency limit to 10.

The Lambda function is constrained to a maximum of 10 concurrent executions, ensuring the legacy database connections never exceed 10.

This implements a hard limit on scale-out concurrency to match the downstream dependency constraints.

Key Concept

Managing AWS Lambda scaling and database connection pooling using Reserved Concurrency.

Alternative Method

Use Amazon RDS Proxy to manage and pool database connections, allowing the Lambda function to scale without overloading the database.

Estimated Time:1m 30s

Question 1540Question →

A developer is configuring an AWS Lambda function to process real-time financial transactions from an Amazon Kinesis Data Stream. The function must validate each transaction by invoking a third-party payment gateway's public API endpoint over the internet, and then save the transaction status to an Amazon RDS database located in a private subnet of a VPC.

The developer configures the Lambda function to run inside the same VPC and private subnet as the RDS database. During testing, the developer observes that the Lambda function is successfully triggered by the Kinesis stream but consistently times out after 15 seconds without executing the API call or database write.

What is the root cause of this issue and how should it be resolved?

The execution role associated with the Lambda function is missing a trust policy allowing Kinesis to assume it. The developer must add the kinesis.amazonaws.com service principal to the trust relationship policy of the role.

The Lambda function's timeout is set to a default value that is too low to process the batch size. The developer must increase the Lambda function execution timeout to 15 minutes to allow the function to complete the API calls and database writes.

The Lambda function lacks internet access because it is deployed in a private VPC subnet without a route to a NAT Gateway. The developer must add a NAT Gateway in a public subnet and update the private subnet's route table to route external traffic to the NAT Gateway.

The producer application is using a partition key with low entropy to write records to Kinesis. The developer must change the partition key to a high-entropy value like a transaction ID to distribute the load and prevent Lambda execution bottlenecks.

Show answer & explanation

Answer: The Lambda function lacks internet access because it is deployed in a private VPC subnet without a route to a NAT Gateway. The developer must add a NAT Gateway in a public subnet and update the private subnet's route table to route external traffic to the NAT Gateway.

Answer

When a Lambda function is configured to connect to a VPC, it is assigned an ENI to communicate with VPC resources like RDS. However, it loses its default public internet connectivity. To allow the function to call a third-party API over the internet, a NAT Gateway must be configured in a public subnet of the VPC, and the route table of the Lambda function's private subnet must have a route pointing 0.0.0.0/0 to the NAT Gateway.

Step-by-Step Solution

Analyze the network path required for the Lambda function's operations.

The Lambda function needs to connect to a private RDS instance (inside the VPC) and a public third-party API endpoint (outside the VPC).

This establishes that both internal VPC and external internet routing are required.

Determine the impact of VPC configuration on Lambda outbound connectivity.

Configuring a Lambda function to run inside a private VPC subnet enables local VPC access but removes default outbound internet access.

By default, Lambda functions in a VPC do not have access to the internet unless routed through a NAT Gateway or using VPC endpoints.

Select the correct networking components to enable outbound internet access from the private subnet.

A NAT Gateway must be deployed in a public subnet, and the route table for the private subnet must route 0.0.0.0/0 traffic to the NAT Gateway.

This allows the Lambda function to reach the public third-party API endpoint while retaining its connection to the private RDS database.

Key Concept

VPC Networking for AWS Lambda when consuming Kinesis Data Streams and accessing public APIs

PreviousPage 77 / 78Next

All practice questions

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Alternative Method

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

Alternative Method

Answer