Tüm alıştırma soruları

1542 soru

Tüm türler1,542 Çoktan seçmeli782 Çoklu seçim746 Sıralama14

A ticketing application named 'PassGate' registers entry scans for high-attendance live events in a DynamoDB table. The table is configured with provisioned write capacity units (WCUs). During the check-in period for a major music concert, the application frequently encounters ProvisionedThroughputExceededException errors. CloudWatch metrics indicate that the table's overall consumed WCUs are well below the provisioned threshold, but a single partition key matching the popular EventID is receiving almost all the write traffic. Which action should the developer take to resolve this throttling issue?

Increase the visibility timeout of the SQS queue that feeds ticket scans to the application, allowing more time for message processing.

Modify the table schema to append a random or calculated suffix to the EventID partition key, distributing the write load across multiple partitions.

Transition the application's read operations to perform a full Scan with filter expressions instead of using Query operations.

Embed static access keys in the application's SDK client configuration to ensure client credentials do not expire during peak throughput.

Cevabı ve açıklamayı göster

Cevap: Modify the table schema to append a random or calculated suffix to the EventID partition key, distributing the write load across multiple partitions.

Cevap

Modify the table schema to append a random or calculated suffix to the EventID partition key, distributing the write load across multiple partitions.

The correct answer is correct because salting the partition key (appending a random or calculated suffix) distributes the writes across multiple logical partitions, preventing a hot key issue on a single partition.

Adım Adım Çözüm

Identify the root cause of the DynamoDB throttling.

CloudWatch metrics show a disproportionate amount of write traffic targeting a single partition key value (the EventID).

A single hot partition key limits throughput to the maximum capacity of a single partition, regardless of the overall table provisioning.

Evaluate partition key design options to distribute write load.

Adding a random or calculated suffix (salting) to the partition key distributes the write load across multiple partitions.

This prevents write traffic from bottlenecking on a single physical partition by spreading it across multiple sub-partitions.

Anahtar Kavram

DynamoDB Partition Key Salting and Hot Partitions

Tahmini Süre:1m 30s

Soru 1462Soru →

A developer is building a video translation system where upload events are published to an Amazon SNS topic. The events are fanned out to an Amazon SQS standard queue, which is polled by a fleet of containerized workers running on Amazon ECS. Each video transcription job takes between 2 to 5 minutes to complete, but occasionally takes up to 12 minutes for larger files. The default visibility timeout of the SQS queue is configured to 3 minutes. During peak traffic, the developer notices that some videos are transcribed multiple times, resulting in duplicate outputs and wasted compute resources.

Which of the following actions should the developer take to resolve this issue in a secure and efficient manner?

Decrease the default visibility timeout of the SQS queue to 1 minute to ensure that if a worker fails, another worker immediately picks up the message.

Migrate the transcription logic to an AWS Lambda function with the default timeout, relying on the reuse of the execution context to persist and complete the 12-minute transcription across separate invocations.

Modify the ECS worker to call the ChangeMessageVisibility API to dynamically extend the message's visibility timeout during transcription, or increase the default visibility timeout of the SQS queue to 13 minutes.

Implement a helper in the ECS worker to call the ChangeMessageVisibility API, initializing the SQS client by hardcoding an IAM User's access key and secret access key in the source code to ensure proper authentication.

Cevabı ve açıklamayı göster

Cevap: Modify the ECS worker to call the ChangeMessageVisibility API to dynamically extend the message's visibility timeout during transcription, or increase the default visibility timeout of the SQS queue to 13 minutes.

Cevap

The correct option addresses the duplicate processing issue by ensuring that the SQS message remains invisible to other consumers while it is actively being processed. By increasing the SQS queue's default visibility timeout to 13 minutes (which is greater than the maximum potential processing time of 12 minutes) or using the ChangeMessageVisibility API to dynamically extend the visibility of a message while work is in progress, the developer prevents other workers from picking up and processing the same message concurrently.

Adım Adım Çözüm

Analyze the processing times of the ECS worker against the default SQS visibility timeout.

The workers take up to 12 minutes, which is significantly longer than the 3-minute default visibility timeout.

When the processing duration exceeds the visibility timeout, SQS makes the message visible again, allowing other workers to retrieve it and cause duplicate execution.

Determine the correct visibility timeout configuration or runtime API calls needed.

The queue's default visibility timeout should be set to at least 13 minutes, or the worker must issue ChangeMessageVisibility calls to heart-beat the message's visibility during execution.

This ensures that no other consumer can pull the message until the current worker either finishes and deletes it, or fails and lets the timeout expire.

Evaluate the security and architecture constraints of the proposed solutions.

The SDK client should be configured to run securely using IAM Task Roles instead of hardcoded credentials, and avoiding incorrect assumptions about Lambda default timeouts and execution context reuse.

Using IAM roles for tasks ensures secure access to SQS, and avoiding default Lambda timeouts prevents runtime failures.

Anahtar Kavram

Understanding and configuring SQS visibility timeouts to align with application processing times, and dynamically managing message visibility using the AWS SDK.

Soru 1463Soru →

A high-volume logistics application uses an Amazon SQS standard queue to buffer telemetry data from delivery vehicles. A worker process retrieves messages, performs geo-spatial calculations, and writes the results to an Amazon DynamoDB table. The worker process takes up to $75$ seconds to process each telemetry payload. Currently, the SQS queue visibility timeout is set to $60$ seconds. Consequently, some telemetry records are duplicated in the DynamoDB table. Which two actions should the developer take to resolve this duplication issue?

Geçerli olan tümünü seçin

Increase the default visibility timeout of the SQS queue to

120

seconds, ensuring it exceeds the maximum message processing time.

Modify the worker application to call the ChangeMessageVisibility API operation to extend the visibility timeout of a message during active processing.

Decrease the default visibility timeout of the SQS queue to

15

seconds so that failed messages are retried faster.

Hardcode static AWS access keys inside the worker application's SDK client configuration to reduce latency during credential resolution.

Store the application's processing state in static, global variables to maximize execution context reuse, assuming the connection pool persists without cleanup.

Cevabı ve açıklamayı göster

Cevap: Increase the default visibility timeout of the SQS queue to $120$ seconds, ensuring it exceeds the maximum message processing time.; Modify the worker application to call the ChangeMessageVisibility API operation to extend the visibility timeout of a message during active processing.

Cevap

To resolve the duplication, the developer must increase the SQS queue's default visibility timeout to

120

seconds and modify the worker application to dynamically call the ChangeMessageVisibility API operation during active processing.

The issue is caused by the message processing duration (

75

seconds) exceeding the default visibility timeout (

60

seconds). Increasing the visibility timeout to

120

seconds ensures the message is not visible to other consumers during the transaction. Additionally, invoking the ChangeMessageVisibility API dynamically extends the timeout for slow messages, handling unexpected latency without permanently locking failed messages.

Adım Adım Çözüm

Identify the cause of message reprocessing.

The worker processing time of

75

seconds exceeds the

60

-second queue visibility timeout.

When the visibility timeout expires before the worker deletes the message, the message becomes visible to other workers, causing duplicate processing.

Adjust the default visibility timeout configuration.

Increase the default visibility timeout of the queue to a value greater than the maximum processing time, such as

120

seconds.

This guarantees that under typical conditions, the message remains invisible to other workers while being processed.

Implement a dynamic extension safeguard.

