Troubleshooting and Optimization

271 soru

Tüm türler271 Çoktan seçmeli138 Çoklu seçim133

A developer is testing a Go microservice locally. The microservice uses the AWS SDK for Go v2 to retrieve parameter configurations from Amazon Systems Manager (SSM) Parameter Store using the following initialization code:

go
// WARNING: Do not hardcode credentials in production.
// This code relies on the default credential provider chain.
cfg, err := config.LoadDefaultConfig(context.TODO())
if err != nil {
log.Fatalf("unable to load SDK config, %v", err)
}
client := ssm.NewFromConfig(cfg)

The application runs inside a local Docker container as a non-root user `appuser` (home directory `/home/appuser`). To supply AWS credentials to the container, the developer ran the container with the environment variable `AWS_PROFILE=dev-profile` and mounted the host's `~/.aws/credentials` file to `/home/appuser/.aws/credentials`.

On the host machine, the AWS CLI configurations are:

`~/.aws/config`:
ini
[profile dev-profile]
role_arn = arn:aws:iam::123456789012:role/DevDeveloperRole
source_profile = base-profile

`~/.aws/credentials` (using placeholder credentials for security):
ini
[base-profile]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

When the application runs in the container, it fails with the error `operation error SSM: GetParameter, failed to resolve credentials`. However, running `aws ssm get-parameter --name /app/config --profile dev-profile` directly on the host machine succeeds.

Which of the following is the root cause of this credential resolution failure?

The AWS SDK for Go v2 default credential chain does not support containerized environments, requiring the developer to pass the raw credentials directly into the `config.LoadDefaultConfig` function parameters in the application code.

The IAM role trust policy for `DevDeveloperRole` does not authorize the service principal `ecs-tasks.amazonaws.com` to assume the role, causing the STS assume-role operation to fail when initiated from the container environment.

The `dev-profile` profile relies on a role assumption chain defined in the host's `~/.aws/config` file, which was not mounted into the container, preventing the SDK from locating the profile configuration.

The Go SDK requires the application to retrieve credentials from AWS Systems Manager Parameter Store or AWS Secrets Manager rather than reading profile configurations from the local filesystem.

Cevabı ve açıklamayı göster

Cevap: The `dev-profile` profile relies on a role assumption chain defined in the host's `~/.aws/config` file, which was not mounted into the container, preventing the SDK from locating the profile configuration.

Cevap

The credential resolution failure is caused by the missing configuration file inside the container. The profile `dev-profile` is defined in the host's `~/.aws/config` file (which references `role_arn` and `source_profile`). Because only the `~/.aws/credentials` file was mounted to the container, the AWS SDK inside the container could not locate the definition for `dev-profile` and therefore could not resolve the credentials.

The correct answer points out that the profile configuration (`dev-profile`) specifying role-chaining parameters (`role_arn` and `source_profile`) resides in the host's `~/.aws/config` file. If only the `~/.aws/credentials` file is mounted to the container, the SDK cannot resolve the `dev-profile` name to its role assumption configuration, causing credential resolution to fail.

Adım Adım Çözüm

Analyze how the AWS SDK for Go v2 resolves credentials.

The SDK looks at environment variables like `AWS_PROFILE` and then checks the shared configuration file (`~/.aws/config`) and credentials file (`~/.aws/credentials`) in the user's home directory.

Understanding the credential resolution chain helps pinpoint where the lookup breaks.

Examine the volume mounts defined for the Docker container.

Only `~/.aws/credentials` is mounted to `/home/appuser/.aws/credentials`. The `~/.aws/config` file is not mounted.

This shows that the containerized SDK only has access to the credentials file and not the configuration file.

Evaluate the profile configuration structure.

The target profile `dev-profile` is configured in `~/.aws/config` using `role_arn` and `source_profile`. The credentials for `base-profile` are in `~/.aws/credentials`.

Because the SDK in the container lacks the config file, it cannot read the definition for `dev-profile`, preventing it from understanding that it must assume a role using the `base-profile` credentials.

Anahtar Kavram

Credential File vs Configuration File in AWS SDK Profile Resolution

Alternatif Yöntem

Instead of mounting individual files, the developer can mount the entire `~/.aws` directory to `/home/appuser/.aws` in the container. This ensures both `config` and `credentials` files are accessible, permitting the SDK to chain profiles successfully.

Tahmini Süre:2m 30s

Soru 2Soru →

A developer is instrumenting a Go-based microservice running on Amazon ECS with the EC2 launch type to trace incoming HTTP requests, downstream HTTP client calls, and calls to Amazon DynamoDB using AWS X-Ray. The X-Ray daemon is already running on the container host instances. Which of the following actions must the developer take to instrument the application and ensure downstream traces are recorded? (Select TWO.)

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

Instrument the AWS SDK clients using the X-Ray SDK for Go and wrap the HTTP client's transport with the X-Ray RoundTripper.

Pass the Go context containing the active segment to downstream AWS SDK operations and HTTP client calls.

Hardcode temporary AWS IAM credentials within the application's SDK client configuration to authorize calls to the X-Ray daemon.

Configure the AWS SDK clients without passing the Go context object, as the Go X-Ray SDK automatically registers a global listener that intercepts and correlates all downstream calls.

Configure the Amazon SQS queue's visibility timeout to be shorter than the database processing time to force X-Ray to flush trace segments.

Cevabı ve açıklamayı göster

Cevap: Instrument the AWS SDK clients using the X-Ray SDK for Go and wrap the HTTP client's transport with the X-Ray RoundTripper.; Pass the Go context containing the active segment to downstream AWS SDK operations and HTTP client calls.

Cevap

To instrument the Go application for AWS X-Ray, the developer must instrument the AWS SDK clients and HTTP client transport, and explicitly pass the Go context containing the active segment to all downstream calls.

Instrumenting the SDK clients and HTTP transport with X-Ray SDK helpers enables subsegment generation for outgoing requests. Since Go lacks thread-local storage, context must be explicitly passed to propagate the active trace segment.

Adım Adım Çözüm

Wrap the HTTP client transport with the X-Ray RoundTripper and initialize the AWS SDK clients with X-Ray instrumentation helper functions.

The application code is prepared to intercept outgoing AWS SDK and HTTP requests to generate X-Ray subsegments.

This establishes the handlers and interceptors required by the X-Ray SDK to record outgoing service details.

Ensure that the Go context.Context object representing the active request segment is passed into all downstream SDK calls and HTTP requests.

The trace ID and segment hierarchy are successfully propagated down the call chain.

Go does not have thread-local storage; therefore, trace context propagation relies entirely on passing context variables down the call stack.

Anahtar Kavram

Go X-Ray SDK Instrumentation and Context Propagation

Soru 3Soru →

A developer is troubleshooting an authorization issue with a REST API in Amazon API Gateway. The API uses a custom Lambda authorizer with caching enabled, and the cache key is set to the Authorization header. When a client sends a request to GET /orders/101 with a valid token, the request succeeds. However, when the same client immediately sends a request to GET /orders/202 using the same token, the client receives a 403 Forbidden error with the message 'User is not authorized to access this resource'. The developer verifies that the client has valid permissions for both order resources. What is the root cause of this authorization failure, and how should it be resolved?