Integrate the ChangeMessageVisibility API call within the application code to request additional visibility time if processing is still ongoing.

This prevents reprocessing in scenarios where transient issues (like database latency) extend the processing time beyond the new static limit.

Anahtar Kavram

Amazon SQS Message Visibility Timeout management and dynamic visibility updates using ChangeMessageVisibility.

Soru 1464Soru →

A developer is configuring a Python application running on an Amazon EC2 instance in Account A ( $111122223333$ ) to retrieve files from a private Amazon S3 bucket located in Account B ( $444455556666$ ). The EC2 instance is associated with an IAM instance profile utilizing a role named `EC2ReadRole`. The developer creates an IAM role named `S3AccessRole` in Account B. However, when the application attempts to assume the role, it receives an `AccessDenied` error. The trust policy for `S3AccessRole` in Account B is currently configured as follows:

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

Which two configuration steps must the developer perform to successfully establish this cross-account access and resolve the `AccessDenied` error? (Select TWO.)

Geçerli olan tümünü seçin

Attach a permissions policy to the EC2ReadRole in Account A that allows the sts:AssumeRole action on the arn:aws:iam::444455556666:role/S3AccessRole resource.

Attach a permissions policy to the S3AccessRole in Account B that allows the s3:GetObject action on the target S3 bucket resource.

Add a statement to the S3AccessRole permissions policy in Account B that allows the sts:AssumeRole action targeting the EC2ReadRole ARN.

Modify the S3 bucket policy in Account B to allow the sts:AssumeRole action for the EC2ReadRole ARN.

Modify the application code on the EC2 instance to initialize the AWS SDK client with hardcoded AWS access keys of an IAM user from Account B.

Cevabı ve açıklamayı göster

Cevap: Attach a permissions policy to the EC2ReadRole in Account A that allows the sts:AssumeRole action on the arn:aws:iam::444455556666:role/S3AccessRole resource.; Attach a permissions policy to the S3AccessRole in Account B that allows the s3:GetObject action on the target S3 bucket resource.

Cevap

To resolve the AccessDenied error and secure cross-account access, the developer must attach a permissions policy to the EC2 role in Account A allowing it to perform the assume-role action on the target role, and attach an IAM policy to the target role in Account B allowing it to perform the S3 read operations.

For cross-account access via role assumption, both sides of the trust and delegation must be configured. The EC2ReadRole in Account A must have permissions to execute the sts:AssumeRole call (as described in the option to attach a permissions policy to EC2ReadRole), and the assumed S3AccessRole in Account B must be authorized to perform the s3:GetObject operations on the target bucket (as described in the option to attach an S3 permissions policy to S3AccessRole).

Adım Adım Çözüm

Analyze the IAM trust relationship configuration.

The trust policy on S3AccessRole in Account B correctly lists Account A's EC2ReadRole as a trusted entity that can execute sts:AssumeRole.

This verifies that Account B permits Account A to assume the role, meaning the issue must lie in Account A's permissions or the permissions of the assumed role.

Configure the permissions of the calling identity in Account A.

Attach an IAM policy to EC2ReadRole in Account A allowing the sts:AssumeRole action on the ARN of S3AccessRole.

By default, IAM roles have no outbound permissions unless explicitly granted. The EC2 role must have permission to request the STS token.

Configure the permissions of the assumed role in Account B.

Attach an IAM policy to S3AccessRole in Account B allowing the s3:GetObject action on the target S3 bucket.

When the application assumes S3AccessRole, it inherits only the permissions assigned to that role. It must be explicitly permitted to perform S3 actions on the target resource.

Anahtar Kavram

IAM trust policies define which entities are trusted to assume a role, while permissions policies define what actions the assumed role can perform on AWS resources.

Soru 1465Soru →

A logistics company uses a serverless transit-tracking application where fleet sensors publish real-time telemetry updates. The updates are published to an Amazon SNS FIFO topic, which is subscribed to by multiple Amazon SQS FIFO queues. An AWS Lambda function is configured to process messages from one of the SQS FIFO queues. The Lambda function has a timeout of 1 minute, while the SQS queue's visibility timeout is set to 30 seconds. During peak hours, the developer notices that some telemetry updates are processed out of order, and the database shows duplicate entries for the same sensor updates. Which two of the following configuration changes will resolve the out-of-order execution issues and prevent duplicate message processing?

Geçerli olan tümünü seçin

Set the MessageGroupId to the unique sensor identifier when publishing messages to the SNS FIFO topic to maintain message ordering per sensor.

Increase the SQS queue's visibility timeout to at least 6 minutes (6 times the Lambda function's timeout) to ensure messages are not reprocessed while the Lambda function is executing.

Decrease the Lambda function's execution timeout to 15 seconds to ensure it always completes before the SQS queue's visibility timeout, without modifying the queue configuration.

Migrate the message ingestion to an Amazon Kinesis Data Stream and set a static partition key for all fleet sensors to guarantee ordered processing.

Configure the AWS SDK client inside the Lambda function using hardcoded IAM user credentials to bypass IAM role assumption and decrease connection initiation latency.

Cevabı ve açıklamayı göster

Cevap: Set the MessageGroupId to the unique sensor identifier when publishing messages to the SNS FIFO topic to maintain message ordering per sensor.; Increase the SQS queue's visibility timeout to at least 6 minutes (6 times the Lambda function's timeout) to ensure messages are not reprocessed while the Lambda function is executing.

Cevap

The correct configuration changes are to set the MessageGroupId to the unique sensor identifier when publishing to the SNS FIFO topic, and to increase the SQS queue's visibility timeout to at least 6 minutes.

To fix the out-of-order execution, setting the MessageGroupId to the unique sensor identifier ensures that SQS FIFO groups related messages and processes them sequentially. To prevent duplicate executions, increasing the SQS queue's visibility timeout to at least 6 times the Lambda function timeout ensures the message remains invisible to other polling invocations while the current execution runs.

Adım Adım Çözüm

Analyze the out-of-order execution issue for fleet sensors.

SQS FIFO queues guarantee ordering only within the scope of a specific MessageGroupId.

By grouping messages using the unique sensor identifier as the MessageGroupId, SQS guarantees that messages for a particular sensor are processed sequentially.

Analyze the duplicate entry issue caused by the Lambda consumer.

The Lambda function timeout is 60 seconds, which exceeds the SQS queue's visibility timeout of 30 seconds.

If a Lambda function takes longer than 30 seconds to process a message, the SQS visibility timeout expires, and the message returns to the queue. Other concurrent Lambda invocations can then poll and process the same message, causing duplicates.

Apply the AWS recommended formula for SQS visibility timeout when integrating with Lambda.

Increase the visibility timeout of the SQS queue to at least 6 times the Lambda function timeout (6 * 60 seconds = 360 seconds or 6 minutes).

This buffer prevents message reprocessing during long-running batch processing or execution retries.

Anahtar Kavram

FIFO Queue Ordering and Lambda Visibility Timeout Alignment

Tahmini Süre:3m 0s

Soru 1466Soru →

A logistics delivery application named 'RouteSpeed' updates the status of packages in an Amazon DynamoDB table. The partition key is `delivery_date` and the sort key is `package_id`. During peak delivery hours on a major shopping holiday, the application encounters a high rate of `ProvisionedThroughputExceededException` errors. CloudWatch metrics indicate that the table's total consumed write capacity is well below the provisioned write capacity.

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

Geçerli olan tümünü seçin

Redesign the partition key schema by appending a randomized or calculated suffix to the partition key value to distribute write requests across multiple physical partitions.

Configure the AWS SDK client in the application to use exponential backoff and jitter for retrying throttled write requests.

Increase the visibility timeout of the Amazon SQS queue that feeds the status updates to the application to prevent messages from returning to the queue.

Modify the application to perform a Scan operation instead of a Query operation to verify if a package partition has available capacity before writing.

Hardcode static AWS credentials in the application's SDK client configuration to bypass the default credential provider chain and reduce connection establishment latency.

Cevabı ve açıklamayı göster

Cevap: Redesign the partition key schema by appending a randomized or calculated suffix to the partition key value to distribute write requests across multiple physical partitions.; Configure the AWS SDK client in the application to use exponential backoff and jitter for retrying throttled write requests.

Cevap

To resolve the throttling issues, the developer must redesign the partition key schema by appending a suffix to distribute writes and configure the AWS SDK client to use exponential backoff and jitter for retrying failed requests.

Redesigning the partition key by appending a randomized or calculated suffix distributes the write load across multiple physical partitions, preventing a single partition from becoming hot. Additionally, configuring the SDK client with exponential backoff and jitter ensures that the application handles temporary write spikes gracefully by retrying requests after increasing delays.

Adım Adım Çözüm

Analyze the table configuration and error patterns to identify if writes are unevenly distributed.

Discovered that the partition key is a date string with low entropy, causing all writes on a given day to target a single physical partition.

Uneven distribution causes single partition limits to be reached even when the overall table capacity is sufficient.

Introduce a calculated suffix (e.g.,

1

N

) to the partition key value during write operations.

Writes are evenly distributed across multiple physical partitions.

Increasing the entropy of the partition key balances the write load.

Configure the AWS SDK client to implement exponential backoff with randomized delay (jitter).

Transient throttling errors are automatically retried with spacing to prevent request collisions.

Ensures the application handles transient load spikes without failing operations.

Anahtar Kavram

Mitigating DynamoDB hot partitions and using SDK retry strategies

Soru 1467Soru →

A corporate employee portal retrieves employee profile metadata and contact information from an Amazon DynamoDB table. During morning log-in hours, the portal experiences high read latency and ProvisionedThroughputExceededException errors when fetching the profiles of executive leadership, which are queried by many employees. The developer wants to reduce read latency to sub-millisecond levels for these read-heavy requests without modifying the existing query API calls. Which of the following actions should the developer take? (Select two.)

Geçerli olan tümünü seçin

Deploy an Amazon DynamoDB Accelerator (DAX) cluster to cache the read requests.

Configure the application to use the DAX client SDK to direct read requests to the DAX cluster.

Increase the provisioned Read Capacity Units (RCUs) on the DynamoDB table to absorb the peak traffic.

Modify the application to perform Scan operations with Parallel Scan enabled to retrieve employee profiles.

Configure the DAX client by hardcoding the developer's AWS Access Key ID and Secret Access Key directly in the application code.

Cevabı ve açıklamayı göster

Cevap: Deploy an Amazon DynamoDB Accelerator (DAX) cluster to cache the read requests.; Configure the application to use the DAX client SDK to direct read requests to the DAX cluster.

Cevap

To optimize read performance and achieve sub-millisecond latency for the hot partition requests without changing query logic, the developer should deploy an Amazon DynamoDB Accelerator (DAX) cluster and update the application to use the DAX client SDK.

The correct options recommend deploying a DynamoDB Accelerator (DAX) cluster and using the DAX client SDK. DAX acts as a managed write-through cache that provides sub-millisecond response times for read-intensive workloads. Because the DAX SDK is API-compatible with DynamoDB, it serves as a drop-in replacement that requires no changes to the existing query API calls.

Adım Adım Çözüm

Identify the performance requirement and constraint.

The application requires sub-millisecond latency for frequently accessed items (hot partitions) without changing the query API calls.

This points to a caching layer that is compatible with the DynamoDB API.

Select the appropriate caching solution.

Amazon DynamoDB Accelerator (DAX) is selected as it is a fully managed, highly available, in-memory cache specifically designed for DynamoDB that delivers sub-millisecond latency.

DAX API is compatible with DynamoDB, meaning the application query logic does not need to change.

Configure the application to communicate with the cache.

The application code is updated to use the DAX client SDK instead of the standard AWS SDK for DynamoDB.

The DAX SDK acts as a drop-in replacement, directing requests to the DAX cluster endpoint and falling back to DynamoDB if necessary.

Anahtar Kavram

Amazon DynamoDB Accelerator (DAX) is an in-memory write-through cache designed to reduce read response times to sub-milliseconds for DynamoDB tables, requiring minimal application modifications via the DAX client SDK.

Soru 1468Soru →

A developer is building a serverless application where Amazon API Gateway routes requests to a backend AWS Lambda function using a Lambda custom (non-proxy) integration. The Lambda function expects a JSON input containing a key named `userId`. However, client requests send this identifier as a query string parameter named `uid` (for example, `/users?uid=123`). How should the developer configure API Gateway to map the incoming query string parameter to the JSON payload format required by the Lambda function?

In the Integration Request settings, add a mapping template for the application/json content type, and define the template body as {"userId": "$input.params('uid')"}.

In the Integration Request settings, enable Lambda Proxy Integration to automatically convert the uid query string parameter into a root-level key named userId in the event payload.

Configure a custom Lambda Authorizer for the Method Request to extract the uid query string parameter and rewrite it into the request body before the integration takes place.

Enable Lambda Proxy Integration and configure a Method Response mapping template to transform the request payload format before it is forwarded to the backend Lambda function.

Cevabı ve açıklamayı göster

Cevap: In the Integration Request settings, add a mapping template for the application/json content type, and define the template body as {"userId": "$input.params('uid')"}.

Cevap

In the Integration Request settings, add a mapping template for the application/json content type, and define the template body as {"userId": "$input.params('uid')"}.

In a Lambda custom (non-proxy) integration, request mapping templates are used to shape the payload before it is dispatched to the backend. Using Velocity Template Language (VTL), the developer can define a template for the application/json content type. The expression $input.params('uid') extracts the value of the uid query string parameter and maps it to the userId key in the constructed JSON payload.

Adım Adım Çözüm

Identify the integration type and requirements

The API uses a Lambda custom (non-proxy) integration and needs to transform a query parameter into a custom JSON payload structure.

Custom integrations require developers to explicitly define the mapping of request components using mapping templates.

Select the correct location for request transformation

The transformation must happen during the Integration Request phase before the request is sent to the backend.

This is where API Gateway processes mapping templates for outgoing backend payloads.

Construct the mapping template using Velocity Template Language (VTL)

Create an application/json template containing the structure {"userId": "$input.params('uid')"}.

The $input.params() function retrieves the value of parameters from headers, path variables, or query strings.

Anahtar Kavram

Request transformation using API Gateway mapping templates for Lambda custom integrations.

Soru 1469Soru →

An enterprise IoT application ingests high-frequency status updates from millions of devices into an Amazon Kinesis Data Stream. The updates are currently partitioned by `DeviceType`. A small number of popular device types account for $90\%$ of the total data volume, leading to frequent `ProvisionedThroughputExceededException` errors.