The Lambda authorizer returned a resource ARN specific to the first request's path, which was cached. Subsequent requests for different paths with the same token reuse the cached policy and are denied. To resolve this, configure the Lambda authorizer to return a wildcard resource ARN covering all paths, or disable caching.

The Lambda authorizer's IAM execution role lacks permissions to assume the client's IAM role for the second request. To resolve this, modify the trust policy of the client's IAM role to allow the sts:AssumeRole action for the Lambda authorizer's execution role.

The API Gateway service principal lacks permissions to invoke the Lambda authorizer for the second path resource. To resolve this, add a resource-based policy to the Lambda authorizer function to grant lambda:InvokeFunction permission to apigateway.amazonaws.com.

The API Gateway API must use a Cognito User Pools authorizer instead of a custom Lambda authorizer to validate identity tokens. To resolve this, configure Cognito User Pools and associate it with a Cognito Identity Pool to map groups to IAM roles for dynamic path authorization.

Cevabı ve açıklamayı göster

Cevap: The Lambda authorizer returned a resource ARN specific to the first request's path, which was cached. Subsequent requests for different paths with the same token reuse the cached policy and are denied. To resolve this, configure the Lambda authorizer to return a wildcard resource ARN covering all paths, or disable caching.

Cevap

When caching is enabled, API Gateway caches the policy returned by the Lambda authorizer using the cache key (the token). If the policy specifies a resource-specific ARN (like the path of the first request), any subsequent requests to a different path with the same token will use the cached policy and fail with a 403 Forbidden error because that path is not allowed in the policy. Returning a wildcard ARN or disabling caching resolves this issue.

Adım Adım Çözüm

Analyze the symptoms of the authorization failure where the first request succeeds but the subsequent request with the same token to a different path fails with a 403 Forbidden error.

Identify that the Lambda authorizer has caching enabled with the Authorization header as the cache key.

This helps narrow down the problem to how API Gateway caches and evaluates the IAM policy returned by the Lambda authorizer.

Examine how API Gateway caches policies based on the custom Lambda authorizer configuration.

The authorizer returns a policy containing the resource ARN for the specific path of the first request (/orders/101), which is then cached by API Gateway for that authorization token.

API Gateway uses the cached policy for all subsequent requests containing the same token during the TTL period, without invoking the Lambda function again.

Determine how the cached policy affects the second request (GET /orders/202).

Because the cached policy only allows access to the resource ARN for /orders/101, API Gateway denies access to /orders/202 and returns a 403 Forbidden error.

This confirms that the narrow resource scope in the cached policy is the root cause of the authorization failure.

Formulate the resolution to fix the authorization issue.