A developer must design a solution that achieves the following:
1. Resolves the stream throttling issue without unnecessary cost.
2. Archives all raw status updates to an Amazon S3 bucket.
3. Routes only the status updates containing a `severity` of `"FATAL"` to Amazon EventBridge for incident management.

Which approach meets these requirements with the lowest latency and operational overhead?

Modify the stream producers to use a composite partition key such as `DeviceType_DeviceID`. Attach an Amazon Kinesis Data Firehose delivery stream to archive all events to Amazon S3. Configure an AWS Lambda function with an Event Source Mapping to consume from Kinesis. Modify the Lambda execution role's trust policy to trust `kinesis.amazonaws.com` instead of `lambda.amazonaws.com` so that the stream can invoke the Lambda function to forward `"FATAL"` events to EventBridge.

Keep `DeviceType` as the partition key and increase the Kinesis Data Stream shard count to 50 to scale out processing. Write an AWS Lambda function to poll the stream using the AWS SDK, filter for `"FATAL"` events, and publish them to Amazon EventBridge while also writing every incoming event to the Amazon S3 bucket.

Modify the stream producers to use a composite partition key such as `DeviceType_DeviceID`. Attach an Amazon Kinesis Data Firehose delivery stream directly to the Kinesis Data Stream to deliver all events to Amazon S3. Configure an AWS Lambda function with an Event Source Mapping that includes a filter pattern for `{"data": {"severity": ["FATAL"]}}` to publish only those critical events to Amazon EventBridge.

Use a composite partition key of `DeviceType_DeviceID`. Configure Kinesis Data Firehose to archive all events to Amazon S3. Deploy an AWS Lambda function to consume from the stream, but place it inside a private VPC subnet with no NAT Gateway or VPC Endpoint to ensure maximum security, and write a script inside the Lambda function to filter and send `"FATAL"` events to EventBridge.

Cevabı ve açıklamayı göster

Cevap: Modify the stream producers to use a composite partition key such as `DeviceType_DeviceID`. Attach an Amazon Kinesis Data Firehose delivery stream directly to the Kinesis Data Stream to deliver all events to Amazon S3. Configure an AWS Lambda function with an Event Source Mapping that includes a filter pattern for `{"data": {"severity": ["FATAL"]}}` to publish only those critical events to Amazon EventBridge.

Cevap

The correct option is the one proposing a composite partition key to resolve throttling, Kinesis Data Firehose to archive all events to S3, and a Lambda function with Event Source Mapping filters to forward FATAL events to EventBridge.

The correct answer proposes using a composite partition key (`DeviceType_DeviceID`) to resolve the hot shard issue. It uses Kinesis Data Firehose to efficiently write all events to Amazon S3 without code maintenance. It then routes only `"FATAL"` events to EventBridge by configuring an Event Source Mapping filter on the Lambda function, minimizing Lambda invocations and execution cost.

Adım Adım Çözüm

Analyze the cause of stream throttling.

The current partition key (DeviceType) has low entropy, causing most traffic to go to a single shard (hot shard). A high-entropy key like DeviceType_DeviceID is needed to distribute the load across all shards.

Kinesis routes records to shards based on the hash of the partition key.

Identify the most efficient archiving strategy.

Kinesis Data Firehose can consume directly from the stream and batch-write to S3 with zero code.

This minimizes operational overhead and avoids writing custom Lambda archiving code.

Identify the most cost-effective routing strategy to EventBridge.

Use Lambda with Event Source Mapping filters set to severity: ['FATAL'].

Filters prevent Lambda from being invoked for non-matching records, reducing costs and code complexity.

Anahtar Kavram

Selecting high-entropy partition keys for Kinesis Data Streams and utilizing Event Source Mapping filters to cost-effectively process stream subsets.

Soru 1470Soru →

A developer is migrating a REST API to Amazon API Gateway with an AWS Lambda backend. The developer configures a new resource with a GET method using Lambda Proxy Integration. The Lambda function executes successfully and returns the following JSON response:

{
"status": "success",
"data": {
"items": ["item1", "item2"]
}
}

However, when testing the API endpoint via a client, the client receives an HTTP $502$ Bad Gateway status code. The CloudWatch execution logs for API Gateway show: "Malformed Lambda proxy response" and "Execution failed due to configuration error". What is the root cause of this error, and how should the developer resolve it?

The Lambda function must return a JSON response with specific keys, including `statusCode` and a stringified `body`. The developer should modify the Lambda function to return a structured payload containing these fields.

The developer must configure an Integration Response mapping template in API Gateway to map the custom JSON properties returned by the Lambda function to the HTTP Method Response.

The developer must configure a Lambda Authorizer to validate the format of the payload returned by the Lambda function before it is passed to the Method Response.

The Lambda function returned a JSON object, but Lambda Proxy Integration requires the response body to be base64-encoded. The developer should modify the function to set `isBase64Encoded` to `true` and base64-encode the JSON payload.

Cevabı ve açıklamayı göster

Cevap: The Lambda function must return a JSON response with specific keys, including `statusCode` and a stringified `body`. The developer should modify the Lambda function to return a structured payload containing these fields.

Cevap

In Lambda Proxy Integration, API Gateway does not map or modify the response from the backend. The backend Lambda function is directly responsible for generating the complete HTTP response. It must return a JSON object with a specific structure: an integer `statusCode`, and a stringified JSON `body`. The custom JSON object returned by the function does not match this structure, which triggers a

502

Bad Gateway error in API Gateway.

Adım Adım Çözüm

Analyze the integration type configured in API Gateway.

The method is configured with Lambda Proxy Integration.

This determines whether API Gateway expects the backend to return an HTTP-compatible response structure directly or if it will use mapping templates to build the response.

Inspect the response returned by the Lambda function.

The Lambda function returns a custom JSON object `{"status": "success", "data": ...}`.

To verify if the response conforms to the contract required by Lambda Proxy Integration.

Identify the mismatch between the returned response and the proxy contract.

The returned response is missing mandatory fields such as `statusCode` and a stringified `body`.

Under Lambda Proxy Integration, API Gateway requires a specific JSON response format containing `statusCode` (an integer) and `body` (a string). Since the returned object is arbitrary, API Gateway cannot parse it and fails with a

502

Bad Gateway error.

Formulate the resolution strategy.

Modify the Lambda function's code to return the required JSON structure.

Since mapping templates (Integration Responses) are bypassed in proxy integration, the change must be made directly within the backend Lambda function.

Anahtar Kavram

Lambda Proxy Integration Response Format

Tahmini Süre:2m 0s

Soru 1471Soru →

An application publishes transaction events to an Amazon SNS topic. A fraud detection service is subscribed to this topic and must only process transactions where the amount is greater than $10,000. Other subscribers must continue to receive all transaction events. Which configuration should the developer implement to meet this requirement?

Define a subscription filter policy on the Amazon SNS subscription for the fraud detection service to match the transaction amount attribute.

Decrease the Amazon SQS visibility timeout of the queue subscribed to the topic to zero so that the fraud detection service can quickly skip unwanted messages.

Initialize the AWS SDK client with hardcoded credentials in the fraud detection application to dynamically create new temporary SQS queues for filtering.

Configure the AWS Lambda function consuming the messages to use a short timeout limit so that executions handling transactions under $10,000 terminate early.

Cevabı ve açıklamayı göster

Cevap: Define a subscription filter policy on the Amazon SNS subscription for the fraud detection service to match the transaction amount attribute.

Cevap

Define a subscription filter policy on the Amazon SNS subscription for the fraud detection service to match the transaction amount attribute.

Defining a subscription filter policy on the Amazon SNS subscription is the standard, native method to filter messages. When a message is published to the topic with matching attributes, SNS automatically filters it so that only the interested subscription receives it, while other subscriptions are unaffected.

Adım Adım Çözüm

Identify the requirement to send a subset of messages from an Amazon SNS topic to a specific subscriber without affecting other subscribers.

The requirement calls for selective message delivery (filtering) at the subscription level.

This allows different subscribers to consume only the messages they need.

Evaluate the native filtering capabilities of Amazon SNS.

Amazon SNS supports Subscription Filter Policies, which evaluate message attributes to determine if a message should be delivered to that subscription.

This offloads filtering logic from the application code to the managed service.

Anahtar Kavram

Amazon SNS Subscription Filter Policies allow subscribers to filter messages based on message attributes so that they only receive messages of interest.

Soru 1472Soru →

A developer is designing a transaction auditing system for a financial application. The system must process transaction events generated by upstream microservices. The requirements are:

* Transaction events for each customer must be processed in the exact order they occurred.
* Events must be sent to two different backend systems: an auditing service and a compliance archiving service.
* If the auditing service fails to process an event after three attempts, that specific event must be isolated for manual inspection without permanently blocking subsequent transactions for that customer.
* Duplicate events sent within 5 minutes must be automatically discarded.

Which combination of actions should the developer take to meet these requirements? (Select TWO.)

Geçerli olan tümünü seçin

Publish transaction events to an Amazon SNS FIFO topic, and subscribe two Amazon SQS FIFO queues to the topic, with one queue for each backend service.

Configure a Dead-Letter Queue (DLQ) on the auditing SQS FIFO queue with a redrive policy where maxReceiveCount is set to 3, and ensure a unique Transaction ID is used as the Message Deduplication ID.

Publish transaction events to an Amazon SNS Standard topic, and subscribe two Amazon SQS FIFO queues to the topic using the customer ID as the Message Group ID.

Configure a Dead-Letter Queue (DLQ) directly on the Amazon SNS FIFO topic with a redrive policy, and set the visibility timeout on the SQS queues to at least three times the processing time.

Use Amazon Kinesis Data Streams with two shards to split the traffic between the auditing and compliance services, and configure the partition key based on the customer ID.

Cevabı ve açıklamayı göster

Cevap: Publish transaction events to an Amazon SNS FIFO topic, and subscribe two Amazon SQS FIFO queues to the topic, with one queue for each backend service.; Configure a Dead-Letter Queue (DLQ) on the auditing SQS FIFO queue with a redrive policy where maxReceiveCount is set to 3, and ensure a unique Transaction ID is used as the Message Deduplication ID.

Cevap

Publish transaction events to an Amazon SNS FIFO topic, subscribe two Amazon SQS FIFO queues to the topic (one for each backend service), configure a Dead-Letter Queue (DLQ) on the auditing SQS FIFO queue with a maxReceiveCount of 3, and use the Transaction ID as the Message Deduplication ID.

To satisfy both ordering and fan-out, the developer must publish messages to an Amazon SNS FIFO topic and subscribe two separate Amazon SQS FIFO queues (one for each microservice). To handle failures without permanently blocking the message group, a Dead-Letter Queue (DLQ) must be configured on the SQS FIFO queue with a redrive policy (maxReceiveCount of 3). Furthermore, to deduplicate events within a 5-minute window, the Transaction ID should be passed as the Message Deduplication ID to the SQS FIFO queues.

Adım Adım Çözüm

Select the messaging pattern for fan-out and ordering.

Combine Amazon SNS FIFO and Amazon SQS FIFO queues.

SNS FIFO allows message fan-out to multiple endpoints, while SQS FIFO queues preserve the strict order of messages within each Message Group ID (using Customer ID).

Address the 5-minute deduplication requirement.

Use the Transaction ID as the Message Deduplication ID.

Amazon SQS FIFO queues natively deduplicate messages within a 5-minute window based on the Message Deduplication ID.

Address the message-level failure isolation requirement.

Configure a Dead-Letter Queue (DLQ) on the SQS FIFO queue with a maxReceiveCount of 3.

When a consumer fails to process a message, returning it to the queue blocks the Message Group. Setting a DLQ with a maxReceiveCount of 3 moves the message to the DLQ after 3 failed attempts, which unblocks the rest of the customer's messages.

Anahtar Kavram

Decoupled fan-out architectures requiring strict message ordering, deduplication, and fault isolation using Amazon SNS FIFO topics and Amazon SQS FIFO queues.

Tahmini Süre:2m 30s

Soru 1473Soru →

A developer is configuring an AWS Lambda function in Account A ( $111122223333$ ) to be triggered by an Amazon SQS queue named `IncomingQueue` in Account B ( $444455556666$ ). The developer wants to establish this cross-account event source mapping under the principle of least privilege, without requiring the Lambda function to perform an explicit assume-role operation in its application code.

The developer has already attached the following permissions policy to the Lambda function's execution role, `LambdaQueueReaderRole`, in Account A:

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

Which of the following configurations are also required to establish this cross-account trigger? (Select TWO.)

Geçerli olan tümünü seçin

Configure the resource-based policy of the SQS queue in Account B to allow the `sqs:ReceiveMessage`, `sqs:DeleteMessage`, and `sqs:GetQueueAttributes` actions for the principal `arn:aws:iam::111122223333:role/LambdaQueueReaderRole`.

Configure the trust policy of `LambdaQueueReaderRole` in Account A to allow the SQS service principal (`sqs.amazonaws.com`) to perform the `sts:AssumeRole` action.

Configure the trust policy of `LambdaQueueReaderRole` in Account A to allow the Lambda service principal (`lambda.amazonaws.com`) to perform the `sts:AssumeRole` action.

Store static AWS access keys for an IAM User created in Account B within the Lambda function's environment variables and initialize the SQS client with them.

Modify the resource-based policy of the SQS queue in Account B to allow the `sts:AssumeRole` action for the `LambdaQueueReaderRole` principal.

Cevabı ve açıklamayı göster

Cevap: Configure the resource-based policy of the SQS queue in Account B to allow the `sqs:ReceiveMessage`, `sqs:DeleteMessage`, and `sqs:GetQueueAttributes` actions for the principal `arn:aws:iam::111122223333:role/LambdaQueueReaderRole`.; Configure the trust policy of `LambdaQueueReaderRole` in Account A to allow the Lambda service principal (`lambda.amazonaws.com`) to perform the `sts:AssumeRole` action.

Cevap

Configure the resource-based policy of the SQS queue in Account B to grant access to the Lambda execution role, and configure the trust policy of the Lambda execution role in Account A to allow the Lambda service principal to assume the role.

For cross-account SQS integration to work with AWS Lambda, the Lambda execution role in Account A must have the necessary IAM permissions to call SQS APIs, and its trust policy must allow `lambda.amazonaws.com` to assume it. Additionally, since the queue resides in Account B, the SQS queue's resource policy must permit the Lambda execution role ARN from Account A to execute the required consumer actions.

Adım Adım Çözüm

Verify Lambda Execution Role Trust Policy

The trust policy of the execution role in Account A must trust the service principal `lambda.amazonaws.com` so that the Lambda service has permission to assume the role.