Modify the Lambda authorizer code to return a wildcard resource ARN (e.g., /orders/*) so that the cached policy permits access to all relevant paths, or disable caching if granular per-path verification is required on every request.

This ensures that either the cached policy is broad enough to cover all client requests or that the authorizer runs on every request to generate a precise policy.

Anahtar Kavram

API Gateway custom Lambda authorizer policy caching and resource ARN validation.

Soru 4Soru →

A developer is troubleshooting an application named PixelStream that uploads high-resolution images. The application stores metadata in an Amazon DynamoDB table where the partition key is set to the upload date (formatted as YYYY-MM-DD). During peak hours, the application frequently encounters ProvisionedThroughputExceededException errors even though the table's overall consumed throughput is well below the provisioned write capacity limit. What is the most effective way to resolve this throughput issue?

Redesign the partition key schema to use a more granular attribute, such as a unique Image ID, to distribute write requests evenly across partitions.

Increase the Amazon SQS visibility timeout of the incoming queue to allow the consumers more time to write records to the table.

Modify the application configuration to hardcode the AWS access keys and force the SDK client to throttle its own requests.

Modify the application queries to perform table Scan operations instead of Query operations to read data from all partitions.

Cevabı ve açıklamayı göster

Cevap: Redesign the partition key schema to use a more granular attribute, such as a unique Image ID, to distribute write requests evenly across partitions.

Cevap

Redesign the partition key schema to use a more granular attribute, such as a unique Image ID, to distribute write requests evenly across partitions.

Redesigning the partition key schema to use a high-cardinality attribute, such as a unique Image ID, spreads write operations across multiple physical partitions, preventing any single partition from exceeding its individual throughput limits.

Adım Adım Çözüm

Analyze the table schema and error behavior.

Identify that the partition key is the upload date, which has very low cardinality and results in all writes for a given day hitting the same partition.

This confirms that the ProvisionedThroughputExceededException is caused by a hot partition key rather than exceeding the table's total capacity.

Determine the solution for even data distribution.

Select a partition key with high cardinality, such as a unique Image ID.

High-cardinality keys distribute write requests evenly across physical partitions, resolving partition-level write limits.

Anahtar Kavram

Selecting a partition key with high cardinality to distribute write requests evenly and avoid hot partition bottlenecks.

Tahmini Süre:1m 0s

Soru 5Soru →

A developer is troubleshooting a CI/CD pipeline in AWS CodePipeline that deploys infrastructure using AWS CloudFormation. During the initial deployment of a new stack, the deployment stage failed due to an invalid parameter value, leaving the CloudFormation stack in the ROLLBACK_COMPLETE state. After correcting the parameter value in the template and pushing the fix to the source repository, the pipeline runs again but the CloudFormation deploy stage fails immediately, indicating that the stack cannot be updated. Which action must the developer perform to successfully deploy the stack through the pipeline?

Delete the existing CloudFormation stack manually or via the AWS CLI, and then trigger the pipeline again.

Execute the aws cloudformation continue-update-rollback CLI command to force the stack back to an active state, then trigger the pipeline.

Modify the trust policy of the CloudFormation execution role to allow the cloudformation.amazonaws.com service principal to assume the role, and then release the change.

Run drift detection on the stack to identify manually modified resources, resolve the drift, and trigger the pipeline.

Cevabı ve açıklamayı göster

Cevap: Delete the existing CloudFormation stack manually or via the AWS CLI, and then trigger the pipeline again.

Cevap

Delete the existing CloudFormation stack manually or via the AWS CLI, and then trigger the pipeline again.

The correct answer is to delete the existing CloudFormation stack manually or via the AWS CLI, and then trigger the pipeline again. When a CloudFormation stack fails during its initial creation, it goes into the ROLLBACK_COMPLETE state. CloudFormation does not allow updates to a stack that has never been successfully created. Therefore, to proceed, the developer must delete the failed stack, which removes it, allowing the pipeline's subsequent run to perform a successful create operation.

Adım Adım Çözüm

Identify the current status of the CloudFormation stack from the AWS CloudFormation console or CLI.

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

Understanding the exact failure state is necessary because different rollback states (e.g., ROLLBACK_COMPLETE vs UPDATE_ROLLBACK_COMPLETE) have different recovery paths.

Determine the supported actions for a stack in the ROLLBACK_COMPLETE state.

A stack in ROLLBACK_COMPLETE cannot be updated; it can only be deleted.

This determines that attempting to push template updates through the pipeline directly will continue to fail, as the pipeline will attempt to perform a stack update action.

Delete the failed stack and re-run the pipeline.

The pipeline runs successfully and creates the stack from scratch with the corrected template.

Deleting the stack removes the blocked state, allowing the pipeline's CloudFormation action to execute a clean stack creation.

Anahtar Kavram

Handling CloudFormation initial creation failures and the ROLLBACK_COMPLETE state in CI/CD pipelines.

Soru 6Soru →

A developer is troubleshooting an AWS Lambda function that processes customer orders. The Lambda function is configured to run inside a custom VPC in two private subnets to access an Amazon RDS database securely. During testing, the function times out when attempting to connect to an external payment processor's HTTP endpoint over the internet. Additionally, under load, the Lambda function frequently times out because it establishes a new database connection during each invocation, quickly exhausting database resources.

Which combination of actions will resolve these issues? (Select TWO.)

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

Configuring a NAT gateway in a public subnet, and updating the route tables of the private subnets to route outbound internet traffic (0.0.0.0/0) through the NAT gateway.

Declaring the database connection client outside of the Lambda handler function to enable execution context reuse across warm starts.

Attaching an Internet Gateway directly to the private subnets where the Lambda function is deployed, and assigning public IP addresses to the function configuration.

Moving the Lambda function to a public subnet in the VPC to allow direct route access to the Internet Gateway for external communication.

Re-initializing the database connection client inside the Lambda handler and executing a connection close method at the end of each invocation.

Cevabı ve açıklamayı göster

Cevap: Configuring a NAT gateway in a public subnet, and updating the route tables of the private subnets to route outbound internet traffic (0.0.0.0/0) through the NAT gateway.; Declaring the database connection client outside of the Lambda handler function to enable execution context reuse across warm starts.

Cevap

The correct options are configuring a NAT gateway in a public subnet and routing the private subnet's traffic through it, and declaring the database connection client outside of the handler function to reuse the execution context.

The correct options resolve both issues. Routing internet-bound traffic from private subnets through a NAT gateway in a public subnet allows the Lambda function to communicate with the external payment API. Declaring the database client outside the handler code ensures that the database connection is reused across invocations, mitigating connection overhead and latency.

Adım Adım Çözüm

Address the external payment processor connection timeouts.

Determine that Lambda functions in private subnets require a NAT gateway or VPC endpoint to access the public internet.

Since the external API is on the internet, a NAT gateway must be set up in a public subnet, and the private subnet route tables must be updated to route outbound traffic through it.

Address the database resource exhaustion and execution timeouts under load.

Move the database connection initialization code out of the Lambda handler block to global scope.

This allows subsequent warm executions of the function to reuse the existing database connection pool instead of repeatedly opening and closing sockets, resolving execution timeouts and database overload.

Anahtar Kavram

VPC networking configuration for outbound Lambda internet access and database connection optimization using execution context reuse.

Soru 7Soru →

An application running inside an Amazon ECS task on AWS Fargate in Account A ( $111111111111$ ) needs to write objects to an Amazon S3 bucket located in Account B ( $222222222222$ ). The developer wants the application to temporarily assume an IAM role named CrossAccountS3Writer in Account B. The ECS task definition is configured with an ECS Task Role named ECSTaskRole.

The trust policy of the CrossAccountS3Writer role in Account B contains the following statement:

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

When the application execution code attempts to call the sts:AssumeRole API, it fails with an AccessDenied error. How should the developer resolve this authorization failure?

Attach an identity-based policy to ECSTaskRole in Account A that grants the sts:AssumeRole permission targeting the Amazon Resource Name (ARN) of the CrossAccountS3Writer role in Account B.

Attach an identity-based policy to the ECS Task Execution Role in Account A that grants the sts:AssumeRole permission targeting the Amazon Resource Name (ARN) of the CrossAccountS3Writer role in Account B.

Modify the trust policy of the CrossAccountS3Writer role in Account B to specify the ECS service principal ecs-tasks.amazonaws.com as the principal instead of the ECSTaskRole ARN.

Generate long-term IAM access keys for a user in Account B, hardcode them into the application's client initialization code, and initialize the S3 client directly using those credentials.

Cevabı ve açıklamayı göster

Cevap: Attach an identity-based policy to ECSTaskRole in Account A that grants the sts:AssumeRole permission targeting the Amazon Resource Name (ARN) of the CrossAccountS3Writer role in Account B.

Cevap

Attach an identity-based policy to ECSTaskRole in Account A that grants the sts:AssumeRole permission targeting the Amazon Resource Name (ARN) of the CrossAccountS3Writer role in Account B.

For cross-account role assumption, AWS IAM requires a bilateral handshake: the trusting role (in Account B) must specify the external principal in its trust policy, and the trusted principal (in Account A) must have an identity-based policy that grants permission to call 'sts:AssumeRole' on the target role's ARN. Since the trust policy in Account B is already correctly configured, adding the 'sts:AssumeRole' permission to the ECSTaskRole in Account A completes this handshake and resolves the AccessDenied error.

Adım Adım Çözüm

Analyze the error context and the resource policy configuration.

The application inside the ECS task is trying to assume the CrossAccountS3Writer role in Account B, but the AssumeRole request is denied.

Establishing cross-account delegation requires explicit authorization in both accounts: a trust relationship in the receiving account (Account B) and an identity-based grant in the initiating account (Account A).

Examine the trust policy of the target role (CrossAccountS3Writer) in Account B.

The trust policy correctly allows the identity 'arn:aws:iam::111111111111:role/ECSTaskRole' to call 'sts:AssumeRole'.

This confirms that Account B is configured properly to trust the ECS Task Role from Account A.

Determine the missing permission in the initiating account (Account A).

The ECS Task Role (ECSTaskRole) itself does not have a policy permitting it to invoke 'sts:AssumeRole' on the destination role.

IAM identities require explicit permission to call 'sts:AssumeRole' on a resource in another account, even if that resource trusts them.

Select the correct action to resolve the authorization failure.

Add an identity-based policy to 'ECSTaskRole' with an 'Allow' effect on the 'sts:AssumeRole' action, specifying the ARN of the target role in Account B as the resource.

This satisfies the cross-account delegation requirements by authorizing the ECS Task Role to perform the assume-role request.

Anahtar Kavram

Cross-Account IAM Delegation and ECS Task Roles

Soru 8Soru →

A developer has configured an AWS Lambda function written in Python to process events from an Amazon SQS queue and write the results to an Amazon DynamoDB table. Active tracing is enabled on both the SQS queue and the Lambda function. When reviewing the AWS X-Ray console, the developer observes that the service map shows the SQS queue and the Lambda function, but the downstream calls to DynamoDB are missing from the trace. Which action should the developer take to trace the downstream DynamoDB calls in AWS X-Ray?

Manually extract the _X_AMZN_TRACE_ID tracing header from the SQS event object and pass it as a custom parameter in the DynamoDB API request payload.

Initialize the Boto3 DynamoDB client with hardcoded AWS access keys and secret keys that have X-Ray write permissions.

Import the AWS X-Ray SDK in the Lambda function code and invoke the patch_all() function before initializing the Boto3 client.

Increase the SQS visibility timeout of the source queue to allow the Boto3 SDK sufficient time to complete and flush the DynamoDB trace segments.

Cevabı ve açıklamayı göster

Cevap: Import the AWS X-Ray SDK in the Lambda function code and invoke the patch_all() function before initializing the Boto3 client.

Cevap

Import the AWS X-Ray SDK in the Lambda function code and invoke the patch_all() function before initializing the Boto3 client.

The correct answer is to import the AWS X-Ray SDK and run the patch_all() function. When running a Python Lambda function with active tracing enabled, downstream SDK calls are not traced by default unless the Boto3 library is instrumented. Patching the library automatically wraps Boto3 clients so that downstream calls (like DynamoDB operations) are recorded as subsegments in the X-Ray trace.

Adım Adım Çözüm

Identify that the Lambda function has active tracing enabled but downstream calls to DynamoDB are not being recorded.

The Lambda function segment is present, but DynamoDB subsegments are missing.

Active tracing on Lambda only traces the Lambda execution itself, not downstream SDK calls by default.

Instrument the Boto3 library using the AWS X-Ray SDK for Python.

The Boto3 clients will automatically generate and propagate subsegment details for downstream API calls.

Patching is the standard method in the Python AWS X-Ray SDK to instrument supported libraries like Boto3 without modifying client invocation syntax.

Anahtar Kavram

AWS SDK client instrumentation using the X-Ray SDK to trace downstream AWS service calls.

Soru 9Soru →

A developer is troubleshooting a web dashboard hosted on `https://monitor.server-analytics.io` that queries a backend using an Amazon API Gateway REST API. The API is configured with a Lambda Proxy integration. When the client makes a request to the API, the browser blocks the response and displays the following error:

`Access to XMLHttpRequest at 'https://api.server-analytics.io/v1/logs' from origin 'https://monitor.server-analytics.io' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.`

Which TWO steps should the developer take to resolve these errors?

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

Configure the `OPTIONS` method on the API Gateway resource to return the required CORS headers for preflight requests.

Modify the Lambda function's response payload to include the `Access-Control-Allow-Origin` header in the `headers` object.

Configure a CORS configuration rule on the Amazon S3 bucket hosting the web dashboard.

Change the integration type to Lambda Custom Integration and configure API Gateway integration responses to handle the request headers.

Add an IAM resource policy to the API Gateway API that allows the origin `https://monitor.server-analytics.io`.

Cevabı ve açıklamayı göster

Cevap: Configure the `OPTIONS` method on the API Gateway resource to return the required CORS headers for preflight requests.; Modify the Lambda function's response payload to include the `Access-Control-Allow-Origin` header in the `headers` object.

Cevap

Configure the `OPTIONS` method on the API Gateway resource to return the required CORS headers for preflight requests, and modify the Lambda function's response payload to include the `Access-Control-Allow-Origin` header in the `headers` object.

The correct options are configuring the `OPTIONS` method on the API Gateway resource and modifying the Lambda function's response payload. Under a Lambda Proxy integration, resolving CORS requires a two-fold approach: first, the preflight `OPTIONS` request must be handled by API Gateway (or a mock integration) to return the allowed origin; second, the backend Lambda function must return the `Access-Control-Allow-Origin` header in its execution response.

Adım Adım Çözüm

Enable CORS preflight by configuring the `OPTIONS` method on the API resource.

The browser's initial preflight request is successfully answered with `Access-Control-Allow-Origin` and other CORS headers.

Browsers send an HTTP `OPTIONS` preflight request before cross-origin non-simple requests to verify if the server permits the cross-origin call.

Add the `Access-Control-Allow-Origin` header to the backend response returned by the Lambda function.

The actual HTTP request succeeds because the response payload contains the required header.

Under Lambda Proxy integration, API Gateway does not automatically inject CORS headers into the backend response. The backend Lambda function must explicitly return these headers in its payload.

Anahtar Kavram

CORS handling in API Gateway Lambda Proxy integrations requires CORS configuration for both the preflight `OPTIONS` method on API Gateway and the actual method response from the backend Lambda function.

Tahmini Süre:1m 30s

Soru 10Soru →

A developer is troubleshooting an AWS Lambda function with a configured timeout of 10 seconds. The function is occasionally failing to process incoming payloads. The developer wants to configure an Amazon CloudWatch Logs metric filter to count how many times the function executions are terminated due to timeouts, and to trigger an alarm. The application code is designed to log custom execution details in JSON format, including `{ "execution_time_ms": 10500, "status": "success" }`, at the end of the handler execution. Which configuration should the developer implement to reliably monitor these execution timeouts?

Create a metric filter on the log group with the pattern `{ $.execution_time_ms > 10000 }` and create a CloudWatch alarm based on this metric.

Create a metric filter on the log group with the pattern `{ $.status = "timeout" }` and create a CloudWatch alarm based on this metric.

Create a metric filter on the log group with the pattern "Task timed out" and create a CloudWatch alarm based on this metric.

Create a metric filter on the log group with the pattern `[timestamp, request_id, status = "timeout"]` and create a CloudWatch alarm based on this metric.

Cevabı ve açıklamayı göster

Cevap: Create a metric filter on the log group with the pattern "Task timed out" and create a CloudWatch alarm based on this metric.

Cevap

Create a metric filter on the log group with the pattern "Task timed out" and create a CloudWatch alarm based on this metric.

When a Lambda function times out, the Lambda service halts execution immediately. This prevents the custom application code from completing and writing any custom JSON log events. Instead, the service writes a message containing 'Task timed out' to the log stream. Therefore, a metric filter targeting this literal string is the only reliable way to count timeouts.

Adım Adım Çözüm

Analyze Lambda execution behavior during a timeout

When a Lambda function reaches its configured timeout limit (10 seconds in this scenario), the AWS Lambda service terminates the execution container immediately.

This shows that any application-level code designed to run at the end of the handler (such as writing a custom JSON log with execution metrics) is never executed.

Identify the log event recorded during a timeout

The AWS Lambda service runtime writes a platform-generated log line to the log stream, containing the phrase: 'Task timed out after 10.00 seconds'.

To reliably track timeouts, the metric filter must search for this platform-generated text rather than custom JSON properties that are only written upon successful handler execution.

Select the correct CloudWatch Logs Metric Filter syntax

The literal pattern "Task timed out" is used to match the platform log event. An alarm is then associated with this metric to trigger notifications or scaling actions.

This correctly targets the service-level error message and tracks execution failures accurately.

Anahtar Kavram

AWS Lambda platform logging on execution timeouts vs application-level logs, and correct CloudWatch metric filter string matching.

Tahmini Süre:1m 30s

Soru 11Soru →

A logistics tracking application named LogiRoute writes real-time status updates for packages to an Amazon DynamoDB table. During peak delivery hours, the application occasionally encounters ProvisionedThroughputExceededException errors when writing updates, causing the tracking requests to fail immediately. Monitoring metrics show that the table's total consumed write capacity remains well below its provisioned write capacity limit. Investigations reveal that the application's HTTP library is configured to disable automatic retries for all backend calls. How should the developer resolve these transient errors while minimizing cost?

Configure the AWS SDK client to use exponential backoff and jitter for handling transient write errors.

Increase the table's provisioned Write Capacity Units (WCUs) to accommodate the peak traffic spikes.

Perform a table Scan operation to verify the partition state before executing the write requests.

Queue the write requests in an Amazon SQS queue and set the visibility timeout to be shorter than the message processing time.

Cevabı ve açıklamayı göster

Cevap: Configure the AWS SDK client to use exponential backoff and jitter for handling transient write errors.

Cevap

Configure the AWS SDK client to use exponential backoff and jitter for handling transient write errors.

Configuring the AWS SDK client to use exponential backoff and jitter is the standard best practice for resolving transient ProvisionedThroughputExceededException errors when the overall capacity is sufficient. This allows the application to retry requests after a progressively longer, randomized delay, smoothing out traffic spikes and avoiding errors for the end user without increasing provisioned throughput costs.

Adım Adım Çözüm

Analyze the error message and CloudWatch metrics.

Identify that the ProvisionedThroughputExceededException errors are transient and occurring even though the total consumed capacity is below provisioned limits.

This indicates that overall capacity is sufficient, but temporary bursts or micro-bursts are causing brief throttling.

Identify the application-side behavior.

Determine that automatic retries are disabled, causing the application to fail immediately upon receiving the exception.

AWS SDKs by default implement retry logic, but disabling or misconfiguring it causes immediate failures on transient errors.

Implement retry logic with backoff and jitter.

Configure the AWS SDK client to retry throttled requests using exponential backoff and randomized jitter delays.

This spreads out the retry attempts, preventing them from hitting the database simultaneously and successfully completing the writes once the transient spike subsides.

Anahtar Kavram

Handling DynamoDB transient throttling errors using SDK retries with exponential backoff and jitter.

Tahmini Süre:1m 30s

Soru 12Soru →

A ride-sharing booking application named 'CabFlow' processes ride requests using an Amazon DynamoDB table. During a major city-wide holiday event, the application experiences a massive surge in booking requests, resulting in `ProvisionedThroughputExceededException` errors. Monitoring indicates that the write requests are heavily concentrated on a partition key representing the current hour and city (e.g., `20260715-NYC`), creating a hot partition, while the table's overall provisioned capacity is not fully utilized. Which of the following actions should the developer take to resolve this key distribution and throttling issue? (Select TWO options.)

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

Append a randomized integer suffix to the partition key value before writing data to distribute the load across multiple partition keys.

Configure the AWS SDK client in the application to implement exponential backoff and jitter for retrying failed requests.

Increase the visibility timeout of the incoming Amazon SQS queue to allow more processing time for individual write operations.

Replace the query operations with Scan operations to search the table without relying on the partition key.

Hardcode AWS access keys directly in the client configuration to speed up authentication and authorization checks on subsequent requests.

Cevabı ve açıklamayı göster

Cevap: Append a randomized integer suffix to the partition key value before writing data to distribute the load across multiple partition keys.; Configure the AWS SDK client in the application to implement exponential backoff and jitter for retrying failed requests.

Cevap

Modify the partition key schema by appending a randomized suffix to distribute the write load, and configure the AWS SDK client to use exponential backoff and jitter for retries.

To fix DynamoDB throttling caused by hot partitions, developers should distribute the write requests across multiple partitions. This is accomplished by sharding the partition keys (adding a random suffix). In addition, configuring the SDK client to implement exponential backoff and jitter allows the application to retry transient failures without overloading the database.

Adım Adım Çözüm

Analyze the DynamoDB write pattern to identify the root cause of the throughput issue.

Identified a hot partition key problem due to low cardinality (all writes using the same hour-city key).

Resolving throttling requires distributing keys across partitions or managing retry behavior.

Implement write sharding (salting) by appending a random integer suffix to the partition key.

Writes are evenly distributed across different partition key values (e.g., `20260715-NYC-1` to `20260715-NYC-N`).

This allows DynamoDB to store and process the data across multiple physical partitions, utilizing the total allocated throughput.

Configure the application's SDK client to handle transient write failures gracefully.

The SDK retries failed operations using exponential backoff and jitter.

This avoids overwhelming the database with immediate retries and helps the application recover from temporary load spikes.

Anahtar Kavram

Resolving DynamoDB throttling issues by addressing hot partition keys through write sharding (salting) and handling client-side retries with backoff and jitter.

Soru 13Soru →

A developer is deploying a Java application on Amazon EC2 instances. The application writes log entries to a local log file at `/var/log/myapp/app.log`. The developer installs the Unified CloudWatch Agent on the instances and configures it to stream these logs to Amazon CloudWatch Logs. After starting the agent service on the EC2 instances, the developer notices that no log groups or log streams are created in CloudWatch Logs, and no log data is received. Which of the following could be the reasons for this issue? (Select TWO.)

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

The IAM role attached to the EC2 instances does not have the permissions required to create log groups, log streams, and write log events (such as the permissions provided by the CloudWatchAgentServerPolicy managed policy).

The Unified CloudWatch Agent configuration file contains a syntax error or specifies an incorrect log file path under the logs section in the collect_list.

The metric filter pattern defined in the agent configuration file incorrectly uses {

.status = "ERROR" } instead of {

.status == "ERROR" }, which causes the agent to fail to start.

The IAM role's trust policy designates lambda.amazonaws.com as the trusted entity instead of ec2.amazonaws.com, preventing the EC2 instances from assuming the role.

The EC2 instances are located in a public subnet, but logs cannot be uploaded because the subnet does not have a NAT Gateway or a VPC endpoint for CloudWatch Logs.

Cevabı ve açıklamayı göster

Cevap: The IAM role attached to the EC2 instances does not have the permissions required to create log groups, log streams, and write log events (such as the permissions provided by the CloudWatchAgentServerPolicy managed policy).; The Unified CloudWatch Agent configuration file contains a syntax error or specifies an incorrect log file path under the logs section in the collect_list.

Cevap

The correct reasons are that the IAM role attached to the EC2 instances lacks the required permissions (such as those in the CloudWatchAgentServerPolicy managed policy) and that the agent configuration file contains a syntax error or a misconfigured log file path under the collect_list settings.

The correct reasons are that the IAM role attached to the EC2 instances lacks the required permissions (such as those in the CloudWatchAgentServerPolicy managed policy) to communicate with CloudWatch Logs, and that the agent configuration file contains a syntax error or a misconfigured log file path under the collect_list settings, which prevents the agent from locating or processing the log files.

Adım Adım Çözüm

Analyze the IAM permissions for the Unified CloudWatch Agent.

Identify that the agent requires permissions like `logs:CreateLogGroup`, `logs:CreateLogStream`, and `logs:PutLogEvents` to write logs, which are typically provided by attaching the `CloudWatchAgentServerPolicy` managed policy to the EC2 instance profile.

Without these permissions, the agent cannot authenticate or perform log upload actions to CloudWatch Logs.

Check the local configuration file of the CloudWatch Agent.

Determine that the agent relies on the local configuration file (often `amazon-cloudwatch-agent.json`) to know which log files to collect and publish under the `logs` section. A syntax error or incorrect path there prevents the agent from finding or parsing the logs.

If the configuration file is malformed, the agent daemon cannot parse the settings to identify which logs to stream.

Evaluate the distractors regarding trust policies, metric filters, and network paths.

Confirm that metric filters are evaluated on the CloudWatch service side (not by the local agent), trust policies must allow EC2 (not Lambda) to assume the role, and public subnets do not require a NAT Gateway or VPC endpoints.

This rules out incorrect options and clarifies standard EC2 and CloudWatch Logs setup.

Anahtar Kavram

Configuring the Unified CloudWatch Agent to stream logs from EC2 instances requires both a valid configuration file on the host and an IAM role with the correct permissions (like CloudWatchAgentServerPolicy) and trust policy (ec2.amazonaws.com).

Soru 14Soru →

A microservice processes real-time telemetry data from IoT devices and writes it to an Amazon DynamoDB table. The table's partition key is DeviceType, which has three possible values: SmartWatch, FitnessTracker, and SmartScale. During periods of high traffic, the write operations fail with a ProvisionedThroughputExceededException, even though the total consumed write capacity of the table is well below the overall provisioned limit. Which TWO actions should the developer take to resolve these throttling errors? (Select TWO.)

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

Redesign the partition key schema to use a more unique attribute, such as a combination of DeviceType and DeviceId, to distribute writes across more partitions.

Configure the application's AWS SDK client to use exponential backoff and jitter for request retries when throttled.

Modify the application configuration to execute Scan operations instead of Query operations to read data from the table.

Increase the visibility timeout of the Amazon SQS queue consuming data from the DynamoDB Streams.

Hardcode temporary AWS access keys directly in the SDK client initialization to speed up database connection times.

Cevabı ve açıklamayı göster

Cevap: Redesign the partition key schema to use a more unique attribute, such as a combination of DeviceType and DeviceId, to distribute writes across more partitions.; Configure the application's AWS SDK client to use exponential backoff and jitter for request retries when throttled.

Cevap

To resolve the throttling, the developer must redesign the partition key schema to use a high-cardinality attribute (such as combining DeviceType and DeviceId) and configure the AWS SDK client to use exponential backoff and jitter for retries.

Redesigning the partition key schema to use a unique combination like DeviceType and DeviceId distributes writes evenly across multiple partition keys, eliminating the hot partition bottleneck. Implementing exponential backoff with jitter in the application SDK client handles transient throttling errors by spacing out retry attempts.

Adım Adım Çözüm

Analyze the cause of the ProvisionedThroughputExceededException.

Identify that a partition key with only three values (SmartWatch, FitnessTracker, SmartScale) creates a hot partition because write requests are concentrated on too few partitions.

DynamoDB partitions are allocated throughput limits. Having a low-cardinality partition key causes individual partitions to exceed their limits, even if the total table capacity is underutilized.

Improve partition key cardinality.

Combine DeviceType with a unique identifier like DeviceId to create a synthetic key.

A high-cardinality key distributes write requests across a larger number of partitions, ensuring even workload distribution.

Configure the client application's retry logic.

Enable exponential backoff and jitter within the AWS SDK client settings.

This prevents client-side retry storms and allows the application to recover gracefully from temporary spikes in traffic.

Anahtar Kavram

DynamoDB partition throttling occurs when a low-cardinality key concentrates requests on a single partition. This is resolved by increasing partition key cardinality and implementing client-side retries with backoff and jitter.

Tahmini Süre:1m 30s

Soru 15Soru →

A developer has deployed an AWS Lambda function inside a private subnet of a custom VPC to process user registration events. The function needs to retrieve database credentials from AWS Secrets Manager to perform database updates. However, the VPC does not have a NAT Gateway or internet access, and the Lambda function executions are timing out with connection errors to the Secrets Manager service endpoint. Which two actions should the developer take to resolve this issue? (Select TWO.)

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

Create an interface VPC endpoint (AWS PrivateLink) for AWS Secrets Manager in the VPC.

Configure the security group of the VPC endpoint to allow inbound HTTPS traffic on port 443 from the security group of the Lambda function.

Attach an Internet Gateway to the VPC and configure the private subnet's route table to route all outbound traffic through the Internet Gateway.

Modify the Lambda function configuration to assign a public IP address and place the function in a public subnet.

Increase the Lambda function's timeout configuration to 15 minutes and double the memory allocation to handle connection retries.

Cevabı ve açıklamayı göster

Cevap: Create an interface VPC endpoint (AWS PrivateLink) for AWS Secrets Manager in the VPC.; Configure the security group of the VPC endpoint to allow inbound HTTPS traffic on port 443 from the security group of the Lambda function.

Cevap

Create an interface VPC endpoint (AWS PrivateLink) for AWS Secrets Manager in the VPC, and configure the security group of the VPC endpoint to allow inbound HTTPS traffic from the security group of the Lambda function.

The correct options are creating an interface VPC endpoint for AWS Secrets Manager and configuring the endpoint's security group to allow inbound HTTPS traffic from the Lambda function. Since the Lambda function is running in a private subnet with no NAT Gateway or internet access, it cannot resolve or connect to the public Secrets Manager API endpoints. Creating an interface VPC endpoint (AWS PrivateLink) creates local ENIs in the subnets, enabling private routing to the service. For the connection to succeed, the security group attached to the VPC endpoint must permit inbound TCP traffic on port 443 from the security group of the Lambda function.

Adım Adım Çözüm

Analyze the network configuration of the Lambda function and the target service endpoint.

Identify that the Lambda function is running inside a private subnet of a VPC without internet access (no NAT Gateway) and cannot reach the public AWS Secrets Manager endpoint.

By default, Lambda functions inside a VPC require a route to the internet (via a NAT Gateway) or a VPC endpoint to reach public AWS service endpoints.

Create an interface VPC endpoint for AWS Secrets Manager.

Establish a private route for the Lambda function to connect to AWS Secrets Manager using internal IP addresses within the VPC.

An interface endpoint powered by AWS PrivateLink allows secure, private connections to supported AWS services without using a NAT Gateway or Internet Gateway.

Configure the security groups to allow traffic between the Lambda function and the VPC endpoint.

Ensure that the endpoint's security group allows inbound traffic on port 443 (HTTPS) from the security group assigned to the Lambda function.

Without adjusting the security group rules, the VPC endpoint will block the incoming connection requests from the Lambda function.

Anahtar Kavram

Configuring private access to AWS services from a VPC using interface VPC endpoints and proper security group configurations.

Tahmini Süre:2m 0s

Soru 16Soru →

A developer is testing a Java application locally on their workstation. The application publishes messages to an Amazon SNS topic using the AWS SDK for Java v2. The SDK client is initialized as follows:

java
SnsClient snsClient = SnsClient.builder()
.region(Region.US_EAST_1)
.build();

The developer's workstation has a shared AWS credentials file (`~/.aws/credentials`) containing a `[default]` profile with expired credentials and a `[dev]` profile with valid credentials. In the local IDE run configuration, the environment variables `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` are set to temporary credentials from an older session that has since expired. When the application runs, it fails with an expired token error.

Which of the following configuration steps must the developer perform to ensure the application successfully authenticates using the valid credentials from the `[dev]` profile? (Select TWO.)

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

Remove the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables from the IDE run configuration.

Set the AWS_PROFILE environment variable to dev in the IDE run configuration.

Modify the Java code to pass the access key and secret key from the dev profile directly to the SnsClient.builder() initialization.

Update the IAM trust policy of the IAM user or role associated with the dev profile to trust the local IDE process.

Store the credentials as plaintext parameters in AWS Systems Manager Parameter Store and retrieve them using an unauthenticated SDK call at application startup.

Cevabı ve açıklamayı göster

Cevap: Remove the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables from the IDE run configuration.; Set the AWS_PROFILE environment variable to dev in the IDE run configuration.

Cevap

Remove the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables from the IDE run configuration, and set the AWS_PROFILE environment variable to dev in the IDE run configuration.

The default credential provider chain in the AWS SDK for Java v2 evaluates credentials sources in a specific order: Java system properties, Environment variables, then the Shared credentials file. Because environment variables have higher precedence, the SDK uses the expired environment variables and throws an error instead of using the shared credentials file. Removing these environment variables allows the SDK to check the shared credentials file. Specifying the profile environment variable directs the SDK to load the valid credentials from the 'dev' profile instead of falling back to the expired 'default' profile.

Adım Adım Çözüm

Analyze the credentials lookup precedence of the default credential provider chain.

The SDK checks environment variables (AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY) before checking the shared credentials file (~/.aws/credentials).

Since the expired credentials are set in the environment variables, the SDK uses them and fails, never reaching the profiles in the shared credentials file.

Unset/remove the expired credential environment variables from the IDE run configuration.

The SDK credentials provider chain falls back to checking the shared credentials file.

This allows the SDK to read profiles defined in ~/.aws/credentials.

Configure the SDK to use the non-default 'dev' profile.

The AWS_PROFILE environment variable is set to dev, guiding the SDK to load credentials from the [dev] profile.

Without setting AWS_PROFILE, the SDK default credentials provider will attempt to use the [default] profile, which contains expired credentials.

Anahtar Kavram

AWS SDK Credential Provider Chain Precedence and Profiles

Soru 17Soru →

An HR management application named StaffSync records employee clock-in and clock-out events to an Amazon DynamoDB table. During the start of a morning shift, hundreds of employees clock in at the exact same minute. The application code makes direct write requests using a custom HTTP client without retry logic. This results in unhandled ProvisionedThroughputExceededException errors and application crashes, even though the table's total provisioned write capacity is not fully exhausted.

Which of the following is the most effective developer-centric solution to resolve these application crashes during brief write spikes?

Configure the client application to retry failed writes using the AWS SDK's built-in retry mechanism with exponential backoff and jitter.

Increase the DynamoDB table's overall provisioned Write Capacity Units (WCUs) to handle the short-lived spikes.

Perform a DynamoDB Scan operation before each write to verify if the employee has already clocked in for the day.

Configure a larger Amazon SQS visibility timeout on the DynamoDB table to queue the write requests automatically.

Cevabı ve açıklamayı göster

Cevap: Configure the client application to retry failed writes using the AWS SDK's built-in retry mechanism with exponential backoff and jitter.

Cevap

Configure the client application to retry failed writes using the AWS SDK's built-in retry mechanism with exponential backoff and jitter.

The correct option is to configure the client application to retry failed writes using the AWS SDK's built-in retry mechanism with exponential backoff and jitter. When DynamoDB throws a ProvisionedThroughputExceededException, it is often a transient error due to a brief spike in traffic. Implementing client-side retries with exponential backoff and jitter allows the client to pause, back off, and retry the request, which successfully handles the throttling event without requiring database schema changes or capacity increases.

Adım Adım Çözüm

Identify the cause of the application failures.

The application crashes due to ProvisionedThroughputExceededException errors from transient burst traffic without any retry handling.

Understanding the transient nature of the spike explains why the client-side configuration needs adjustment rather than database re-provisioning.

Implement the retry strategy in the client code.

The client application automatically pauses and retries requests when throttled, spacing them out using exponential backoff and jitter.

This prevents the client from overwhelming the database with immediate retries and allows transient traffic spikes to clear.

Anahtar Kavram

Handling ProvisionedThroughputExceededException with Client-Side Retry Policies

Soru 18Soru →

A developer is deploying a Go web application to Amazon ECS using the EC2 launch type. The application is instrumented with the AWS X-Ray SDK for Go to trace incoming HTTP requests and downstream calls to Amazon DynamoDB. The ECS task definition is configured with the awsvpc network mode and currently contains only the application container. During testing, no trace data is appearing in the AWS X-Ray console. When inspecting the container logs, the developer finds multiple errors stating that the application is unable to connect to the X-Ray daemon at 127.0.0.1:2000. Which of the following actions should the developer take to resolve this issue? (Select TWO.)

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

Add a sidecar container to the ECS task definition using the official AWS X-Ray daemon image.

Attach the AWSXRayWriteOnlyAccess policy to the IAM role specified as the ECS Task Role (taskRoleArn).

Set the visibility timeout of downstream Amazon SQS queues to be greater than the application processing time to prevent trace context propagation from failing.

Update the API Gateway integration to custom integration mode to ensure the raw tracing header is correctly mapped to the container environment.

Initialize the Go SDK client using hardcoded AWS access keys and secret keys in the application source code to authenticate with the X-Ray daemon's UDP endpoint.

Cevabı ve açıklamayı göster

Cevap: Add a sidecar container to the ECS task definition using the official AWS X-Ray daemon image.; Attach the AWSXRayWriteOnlyAccess policy to the IAM role specified as the ECS Task Role (taskRoleArn).

Cevap

To resolve the tracing issue, the developer must add a sidecar container running the official AWS X-Ray daemon image to the ECS task definition and attach the AWSXRayWriteOnlyAccess policy to the ECS Task Role.

The correct actions are to add the AWS X-Ray daemon container as a sidecar and to grant the task role write access to X-Ray. In Amazon ECS with awsvpc network mode, containers in the same task share the network namespace, allowing them to communicate via localhost (127.0.0.1). Adding the daemon container enables the application to reach it over port 2000. Additionally, the daemon container requires the correct IAM permissions via the ECS Task Role to write traces to the X-Ray service.

Adım Adım Çözüm

Analyze the log error message pointing to UDP connection refused at 127.0.0.1:2000.

Identify that the X-Ray daemon is not running or accessible within the task's network namespace.

The X-Ray SDK sends trace segments to the daemon via UDP port 2000 by default, which requires the daemon to be running locally.

Add the AWS X-Ray daemon container to the ECS task definition.

The daemon container starts in the same task network namespace and binds to port 2000, resolving the connection refused errors.

In awsvpc mode, all containers in a task share the localhost network interface, allowing direct communication.

Assign write permissions to the ECS Task Role.

Attach the AWSXRayWriteOnlyAccess policy to the Task Role so the daemon container can upload segments to the AWS X-Ray backend.

The task requires IAM authorization to authenticate with and send trace data to the X-Ray API.

Anahtar Kavram

ECS sidecar pattern deployment of the AWS X-Ray daemon and task role permission requirements.

Soru 19Soru →

An agricultural IoT platform named AgriGrow records hourly soil telemetry data from millions of sensors deployed across global farms. The data is written to an Amazon DynamoDB table with a partition key of `FarmID` (UUID) and a sort key of `Timestamp` (ISO 8601 string). During a sudden regional weather event, the platform experiences a massive surge in sensor writes. The application starts receiving `ProvisionedThroughputExceededException` errors. CloudWatch metrics indicate that the table's total consumed Write Capacity Units (WCUs) are far below the total provisioned write capacity. The developer finds that a single large farm has thousands of active sensors writing simultaneously, creating a hot partition. The telemetry client currently fails immediately when a write is throttled. Which TWO actions should the developer take to resolve the write throttling and minimize client-side errors? (Select TWO.)

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

Append a random numeric suffix to the `FarmID` partition key during write operations to distribute the write volume across multiple physical partitions.

Configure the application client's AWS SDK to implement exponential backoff and jitter for request retries.

Increase the provisioned Write Capacity Units (WCUs) of the DynamoDB table to absorb the peak write throughput of the hot partitions.

Modify the application retrieval logic to use `Scan` operations with a filter expression instead of `Query` operations to read the telemetry records.

Increase the Amazon SQS visibility timeout of the queue processing the telemetry events to allow more time for DynamoDB writes to succeed.

Cevabı ve açıklamayı göster

Cevap: Append a random numeric suffix to the `FarmID` partition key during write operations to distribute the write volume across multiple physical partitions.; Configure the application client's AWS SDK to implement exponential backoff and jitter for request retries.

Cevap

The developer should append a random numeric suffix to the partition key during write operations to distribute the write traffic, and configure the application SDK client to use exponential backoff and jitter for retrying throttled requests.

The correct actions are to append a random numeric suffix to the partition key (write sharding) and configure exponential backoff and jitter in the SDK client. In DynamoDB, each physical partition has a maximum write limit of

1000

WCUs per second. When writes to a single partition key exceed this threshold, the requests are throttled, generating a ProvisionedThroughputExceededException. Appending a random suffix distributes the write traffic across multiple partition keys and physical partitions. Concurrently, configuring the client SDK with exponential backoff and jitter prevents immediate client-side failures by spreading out retries over randomized intervals during traffic spikes.

Adım Adım Çözüm

Analyze the error metrics and root cause.

Identify that the ProvisionedThroughputExceededException is occurring due to a hot partition (a single FarmID key receiving excessive write throughput) rather than the overall table-level capacity being exceeded.

DynamoDB partitions have a hard limit of

1000

WCUs per second for writes. If this limit is exceeded on a single partition key, throttling occurs even if the table has spare capacity.

Select a strategy to distribute the write load.

Implement write sharding by appending a random integer suffix (e.g., from

1

N

) to the FarmID partition key when writing data.

This spreads writes across

N

distinct partition keys, distributing the workload across multiple physical partitions and bypassing the

1000

WCU single-partition limit.

Configure the client retry behavior.

Modify the AWS SDK client settings to use exponential backoff and jitter.

Since the client currently fails immediately upon throttling, enabling backoff and jitter allows the client to retry requests after a randomized, increasing delay, which handles transient spikes gracefully.

Anahtar Kavram

DynamoDB partition write limitations and write sharding techniques

Tahmini Süre:2m 0s

Soru 20Soru →

A developer is troubleshooting a local Node.js application that uses the AWS SDK for JavaScript (v3) to query an Amazon DynamoDB table. The local development machine has the environment variables `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` set to credentials of a retired testing account, which causes authentication failures. The developer has a local shared credentials file (`~/.aws/credentials`) with a profile named `local-dev` that contains active credentials for the development environment. The client is initialized in the code as follows:

javascript
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
const client = new DynamoDBClient({});

Which of the following actions will resolve this credential resolution issue and ensure the application authenticates using the `local-dev` profile? (Select TWO.)

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

Unset the `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` environment variables, and set the `AWS_PROFILE` environment variable to `local-dev`.

Import the `fromIni` credential provider from `@aws-sdk/credential-providers` and pass it to the `credentials` configuration option of the `DynamoDBClient` constructor, specifying the `local-dev` profile.

Set the `AWS_DEFAULT_PROFILE` environment variable to `local-dev` and verify that the `AWS_PROFILE` environment variable is unset.

Initialize the `DynamoDBClient` by hardcoding the `local-dev` access key ID and secret access key directly into the client constructor configuration object.

Store the `local-dev` credentials as a `SecureString` parameter in AWS Systems Manager Parameter Store, and set the `AWS_SSM_CREDENTIALS_PATH` environment variable to point to the parameter.

Cevabı ve açıklamayı göster

Cevap: Unset the `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` environment variables, and set the `AWS_PROFILE` environment variable to `local-dev`.; Import the `fromIni` credential provider from `@aws-sdk/credential-providers` and pass it to the `credentials` configuration option of the `DynamoDBClient` constructor, specifying the `local-dev` profile.

Cevap

To resolve the credential resolution issue, the developer can either unset the credentials environment variables and set the profile environment variable to specify the profile, or configure the client explicitly using the `fromIni` provider from the credential providers library to load the profile.

To resolve the credential resolution issue, the developer can either clean up the environment or configure the application client explicitly. In the default credential provider chain, environment variables containing credentials have the highest precedence. Therefore, removing the retired credentials environment variables and setting the profile environment variable forces the SDK to fall back to the shared credentials file and load the specified profile. Alternatively, explicitly configuring the client constructor with the `fromIni` provider overrides the default provider chain entirely, forcing the application to load the local-dev profile credentials directly from the local configuration files.

Adım Adım Çözüm

Analyze the AWS SDK credential provider chain precedence.

Identify that environment variables containing credentials take precedence over configuration profiles and the shared credentials file.

This explains why the application uses the retired credentials instead of the local-dev profile.

Determine how to modify the environment to allow profile-based authentication.

Unsetting the credentials environment variables enables the SDK to fall back to the shared credentials file, where the profile specified by the profile environment variable will be used.

This allows the default chain to resolve the local-dev profile credentials.

Determine how to modify the application code to explicitly bypass the default credential provider chain.

Import and use the `fromIni` provider from `@aws-sdk/credential-providers` to explicitly load credentials from the local-dev profile.

This overrides the default credential provider chain and avoids using the environment variables.

Anahtar Kavram

AWS SDK credential provider chain precedence and local profile configuration.

Tahmini Süre:2m 0s

Sayfa 1 / 14Sonraki

Troubleshooting and Optimization

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

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

Cevap

Adım Adım Çözüm