Without this trust relationship, AWS Lambda cannot assume the execution role to poll the queue or invoke the function.

Configure the Cross-Account Resource Policy

Update the SQS queue policy in Account B to allow the Lambda execution role's ARN in Account A to perform the `sqs:ReceiveMessage`, `sqs:DeleteMessage`, and `sqs:GetQueueAttributes` actions.

For cross-account access to SQS, both the identity-based policy in the source account and the resource-based policy in the destination account must explicitly allow the actions.

Anahtar Kavram

Cross-account SQS integration requires both an identity-based policy in the source account and a resource-based policy in the destination account, alongside a properly configured trust relationship for the executing service principal.

Tahmini Süre:2m 0s

Soru 1474Soru →

A developer is configuring an Amazon API Gateway REST API that integrates with an HTTP backend service hosted on-premises. The backend service requires a custom HTTP header named X-Backend-Token, which must be populated using the client's identity identifier found in the $context.authorizer.claims.sub context variable. Additionally, the backend service returns responses in XML format, but the API client expects a JSON payload.

Which two configurations must the developer implement in API Gateway to achieve this integration? (Select TWO.)

Geçerli olan tümünü seçin

Set the integration type of the API method to HTTP Integration.

In the Integration Request settings, map the X-Backend-Token header to context.authorizer.claims.sub.

Set the integration type of the API method to HTTP Proxy Integration.

In the Method Request settings, map the X-Backend-Token header to context.authorizer.claims.sub.

In the Integration Response settings, define a mapping template for the application/xml content type to transform the XML payload to JSON.

Cevabı ve açıklamayı göster

Cevap: Set the integration type of the API method to HTTP Integration.; In the Integration Request settings, map the X-Backend-Token header to context.authorizer.claims.sub.

Cevap

Configure the integration type as HTTP Integration (non-proxy) and map the X-Backend-Token header to context.authorizer.claims.sub under the Integration Request settings.

The correct options are configuring the integration type to HTTP Integration and mapping the custom header under the Integration Request settings. HTTP Integration (custom integration) must be used instead of HTTP Proxy Integration because proxy integrations pass the client request and backend response directly through without modification, preventing any header injection or payload transformation. Mapping context variables to backend headers is configured in the Integration Request settings, which define the backend request structure.

Adım Adım Çözüm

Determine the appropriate integration type for custom request modification and response payload transformation.

Choose HTTP Integration instead of HTTP Proxy Integration, because proxy integrations do not allow request parameter mapping or response body transformations.

An HTTP Integration (custom integration) allows API Gateway to map variables and apply mapping templates to request and response payloads.

Configure the custom header mapping from the authorizer context to the backend integration request.

In the API Gateway Console or CloudFormation, navigate to the Integration Request and add a header parameter mapping setting the name to 'X-Backend-Token' and the value to 'context.authorizer.claims.sub'.

The Integration Request is where incoming request data (and context variables) are mapped to backend integration arguments.

Configure the response transformation from XML to JSON.

Define a mapping template for the 'application/json' Content-Type in the Integration Response section to parse the XML from the backend and generate JSON.

API Gateway matches response mapping templates based on the client-side content type (Method Response), not the backend response content type.

Anahtar Kavram

Custom HTTP integration allows request header injection from context variables and response mapping templates for data transformation, which is not possible with proxy integrations.

Soru 1475Soru →

A retail company processes high-frequency transactional data using an Amazon Kinesis Data Stream with $5$ shards. An AWS Lambda function acts as the consumer to process and save these records to Amazon DynamoDB. The records contain a `transactionId` (UUID), `customerId` (high entropy), `region` (only $5$ unique values), and `transactionType` (e.g., 'purchase', 'refund'). The developer notices frequent `ProvisionedThroughputExceededException` errors on one specific shard, while the other shards are underutilized. Additionally, the developer needs to route all 'refund' transactions with an amount greater than $\$1000$ to a third-party audit API using Amazon EventBridge.

Which two configurations should the developer implement to resolve the throttling issue and route the required transaction events?

Geçerli olan tümünü seçin

Configure the Kinesis producer to use `customerId` or `transactionId` as the partition key, and implement exponential backoff with jitter on write failures.

Create an EventBridge rule on the default event bus with an event pattern filtering for `transactionType` matching 'refund' and `amount` greater than

1000

, and set the target as an EventBridge API Destination.

Configure the producer to use the `region` attribute as the partition key for the Kinesis Data Stream.

Increase the Lambda function's maximum execution timeout to

15

minutes and set the batch size to

10000

Deploy the consumer Lambda function in a private VPC subnet without a NAT Gateway or VPC endpoints.

Cevabı ve açıklamayı göster

Cevap: Configure the Kinesis producer to use `customerId` or `transactionId` as the partition key, and implement exponential backoff with jitter on write failures.; Create an EventBridge rule on the default event bus with an event pattern filtering for `transactionType` matching 'refund' and `amount` greater than $1000$ , and set the target as an EventBridge API Destination.

Cevap

To resolve the throttling issue, configure the Kinesis producer to use a high-entropy key like customerId or transactionId for even distribution and use exponential backoff on writes. To route the high-value refunds, create an EventBridge rule with the appropriate event pattern targeting an EventBridge API Destination.

The throttling issue is resolved by utilizing high-cardinality partition keys like customerId or transactionId, which spreads requests evenly across all shards. Implementing exponential backoff with jitter helps manage transient peaks. The event routing is resolved by configuring an EventBridge rule matching the specific JSON criteria and routing the matching events to the third-party API through an EventBridge API Destination, which manages the API integration natively.

Adım Adım Çözüm

Analyze partition key cardinality

Using geographic region (low cardinality) leads to concentrated throughput on specific shards (hot shards). Select transactionId or customerId for high cardinality.

Kinesis distributes data to shards based on the MD5 hash of the partition key; higher entropy ensures uniform distribution.

Configure write retry policy

Incorporate exponential backoff with jitter on the producer side.

This mitigates transient provisioning failures without overwhelming the stream during spikes.

Set up EventBridge event routing

Define an EventBridge rule that filters transaction events based on type and amount.

Allows declarative routing of matching event payloads without writing custom sorting logic in Lambda.

Configure target endpoint routing

Define an API Destination for EventBridge pointing to the third-party endpoint.

API Destinations manage authorization, rate limits, and invocation mechanisms out-of-the-box.

Anahtar Kavram

Partition key design in Amazon Kinesis Data Streams and EventBridge routing patterns with API Destinations

Alternatif Yöntem

Instead of custom consumer code in Lambda, EventBridge Pipes could be configured to read directly from the Kinesis stream and route filtered events to the API Destination.

Tahmini Süre:3m 0s

Soru 1476Soru →

A developer is building a video transcoding application where upload events are published to an Amazon SNS topic and fanned out to an Amazon SQS standard queue. A fleet of worker instances running on Amazon EC2 polls this queue to retrieve and transcode the videos. The transcoding process takes between $2$ to $8$ minutes per video depending on its file size. The SQS queue has a default Visibility Timeout of $5$ minutes. The developer notices that during peak usage, larger videos that require more than $5$ minutes to process are being transcoded multiple times by different EC2 worker instances.

Which of the following actions will resolve this issue and prevent duplicate transcoding?

Configure the Amazon EC2 workers to poll the queue using long polling by setting the `WaitTimeSeconds` parameter of the `ReceiveMessage` API call to

20

seconds to keep the connection open during transcoding.

Configure the worker application to call the `ChangeMessageVisibility` API to extend the message visibility timeout during transcoding, or increase the queue's default Visibility Timeout to

10

minutes.

Convert the SQS standard queue to an SQS FIFO queue and enable content-based deduplication to prevent duplicate message retrieval by other worker instances.

Decrease the default Visibility Timeout of the SQS queue to

1

minute so that if a worker fails, other worker instances can immediately pick up the message and restart the transcoding.

Cevabı ve açıklamayı göster

Cevap: Configure the worker application to call the `ChangeMessageVisibility` API to extend the message visibility timeout during transcoding, or increase the queue's default Visibility Timeout to $10$ minutes.

Cevap

Configure the worker application to call the `ChangeMessageVisibility` API to extend the message visibility timeout during transcoding, or increase the queue's default Visibility Timeout to

10

minutes.

The correct answer is to extend the visibility timeout dynamically using the `ChangeMessageVisibility` API or increase the default Visibility Timeout to a value larger than the maximum processing time. This ensures that the message remains hidden from other workers until the transcoding process completes and the worker deletes the message.

Adım Adım Çözüm

Identify the mismatch between the maximum processing time (

8

minutes) and the queue's default Visibility Timeout (

5

minutes).

Realize that any message taking longer than

5

minutes will become visible again while still being processed.

This explains why other workers are picking up and reprocessing the same video messages.

Evaluate SQS mechanisms for managing message visibility during processing.

Determine that increasing the default Visibility Timeout to

10

minutes (greater than the

8\text{-minute}

maximum) or calling `ChangeMessageVisibility` dynamically will keep the message hidden.

Keeping the message hidden prevents other consumers from retrieving it concurrently.

Ensure the worker deletes the message from the queue only after successful processing.

The message is safely deleted from the queue upon completion, avoiding reprocessing.

If processing fails, the message will eventually become visible again after the visibility timeout expires.

Anahtar Kavram

SQS Visibility Timeout Management

Alternatif Yöntem

Instead of a static visibility timeout, you can run a background thread within the worker that periodically calls `ChangeMessageVisibility` to heartbeat and extend the timeout in increments as long as the process is alive.

Tahmini Süre:2m 0s

Soru 1477Soru →

A developer is implementing a background worker service on Amazon ECS to process batch image transcoding jobs from an Amazon SQS standard queue. The average transcoding job takes 4 minutes to complete, but high-resolution images can take up to 12 minutes. During testing, the developer observes that multiple ECS tasks are frequently processing the same image file concurrently, resulting in duplicate outputs and wasted compute resources. Additionally, corrupt image files that fail to transcode are retried indefinitely, blocking the queue.

Which combination of configuration steps should the developer perform to resolve these issues? (Select TWO.)

Geçerli olan tümünü seçin

Set the SQS queue's visibility timeout to a value greater than 12 minutes to allow sufficient time for transcoding to complete before the message is made available to other tasks.

Configure a dead-letter queue (DLQ) and specify a redrive policy on the source SQS queue with a maxReceiveCount value to capture and isolate consistently failing messages.

Decrease the visibility timeout of the SQS queue to 1 minute to ensure that if a task fails, another ECS task can immediately pick up the message.

Increase the task execution timeout of the ECS tasks to 15 minutes without modifying the SQS queue parameters.

Hardcode an IAM user access key and secret key inside the worker application code when constructing the AWS SDK client to reduce the latency of credentials retrieval.

Cevabı ve açıklamayı göster

Cevap: Set the SQS queue's visibility timeout to a value greater than 12 minutes to allow sufficient time for transcoding to complete before the message is made available to other tasks.; Configure a dead-letter queue (DLQ) and specify a redrive policy on the source SQS queue with a maxReceiveCount value to capture and isolate consistently failing messages.

Cevap

Configure the SQS queue's visibility timeout to a value greater than 12 minutes, and set up a dead-letter queue (DLQ) with a redrive policy and maxReceiveCount on the main SQS queue to isolate failing messages.

To prevent duplicate processing of messages, the SQS visibility timeout must be configured to be longer than the maximum time it takes for a consumer to process a message. This ensures the message remains hidden from other consumers while the active worker completes its task. To handle corrupt or unprocessable messages that would otherwise block the queue indefinitely, a dead-letter queue (DLQ) must be configured with a redrive policy using a maxReceiveCount parameter to isolate these messages after a set number of failures.

Adım Adım Çözüm

Analyze the cause of duplicate processing.

The average processing time is 4 minutes, and the maximum is 12 minutes. If the queue's visibility timeout is set to a value less than the processing time, another consumer will poll the queue and retrieve the same message before the active task can finish and delete it.

To prevent duplicate processing, the visibility timeout of the queue must exceed the maximum time the consumer takes to process the message.

Address the infinite retry issue for corrupt or invalid messages.

Corrupt messages that consistently fail to process should be sent to a dead-letter queue (DLQ) rather than returning to the main queue indefinitely.

Using a redrive policy with a set maxReceiveCount separates failing messages from successful ones, preventing queue blockages.

Anahtar Kavram

SQS visibility timeout configuration and dead-letter queue (DLQ) handling

Soru 1478Soru →

A video streaming platform uses an Amazon DynamoDB table to track user watch progress. The table uses $UserId$ as the partition key and $VideoId$ as the sort key. As users watch videos, progress updates create a high volume of writes. The platform's homepage must display the $10$ most recently watched videos that are currently in progress (where the $CompletionStatus$ attribute is $IN\_PROGRESS$ ), sorted by the $LastUpdated$ timestamp in descending order.

To minimize both Read Capacity Unit (RCU) consumption and query latency, which strategy should the developer implement?

Perform a Scan operation on the base table using a FilterExpression of UserId = :uid AND CompletionStatus = :status, then sort and limit the results to the top 10 items in the application memory.

Create a Global Secondary Index (GSI) with UserId as the partition key and InProgressTimestamp as the sort key. Populate InProgressTimestamp with the update timestamp only when CompletionStatus is IN_PROGRESS, otherwise leave it blank. Query this GSI with ScanIndexForward set to false.

Query the base table using only UserId as the partition key to retrieve all watch history records, and if the client encounters a ProvisionedThroughputExceededException due to high read volume, scale up the provisioned Read Capacity Units (RCUs) for the base table.

Initialize the AWS SDK client inside the application by hardcoding temporary IAM Access Key ID and Secret Access Key credentials directly in the constructor, then run a Scan query on the base table to filter the records.

Cevabı ve açıklamayı göster

Cevap: Create a Global Secondary Index (GSI) with UserId as the partition key and InProgressTimestamp as the sort key. Populate InProgressTimestamp with the update timestamp only when CompletionStatus is IN_PROGRESS, otherwise leave it blank. Query this GSI with ScanIndexForward set to false.

Cevap

Create a Global Secondary Index (GSI) with UserId as the partition key and InProgressTimestamp as the sort key. Only populate InProgressTimestamp when CompletionStatus is IN_PROGRESS, and query the GSI with ScanIndexForward set to false.

The correct strategy is to create a sparse Global Secondary Index (GSI). By defining a sort key (such as InProgressTimestamp) that is only populated when the status is 'IN_PROGRESS', DynamoDB will automatically exclude all 'COMPLETED' records from the index. Querying this GSI by UserId with ScanIndexForward set to false retrieves only the relevant, in-progress items in descending order of the timestamp, minimizing RCU usage and latency.

Adım Adım Çözüm

Identify the performance and cost bottleneck in the access pattern.

Querying the base table or scanning it for 'IN_PROGRESS' items scans unnecessary data, wasting Read Capacity Units (RCUs) and increasing latency.

DynamoDB charges RCUs based on the size of the data read before filtering. To optimize cost and speed, only the relevant items should be read.

Design a sparse secondary index to isolate the required dataset.

A Global Secondary Index (GSI) is created with UserId as the partition key and InProgressTimestamp as the sort key. InProgressTimestamp is only populated for in-progress items.

DynamoDB sparse indexes only include items that possess the index key attributes. This excludes completed videos from the GSI, making it small and efficient to query.

Execute the query using appropriate sort configuration.

Query the GSI with ScanIndexForward set to false and a limit of 10.

Setting ScanIndexForward to false returns the results sorted by the sort key (InProgressTimestamp) in descending order, fulfilling the chronological requirement.

Anahtar Kavram

Sparse Global Secondary Indexes (GSIs) for optimized querying and cost management in DynamoDB.

Soru 1479Soru →

A customer loyalty rewards platform named "LoyaltyLink" processes member transactions and records reward point updates in an Amazon DynamoDB table. During a flash sale event, the application experiences a high volume of writes and starts throwing `ProvisionedThroughputExceededException` errors. The DynamoDB table partition key is `transaction_date` (formatted as YYYY-MM-DD), and the sort key is `member_id`. Although the total write throughput is well within the table's provisioned write capacity units (WCUs), the requests are heavily skewed towards the current date, causing throttling on a single partition. Which of the following approaches should a developer implement to resolve this throttling issue?

Redesign the partition key schema by appending a random suffix (such as a number from

1

N

) to the `transaction_date` partition key during writes, and update the application logic to query across all salted partitions.

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

5000

to accommodate the temporary spike in write activity.

Integrate an Amazon SQS queue to buffer write requests and increase the SQS visibility timeout to

600

seconds to prevent message processing duplicates.

Reconfigure the application to perform parallel Scan operations across

10

segments to distribute the write workload evenly across the physical partitions.

Cevabı ve açıklamayı göster

Cevap: Redesign the partition key schema by appending a random suffix (such as a number from $1$ to $N$ ) to the `transaction_date` partition key during writes, and update the application logic to query across all salted partitions.

Cevap

Redesign the partition key schema by appending a random suffix (such as a number from

1

N

) to the `transaction_date` partition key during writes, and update the application logic to query across all salted partitions.

The correct answer is to redesign the partition key schema by appending a random suffix to the `transaction_date` partition key during writes. Because DynamoDB partitions have a maximum write throughput limit of

1000

WCUs, using a partition key with low cardinality (such as a single date for all transactions on that day) causes all writes to target a single partition, resulting in throttling. Adding a random suffix (salting) distributes the items across multiple partitions, overcoming the single-partition write limit.

Adım Adım Çözüm

Identify the cause of the ProvisionedThroughputExceededException when total consumed capacity is within limits.

The issue is a hot partition key caused by using a highly skewed value (`transaction_date`), which routes all writes for a single day to the same physical partition, hitting the single-partition limit of

1000

WCUs.

Understanding the physical limits of DynamoDB partitions is necessary to diagnose why scaling up overall capacity fails to resolve the issue.

Evaluate the correct design pattern for handling hot partition keys during writes.

Appending a random suffix (write sharding/salting) to the partition key distributes the write workload across multiple logical partitions.

Using a random suffix allows writes to be spread across multiple physical partitions, multiplying the maximum throughput for a single date.

Determine the changes required for read operations.

The application must be updated to query all potential salted partition keys (scatter-gather) to retrieve the full set of transactions for a given date.

Querying salted keys ensures that data can still be read reliably even though it is distributed across multiple partitions.

Anahtar Kavram

Handling DynamoDB hot partition keys using write sharding (salting) to distribute throughput across physical partitions.

Soru 1480Soru →

A developer is configuring a containerized application to run on Amazon ECS using the AWS Fargate launch type. The application needs to read messages from an Amazon SQS queue and write records to an Amazon DynamoDB table. During container initialization, the ECS container agent must pull the container image from Amazon ECR, retrieve a database credential from AWS Secrets Manager to set as an environment variable, and send container logs to Amazon CloudWatch Logs. Which two IAM roles must the developer configure in the ECS task definition to meet these requirements with the minimum required privileges? (Select TWO.)

Geçerli olan tümünü seçin

An ECS Task Execution Role with a policy that allows the ecr:GetAuthorizationToken, ecr:BatchGetImage, secretsmanager:GetSecretValue, and logs:PutLogEvents actions.

An ECS Task Role with a policy that allows the sqs:ReceiveMessage, sqs:DeleteMessage, and dynamodb:PutItem actions.

An ECS Task Role with a policy that allows the ecr:BatchGetImage, secretsmanager:GetSecretValue, and logs:PutLogEvents actions.

An ECS Task Execution Role with a policy that allows the sqs:ReceiveMessage, sqs:DeleteMessage, and dynamodb:PutItem actions.

An IAM Instance Role associated with the underlying EC2 instance profile that allows Amazon ECR, AWS Secrets Manager, and Amazon CloudWatch access.

Cevabı ve açıklamayı göster

Cevap: An ECS Task Execution Role with a policy that allows the ecr:GetAuthorizationToken, ecr:BatchGetImage, secretsmanager:GetSecretValue, and logs:PutLogEvents actions.; An ECS Task Role with a policy that allows the sqs:ReceiveMessage, sqs:DeleteMessage, and dynamodb:PutItem actions.

Cevap

An ECS Task Execution Role that allows the container agent to pull images, fetch secrets, and send logs, and an ECS Task Role that allows the application to read from SQS and write to DynamoDB.

The correct solution involves configuring both the ECS Task Execution Role and the ECS Task Role. The Task Execution Role is required by the ECS agent to prepare the environment (pull ECR images, retrieve secrets to set as environment variables, and send container logs to CloudWatch). The Task Role is required by the application code to interact with AWS services like Amazon SQS and Amazon DynamoDB.

Adım Adım Çözüm

Analyze the requirements of the ECS container agent versus the application running inside the container.

The container agent needs to pull images, retrieve secrets for environment variables, and configure logging. The application code needs to interact with SQS and DynamoDB.

This separation determines which permissions go to the Task Execution Role and which go to the Task Role.

Assign agent-level permissions to the ECS Task Execution Role.

Permissions for ECR image pull, Secrets Manager secret retrieval, and CloudWatch log delivery are assigned to the Task Execution Role.

The ECS agent performs these tasks before launching the application container, so they must be in the execution role.

Assign application-level permissions to the ECS Task Role.

Permissions to receive/delete messages from SQS and put items to DynamoDB are assigned to the Task Role.

The application code running inside the container assumes the Task Role to perform its business logic.

Anahtar Kavram

Distinction between ECS Task Role (application permissions) and ECS Task Execution Role (agent/infrastructure permissions) in AWS Fargate.

ÖncekiSayfa 74 / 78Sonraki

Tüm alıştırma soruları

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Alternatif Yöntem

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Alternatif Yöntem

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap