Troubleshooting and Optimization

271 soru

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

An analytics application utilizes an AWS Lambda function to generate daily reports. The function downloads several source files to the local ephemeral storage (`/tmp`), merges them, and uploads the final report to Amazon S3. The function is configured with $512\text{ MB}$ of ephemeral storage. While initial test runs succeed, the function intermittently fails during peak hours with a `No space left on device` error, even though the source files for any single invocation never exceed $100\text{ MB}$ in total. What is the root cause of this failure, and how should the developer resolve it?

The execution context is being reused across invocations, causing files from previous runs to persist in the `/tmp` directory. The developer should modify the code to delete temporary files from `/tmp` before the function execution completes.

The developer assumed that the ephemeral storage is automatically wiped by Lambda between warm starts. The developer should increase the Lambda function's execution timeout limit to allow the platform's automatic background garbage collector to clean up the directory.

The Lambda function is deployed in a private VPC subnet without a NAT Gateway or VPC endpoint to access the Amazon S3 service. The developer should configure a NAT Gateway in the public subnet and update the route tables to allow the function to upload the files and free up storage.

The Lambda function's execution role trust policy is missing the `lambda.amazonaws.com` service principal, preventing the function from writing log streams to CloudWatch and causing local write buffers to overflow. The developer should modify the trust policy to allow the service principal.

Cevabı ve açıklamayı göster

Cevap: The execution context is being reused across invocations, causing files from previous runs to persist in the `/tmp` directory. The developer should modify the code to delete temporary files from `/tmp` before the function execution completes.

Cevap

The correct answer is the option explaining that the execution context is reused across invocations, which preserves files in the `/tmp` directory. To resolve the issue, the developer must explicitly delete the files before the invocation ends. AWS Lambda reuses execution environments to avoid cold start overhead. When an environment is reused, the state of the `/tmp` directory is maintained. If a function writes files to `/tmp` and does not clean them up, subsequent invocations in the same environment will find those files still present, leading to cumulative disk usage and eventual disk exhaustion.

Adım Adım Çözüm

Analyze the error message and context.

The `No space left on device` error indicates that the local disk storage under `/tmp` is fully exhausted, despite the current invocation's files being well below the

512\text{ MB}

limit.

This discrepancy suggests that storage space is leaking across separate execution events, pointing to a persistent state issue in the Lambda runtime environment.

Evaluate the behavior of Lambda ephemeral storage during execution context reuse.

AWS Lambda reuses execution environments for subsequent invocations (warm starts) to improve response times. Files stored in `/tmp` are preserved during this reuse.

Since the function download logic writes files but does not delete them, these files accumulate over successive invocations in a reused execution context until the disk space is depleted.

Determine the appropriate correction method.

Implement cleanup logic in the Lambda handler code to delete the files from `/tmp` right before the handler returns or finishes processing.

Explicitly deleting files ensures that each invocation starts or ends with a clean `/tmp` directory, preventing cumulative disk usage across reused execution environments.

Anahtar Kavram

AWS Lambda reuses its execution context (including the `/tmp` directory) across sequential invocations (warm starts). Developers must explicitly clean up any ephemeral storage files to prevent disk exhaustion over time.

Soru 102Soru →

A client-side single-page dashboard application hosted on `https://internal-app.net` sends a `DELETE` request to a backend API. The API is hosted on Amazon API Gateway and integrated with a backend AWS Lambda function using a Lambda proxy integration. During testing, the browser console shows that the `DELETE` request is blocked due to a missing CORS header during the preflight check. Furthermore, direct invocations of the endpoint using a command-line tool result in a `502 Bad Gateway` error with the message 'Malformatted Lambda proxy response' in the CloudWatch logs. Which two actions must the developer take to resolve both the CORS preflight block and the integration error?

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

Enable CORS on the API Gateway resource to create an OPTIONS method that returns the required Access-Control-Allow-Methods and Access-Control-Allow-Origin headers.

Modify the backend Lambda function's return payload to be a JSON object containing the statusCode integer, a headers object with the Access-Control-Allow-Origin header, and a stringified body.

Add the Access-Control-Allow-Origin header to the CORS configuration of the Amazon S3 bucket where the frontend dashboard application is hosted.

Configure an Integration Response mapping template in API Gateway to transform the Lambda function's raw output string into a structured JSON response.

Configure a Lambda authorizer on the API Gateway method to validate the Origin header and return an IAM policy allowing the execute-api:Invoke action.

Cevabı ve açıklamayı göster

Cevap: Enable CORS on the API Gateway resource to create an OPTIONS method that returns the required Access-Control-Allow-Methods and Access-Control-Allow-Origin headers.; Modify the backend Lambda function's return payload to be a JSON object containing the statusCode integer, a headers object with the Access-Control-Allow-Origin header, and a stringified body.

Cevap

Enable CORS on the API Gateway resource to create an OPTIONS method that returns the required Access-Control-Allow-Methods and Access-Control-Allow-Origin headers, and modify the backend Lambda function's return payload to be a JSON object containing the statusCode integer, a headers object with the Access-Control-Allow-Origin header, and a stringified body.

The correct options resolve both issues: first, enabling CORS on the API Gateway resource creates the OPTIONS method to handle the browser's preflight request; second, formatting the Lambda response as a JSON object with statusCode, headers (including the CORS header), and body complies with Lambda proxy integration rules and resolves the 502 Bad Gateway error.

Adım Adım Çözüm

Configure preflight handling by enabling CORS on the API Gateway resource.

An OPTIONS method is created that returns the Access-Control-Allow-Methods, Access-Control-Allow-Headers, and Access-Control-Allow-Origin headers, satisfying the browser's preflight check.

Before sending a non-simple request like DELETE, the browser initiates a preflight OPTIONS request to verify CORS permissions.

Ensure the Lambda function returns a valid proxy integration JSON payload.

The Lambda function returns a response object with statusCode, headers (including Access-Control-Allow-Origin), and body.

In a Lambda proxy integration, API Gateway expects a specific JSON format. Returning a raw string causes a 502 Bad Gateway error. Additionally, proxy integrations require the backend function to return the CORS headers for the actual request.

Anahtar Kavram

API Gateway Lambda proxy integrations require both a preflight OPTIONS method configured at the API Gateway level and a properly formatted JSON response containing the status code, headers (including CORS headers), and body returned directly from the Lambda function.

Tahmini Süre:2m 0s

Soru 103Soru →

An order processing service runs on AWS Lambda. To comply with security guidelines, this function is attached to private subnets within a VPC to query an Amazon Aurora database. As part of its execution, the function must also call an external payment gateway API over the internet. Although the database queries succeed, all external API calls timeout. What configuration change is required to allow the function to connect to the external API?

Relocate the Lambda function configuration from the private subnets to the public subnets of the VPC to grant it a public IP address.

Create a NAT gateway in a public subnet of the VPC and configure a route for outbound internet traffic in the private subnet's route table.

Extend the execution timeout of the Lambda function to allow more time for the external API requests to complete.

Update the Lambda function's IAM execution role trust policy to allow the VPC endpoints to assume the role.

Cevabı ve açıklamayı göster

Cevap: Create a NAT gateway in a public subnet of the VPC and configure a route for outbound internet traffic in the private subnet's route table.

Cevap

Create a NAT gateway in a public subnet of the VPC and configure a route for outbound internet traffic in the private subnet's route table.

The correct action is to create a NAT gateway in a public subnet and configure a route in the private subnet's route table. When a Lambda function is configured to run inside a VPC, it does not have direct internet access. To access an external API, outbound internet traffic must be routed through a NAT gateway located in a public subnet.

Adım Adım Çözüm

Analyze the networking configuration of the Lambda function.

The Lambda function is running in private subnets of a VPC, allowing it to connect to the internal database but blocking direct internet access.

By default, a Lambda function inside a VPC has no internet access.

Identify the destination of the failed network request.

The function is attempting to reach an external payment gateway API over the public internet.

Knowing the target is internet-based determines whether we need internet routing (NAT gateway) or a VPC endpoint.

Select the correct AWS network component to bridge the private VPC subnets to the public internet.

A NAT gateway placed in a public subnet with appropriate route table entries allows the private subnets to reach the internet.

This establishes outbound-only internet connectivity for resources in private subnets.

Anahtar Kavram

VPC Networking for AWS Lambda

Soru 104Soru →

A developer is troubleshooting an AWS Lambda function written in Python that is triggered by an Amazon API Gateway REST API. When a client sends a request, the function queries Amazon DynamoDB and then queries an external PostgreSQL database. The developer has enabled active tracing on the Lambda function. Although the API Gateway and Lambda service execution segments appear in the AWS X-Ray service map, downstream calls to DynamoDB and the PostgreSQL database are completely missing. Which two actions must the developer take to capture these downstream calls in the X-Ray trace?

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

Call patch_all() from the aws_xray_sdk.core module at application startup to automatically instrument downstream calls made via the boto3 library.

Wrap the PostgreSQL database connection library using the AWS X-Ray SDK's patch function or database wrappers to instrument SQL queries.

Initialize the AWS SDK clients by hardcoding an AWS IAM access key and secret access key that have the xray:PutTraceSegments permission.

Increase the execution timeout of the Lambda function to allow the X-Ray daemon helper thread to flush traces before the runtime container freezes.

Configure API Gateway to use a custom Lambda integration instead of a Lambda proxy integration to ensure that the trace header is parsed and passed in the JSON payload.

Cevabı ve açıklamayı göster

Cevap: Call patch_all() from the aws_xray_sdk.core module at application startup to automatically instrument downstream calls made via the boto3 library.; Wrap the PostgreSQL database connection library using the AWS X-Ray SDK's patch function or database wrappers to instrument SQL queries.

Cevap

To capture downstream AWS SDK and database calls in AWS X-Ray, the developer must call patch_all() to instrument boto3 and wrap the database connection library with the X-Ray SDK's database wrappers.

To trace downstream dependencies with AWS X-Ray in a Python Lambda function, active tracing must be paired with application-level SDK instrumentation. Calling the patch_all function from the X-Ray SDK dynamically patches boto3, enabling tracing for all AWS SDK calls (like DynamoDB). To trace external database queries, the database client library must also be wrapped or patched by the X-Ray SDK.

Adım Adım Çözüm

Patch the AWS SDK client.

The boto3 library is patched with the X-Ray SDK.

This allows X-Ray to intercept all downstream AWS service requests (such as DynamoDB calls) and create subsegments automatically.

Patch the third-party database library.

The SQL driver is wrapped with X-Ray instrumentation.

This captures SQL database queries as subsegments and visualizes them on the X-Ray service map.

Anahtar Kavram

AWS X-Ray SDK instrumentation for downstream dependencies

Soru 105Soru →

A developer has a distributed application where a producer service running on Amazon ECS Fargate sends tasks to an Amazon SQS queue. A consumer service, also running on Amazon ECS Fargate, polls the queue and processes the tasks. Both services use the AWS SDK and are configured with the AWS X-Ray SDK, with active tracing enabled where applicable and the AWS SDK clients properly patched.

When viewing the traces in the AWS X-Ray console, the developer observes two disconnected traces: one for the producer service sending the message, and another separate trace for the consumer service processing the task. The end-to-end transaction is not correlated.

Which action should the developer take to resolve this issue and trace the request end-to-end?

Enable active tracing on the Amazon SQS queue configuration via the AWS Management Console to allow the queue to act as a segment coordinator.

Modify the consumer service code to extract the AWSTraceHeader from the SQS message system attributes, and use it to construct and set the parent segment context in the AWS X-Ray SDK.

Increase the visibility timeout of the Amazon SQS queue to ensure that the consumer service has enough time to write trace segments to the AWS X-Ray daemon before the message returns to the queue.

Configure the AWS X-Ray SDK on the consumer service using hardcoded AWS IAM credentials with xray:PutTraceSegments permissions in the application source code to authorize the segment creation.

Cevabı ve açıklamayı göster

Cevap: Modify the consumer service code to extract the AWSTraceHeader from the SQS message system attributes, and use it to construct and set the parent segment context in the AWS X-Ray SDK.

Cevap

Modify the consumer service code to extract the AWSTraceHeader from the SQS message system attributes, and use it to construct and set the parent segment context in the AWS X-Ray SDK.

The correct answer is to modify the consumer service code to extract the AWSTraceHeader from the SQS message system attributes, and use it to construct and set the parent segment context. When using a self-managed worker (such as on ECS Fargate or EC2) to process SQS messages, the SDK does not automatically extract the tracing header. The developer must manually parse the AWSTraceHeader system attribute and initialize the segment context with it, which links the consumer's trace to the producer's trace.

Adım Adım Çözüm

Identify the boundary where tracing context is lost.

The boundary is the Amazon SQS queue, where the producer sends a message and the consumer on ECS Fargate retrieves it. The trace splits into two disconnected traces.

Since the consumer is running on ECS Fargate (rather than AWS Lambda, which automatically handles SQS trace context propagation), the X-Ray SDK on the consumer does not automatically know how to link the processing logic to the incoming message's trace context.

Locate where the tracing header is transmitted within Amazon SQS.

The AWS SDK automatically injects the AWSTraceHeader into the message's system attributes when the producer sends the message.

This header contains the trace ID, parent segment ID, and sampling decision.

Extract the trace header and initialize the segment in the consumer service code.

The consumer reads the AWSTraceHeader from the SQS message attributes and initializes a new segment (or subsegment) with this header as the parent context.

By explicitly setting the parent context using the extracted trace header, the X-Ray SDK links the consumer's execution to the producer's trace, restoring end-to-end correlation.

Anahtar Kavram

Manual trace context propagation across asynchronous boundaries with non-Lambda consumers

Soru 106Soru →

A developer has built a serverless application where an AWS Lambda function, written in Python, processes payment reports. The Lambda function is configured to run inside a VPC, attached to two private subnets, to securely access a private Amazon RDS PostgreSQL database.

As part of the processing logic, the Lambda function must perform the following actions:
1. Connect to the RDS database to fetch payment transactions.
2. Query a public external credit rating API via HTTPS to validate client records.
3. Download a standard currency conversion schema from a public Amazon S3 bucket.

During testing, the Lambda function consistently runs for its maximum configured timeout of $3$ seconds and then terminates with a `Task timed out after 3.00 seconds` error. The Amazon CloudWatch logs indicate that the connection to the RDS database is established successfully, but the connections to both the external credit rating API and Amazon S3 fail to connect.

Which combination of actions should the developer take to resolve these connectivity and execution timeout issues? (Select TWO.)

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

Deploy a NAT Gateway in a public subnet of the VPC, and update the private subnets' route tables to direct internet-bound traffic (

0.0.0.0/0

) to the NAT Gateway.

Increase the Lambda function's timeout configuration to a value greater than

3

seconds (such as

15

seconds) to accommodate network transit and API latency.

Relocate the Lambda function to the public subnets of the VPC and enable the auto-assign public IP option on those subnets to establish direct internet access.

Create an Internet Gateway and associate it directly with the private subnets' route tables to provide an outbound pathway for the Lambda function.

Configure the Lambda function to tear down and recreate the database connection pool at the end of each handler execution to clear the cached execution context.

Cevabı ve açıklamayı göster

Cevap: Deploy a NAT Gateway in a public subnet of the VPC, and update the private subnets' route tables to direct internet-bound traffic ( $0.0.0.0/0$ ) to the NAT Gateway.; Increase the Lambda function's timeout configuration to a value greater than $3$ seconds (such as $15$ seconds) to accommodate network transit and API latency.

Cevap

Deploy a NAT Gateway in a public subnet of the VPC and update the private subnets' route tables to route internet traffic to it, and increase the Lambda function's timeout configuration to a value greater than

3

seconds.

The correct answers describe deploying a NAT Gateway in a public subnet to allow the private-subnet Lambda function to reach the public internet (for S3 and the external API), and increasing the function's timeout configuration to accommodate the network transit time and database operations. These two adjustments work together to resolve both the networking bottleneck and the execution duration limitation.

Adım Adım Çözüm

Diagnose the routing issue by reviewing subnets and endpoints.

The Lambda function is running in private VPC subnets with no route to the internet, causing external HTTP/HTTPS calls to time out.

VPC-enabled Lambda functions require a NAT Gateway (or VPC Endpoints) to reach endpoints outside the VPC.

Establish outbound connectivity for public endpoints.

Deploy a NAT Gateway in a public subnet and route traffic destined for

0.0.0.0/0

from the private subnets to the NAT Gateway.

This configuration allows the Lambda function to securely reach both the external API and the public S3 bucket.

Adjust the execution configuration of the Lambda function.

Increase the timeout configuration from

3

seconds to a higher limit (e.g.,

15

seconds).

The execution environment needs sufficient time to establish connections, query the database, and receive external API responses without timing out prematurely.

Anahtar Kavram

VPC networking configurations and execution environment settings for AWS Lambda functions

Soru 107Soru →

A developer is deploying a Node.js application to Amazon ECS on AWS Fargate. The developer wants to instrument the application to send distributed tracing data to AWS X-Ray. The developer includes the AWS X-Ray SDK in the application code and configures the SDK to instrument incoming HTTP requests. However, after deployment, no traces appear in the AWS X-Ray console, and the application logs show errors indicating that connection to the X-Ray daemon on port 2000 failed. Which of the following actions should the developer take to resolve this issue and enable successful tracing?

Create a sidecar container for the AWS X-Ray daemon in the ECS task definition, and attach the AWSXRayDaemonWriteAccess policy to the ECS task role.

Create a sidecar container for the AWS X-Ray daemon in the ECS task definition, and attach the AWSXRayDaemonWriteAccess policy to the ECS task execution role.

Initialize the AWS SDK clients within the Node.js application by passing hardcoded IAM credentials containing the AWSXRayDaemonWriteAccess policy directly into the constructors.

Set the AWS_XRAY_CONTEXT_MISSING environment variable to IGNORE_ERROR to allow the SDK to function without a running X-Ray daemon.

Cevabı ve açıklamayı göster

Cevap: Create a sidecar container for the AWS X-Ray daemon in the ECS task definition, and attach the AWSXRayDaemonWriteAccess policy to the ECS task role.

Cevap

Create a sidecar container for the AWS X-Ray daemon in the ECS task definition, and attach the AWSXRayDaemonWriteAccess policy to the ECS task role.

To instrument an application running on Amazon ECS with Fargate, the AWS X-Ray daemon must be run as a sidecar container in the same task definition. Because Fargate tasks use the awsvpc network mode, the application container can communicate with the daemon container over localhost (127.0.0.1) on UDP port 2000. Additionally, the ECS Task Role must have the necessary permissions (such as AWSXRayDaemonWriteAccess) to allow the daemon to upload segment data to the AWS X-Ray service. The Task Role defines permissions for the containers running inside the task.

Adım Adım Çözüm

Analyze application logs showing connection failure to the X-Ray daemon on port 2000.

Identify that the X-Ray daemon is either not running or is unreachable by the application container.

On ECS Fargate, applications communicate with the X-Ray daemon over UDP localhost (127.0.0.1:2000), which requires the daemon to be running inside the same task.

Configure the X-Ray daemon as a sidecar container in the ECS task definition.

The daemon starts inside the same network namespace, making port 2000 reachable by the application container over localhost.

This establishes local UDP network connectivity between the application's X-Ray SDK client and the X-Ray daemon.

Attach the AWSXRayDaemonWriteAccess managed policy to the ECS Task Role.

The X-Ray daemon has permissions to send trace segments to the AWS X-Ray service endpoint at runtime.

The Task Role provides credentials to the running containers, unlike the Task Execution Role, which is only used by the ECS agent for pulling images and publishing startup logs.

Anahtar Kavram

Instrumenting Distributed Tracing with AWS X-Ray on Amazon ECS

Soru 108Soru →

A developer wants to create an Amazon CloudWatch metric filter to count occurrences of the term 'AccessDenied' in a plain text log group. The developer attempts to use the following CloudWatch Logs Insights query syntax as the metric filter pattern:

`fields @message | filter @message like /AccessDenied/`

However, the metric is not being incremented even when 'AccessDenied' appears in the logs.

Which of the following is the correct explanation and resolution for this issue?

Metric filters do not support CloudWatch Logs Insights query syntax. The filter pattern should be changed to the literal string 'AccessDenied'.

Metric filters can only parse JSON-formatted logs. The developer must convert the application's logging library output to JSON format to use metric filters.

The metric filter pattern is correct, but the metric does not increment because the IAM execution role of the application generating the logs lacks the 'logs:StartQuery' permission.

The metric filter failed to process the logs because the log group's processing duration exceeded the default execution timeout of the underlying log parser.

Cevabı ve açıklamayı göster

Cevap: Metric filters do not support CloudWatch Logs Insights query syntax. The filter pattern should be changed to the literal string 'AccessDenied'.

Cevap

Metric filters do not support CloudWatch Logs Insights query syntax. The filter pattern should be changed to the literal string 'AccessDenied'.

The correct answer is correct because CloudWatch Logs metric filters and CloudWatch Logs Insights are two distinct features with different syntaxes. Metric filters scan logs during ingestion using basic string matching patterns or JSON properties, and they do not understand the pipe-separated query syntax of Logs Insights. By changing the pattern to the simple string 'AccessDenied', the filter will correctly match any log line containing that term.

Adım Adım Çözüm

Analyze the configured filter pattern syntax.

The developer configured the metric filter pattern with 'fields @message | filter @message like /AccessDenied/', which is a query string designed for CloudWatch Logs Insights.

Identifying the syntax type helps determine if it is compatible with the target service feature (Metric Filters).

Determine compatibility of Logs Insights query syntax with CloudWatch metric filters.

CloudWatch Logs metric filters do not support pipe-delimited query commands or the Logs Insights syntax. They support simple terms, phrases, or JSON object patterns.

Understanding the feature limitations explains why the current configuration is failing to match any log events.

Identify the correct syntax for a basic term match in plain text logs.

For a plain text log, to match a specific keyword, the metric filter pattern should be configured with the keyword itself (e.g., 'AccessDenied' or '"AccessDenied"').

Replacing the invalid query syntax with the correct metric filter pattern resolves the issue and allows the metric to increment.

Anahtar Kavram

CloudWatch Logs metric filters use a simple term-matching or JSON-matching syntax and do not support CloudWatch Logs Insights query syntax.

Soru 109Soru →

A developer is troubleshooting a distributed application. The flow begins with an Amazon API Gateway HTTP API that integrates with an AWS Lambda function. The Lambda function performs some processing and sends an HTTP request to an internal Java-based microservice running on Amazon ECS on AWS Fargate behind an Application Load Balancer (ALB). The Java microservice then writes records to an Amazon DynamoDB table.

Active tracing is enabled on both the API Gateway and the Lambda function. However, in the AWS X-Ray console, the developer observes that:
1. The trace map shows the Lambda function's execution segment, but the Java microservice and the subsequent DynamoDB calls are represented as a separate, disconnected trace map.
2. The DynamoDB calls themselves are missing from the X-Ray service map entirely.

Which two actions should the developer take to resolve these issues and establish continuous, end-to-end trace propagation?

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

In the Lambda function's code, ensure the outgoing HTTP client is instrumented with the AWS X-Ray SDK, or manually retrieve the current trace entity and inject the X-Amzn-Trace-Id header into the HTTP request sent to the ALB.

In the ECS task definition, add a container definition for the aws-xray-daemon, ensure the ECS task role has the xray:PutTraceSegments and xray:PutTelemetryRecords permissions, and configure the Java microservice's AWS SDK clients with the X-Ray SDK's TracingInterceptor.

Configure the ECS task execution role with the xray:PutTraceSegments permission, and configure the Java application to send tracing segments directly to the ALB's DNS name using the X-Ray daemon cluster-wide endpoint.

Change the API Gateway integration type to a Lambda custom integration, and configure a mapping template to extract the X-Amzn-Trace-Id header from API Gateway and pass it as a JSON payload property to the Lambda handler.

Increase the Lambda function's timeout and memory settings to allow the execution context to remain warm long enough for the X-Ray SDK to buffer and flush tracing segments to the daemon before the function container terminates.

Cevabı ve açıklamayı göster

Cevap: In the Lambda function's code, ensure the outgoing HTTP client is instrumented with the AWS X-Ray SDK, or manually retrieve the current trace entity and inject the X-Amzn-Trace-Id header into the HTTP request sent to the ALB.; In the ECS task definition, add a container definition for the aws-xray-daemon, ensure the ECS task role has the xray:PutTraceSegments and xray:PutTelemetryRecords permissions, and configure the Java microservice's AWS SDK clients with the X-Ray SDK's TracingInterceptor.

Cevap

To establish end-to-end trace propagation, the Lambda function must propagate the X-Ray trace header (X-Amzn-Trace-Id) in its outgoing HTTP requests, and the ECS Fargate tasks must run the X-Ray daemon as a sidecar container with the correct IAM Task Role permissions while instrumenting downstream SDK calls.

The correct actions require propagating the trace header from the Lambda function and configuring the X-Ray daemon sidecar and SDK client in ECS Fargate. First, the Lambda function must send the trace context downstream by instrumenting the outgoing HTTP client to add the X-Amzn-Trace-Id header. Second, because Fargate is serverless, the X-Ray daemon cannot be run at the EC2 host level, so it must be added as a sidecar container in the task definition. The application's ECS task role must have permissions to upload the traces, and the AWS SDK clients inside the Java microservice must be instrumented with the TracingInterceptor to record the downstream DynamoDB calls.

Adım Adım Çözüm

Identify the trace gap between the Lambda function and the downstream ECS microservice.

Determine that trace context propagation is missing over the custom HTTP client call to the ALB.

X-Ray context is not automatically propagated across custom HTTP boundaries unless the outgoing HTTP client is instrumented or the header is manually injected.

Determine the requirement for running the X-Ray daemon on AWS ECS Fargate.

Specify the X-Ray daemon container as a sidecar in the ECS Task Definition.

Because ECS Fargate does not allow host-level daemon execution, the daemon must run alongside the application in each task.

Identify the correct IAM role and permissions needed for the ECS container to publish traces.

Assign xray:PutTraceSegments and xray:PutTelemetryRecords to the ECS Task Role.

The Task Role gives permissions to the running application and sidecar containers, whereas the Task Execution Role is only used by the ECS agent for tasks like pulling images.

Instrument the downstream calls from the Java microservice to DynamoDB.

Configure the Java AWS SDK client with the X-Ray SDK's TracingInterceptor.

Without SDK client instrumentation, the AWS SDK calls are not monitored by X-Ray, causing DynamoDB segments to be missing from the trace.

Anahtar Kavram

AWS X-Ray distributed tracing context propagation across HTTP boundaries and daemon sidecar configuration on ECS Fargate.

Tahmini Süre:3m 0s

Soru 110Soru →

A developer is using Docker Compose to locally test a Python application that uses the AWS SDK (Boto3) to retrieve secrets from AWS Secrets Manager. The application runs inside the container under a non-root user account named `appuser` (with home directory `/home/appuser`).

On the host workstation, the developer has configured the AWS CLI with a profile named `local-dev` that contains the necessary IAM permissions. The container fails to authenticate with AWS, raising a `ClientError` indicating that no credentials can be found. The current `docker-compose.yml` file contains the following volume mount:

yaml
volumes:
- ~/.aws:/root/.aws:ro

Which two actions must the developer take to resolve this issue and ensure Boto3 uses the correct credentials? (Select two.)

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

Update the volume mount in the `docker-compose.yml` file to map the host's `~/.aws` directory to `/home/appuser/.aws:ro`.

Add the `AWS_PROFILE=local-dev` environment variable to the container's service environment block in the `docker-compose.yml` file.

Set the `AWS_PROFILE` environment variable to `local-dev` on the host workstation's shell before running `docker-compose up`.

Set the `AWS_SDK_LOAD_CONFIG=true` environment variable in the container and mount the credentials file to `/etc/aws/credentials:ro`.

Configure the AWS Secrets Manager resource policy to allow access from the container's local IP address using a `StringEquals` condition.

Cevabı ve açıklamayı göster

Cevap: Update the volume mount in the `docker-compose.yml` file to map the host's `~/.aws` directory to `/home/appuser/.aws:ro`.; Add the `AWS_PROFILE=local-dev` environment variable to the container's service environment block in the `docker-compose.yml` file.

Cevap

Update the volume mount to target `/home/appuser/.aws:ro` and set the `AWS_PROFILE` environment variable to `local-dev` in the docker-compose file.

The correct actions are to update the volume mount to target `/home/appuser/.aws:ro` and to add the `AWS_PROFILE=local-dev` environment variable in the docker-compose file. Since the application runs under the `appuser` context, Boto3 searches `/home/appuser/.aws` for credentials. Additionally, `AWS_PROFILE` must be set in the container environment so the SDK knows to select the `local-dev` profile rather than falling back to `default`.

Adım Adım Çözüm

Determine the executing user context within the container.

The application runs as `appuser`, which means Boto3 will look for config/credentials in `/home/appuser/.aws` instead of `/root/.aws`.

SDKs resolve credentials relative to the home directory of the current user executing the process.

Adjust the volume mounting path to match the user's home directory.

Map the host's `~/.aws` directory to `/home/appuser/.aws` inside the container.

This makes the host's AWS profiles accessible to Boto3 running under the `appuser` account.

Ensure the container processes use the correct profile.

Define the `AWS_PROFILE` environment variable as `local-dev` in the container's environment definition.

By default, the SDK looks for the `default` profile. Defining the profile name via `AWS_PROFILE` forces the SDK to load the `local-dev` configuration.

Anahtar Kavram

Credential resolution in containerized environments relies on correct volume mounting to the active user's home directory and explicit passing of environment variables like AWS_PROFILE.

Soru 111Soru →

A containerized Node.js application is deployed on Amazon ECS using the AWS Fargate launch type. The application processes incoming HTTP requests and offloads compute-heavy processing and downstream database writes to asynchronous worker threads using the Node.js worker_threads module. The application uses the AWS X-Ray SDK to capture traces. The developer has enabled the AWS X-Ray daemon in a sidecar container and initialized the SDK using AWSXRay.captureAWS(AWS). However, the application logs show 'SegmentNotFoundException: Failed to get the current sub/segment from the context' during DynamoDB writes inside the worker threads, and these downstream calls are missing from the X-Ray traces. Which action should the developer take to resolve this issue?

Initialize the DynamoDB client inside the worker thread by hardcoding temporary IAM credentials retrieved from a custom metadata endpoint, ensuring the worker thread has explicit write permissions for AWS X-Ray.

Increase the task-level CPU allocation and configure the client HTTP timeout setting in the AWS SDK configuration within the worker thread to prevent execution context expiration.

Extract the current tracing header in the parent thread using the X-Ray SDK, pass it to the worker thread, and manually initialize and set the segment context in the worker thread before invoking the DynamoDB client.

Increase the visibility timeout of the Amazon SQS queue that feeds tasks to the application to prevent the tracing context from being prematurely deleted from the queue before the worker thread executes.

Cevabı ve açıklamayı göster

Cevap: Extract the current tracing header in the parent thread using the X-Ray SDK, pass it to the worker thread, and manually initialize and set the segment context in the worker thread before invoking the DynamoDB client.

Cevap

The correct action is to extract the current trace header from the parent thread and pass it to the worker thread. Because the AWS X-Ray SDK for Node.js uses continuation-local storage (CLS) to track the active trace context, this context is lost when spawning a new worker thread. The developer must manually pass the trace header string, instantiate a new segment/subsegment using this header in the worker thread, and set it as the active context using the SDK.

Adım Adım Çözüm

Retrieve the trace header from the active segment in the main parent thread using the AWS X-Ray SDK.

The parent thread obtains the trace context string containing the trace ID, parent segment ID, and sampling decision.

The main thread has access to the continuation-local storage where the incoming request's trace context is automatically tracked.

Pass the trace header string as worker data when spawning the worker thread.

The worker thread receives the tracing metadata upon initialization.

Spawning a new thread creates a separate execution context, meaning context tracking via continuation-local storage is not shared by default.

In the worker thread, initialize a new segment or subsegment using the received trace header and set it as the active context using the X-Ray SDK.

The X-Ray SDK in the worker thread now has an active segment context populated in its thread-local storage.

This allows downstream AWS SDK clients in the worker thread to successfully associate their calls with the parent trace rather than throwing a SegmentNotFoundException.

Anahtar Kavram

Manual segment context propagation across asynchronous thread boundaries in the AWS X-Ray SDK.

Soru 112Soru →

A developer has a Python application deployed on Amazon ECS with the AWS Fargate launch type. The application is instrumented using the AWS X-Ray SDK for Python, with `patch_all()` invoked at startup. To improve request throughput, the application uses a `ThreadPoolExecutor` from the `concurrent.futures` module to perform downstream HTTP requests using the `requests` library and write operations to Amazon DynamoDB in parallel worker threads. The X-Ray daemon runs as a sidecar container in the ECS task. When analyzing traces in the AWS X-Ray console, the developer observes that downstream HTTP calls and DynamoDB operations executed within the worker threads are not associated with the main request trace, showing up as separate traces or missing entirely. Which of the following actions should the developer take to resolve this tracing correlation issue?

Set the environment variable `AWS_XRAY_CONTEXT_MISSING` to `IGNORE_ERROR` in the ECS task definition to allow the X-Ray recorder to automatically link detached threads to the parent execution segment.

Retrieve the active trace entity in the parent thread using `xray_recorder.get_trace_entity()`, pass this entity to the worker thread, and call `xray_recorder.set_trace_entity(entity)` inside the worker thread before making the downstream calls.

Initialize the AWS SDK clients within the worker threads using hardcoded IAM access keys and secret keys to authenticate the connection to the X-Ray daemon.

Increase the visibility timeout of the input source queue to ensure that worker threads finish executing and have enough time to flush the local segment buffers to the daemon.

Cevabı ve açıklamayı göster

Cevap: Retrieve the active trace entity in the parent thread using `xray_recorder.get_trace_entity()`, pass this entity to the worker thread, and call `xray_recorder.set_trace_entity(entity)` inside the worker thread before making the downstream calls.

Cevap

The AWS X-Ray SDK for Python stores the tracing context (the current segment or subsegment) in thread-local storage. When the application spawns new threads using a thread pool, the active context is lost because the new thread has its own empty thread-local storage. To resolve this, the active trace entity must be retrieved from the parent thread via `xray_recorder.get_trace_entity()`, passed to the worker thread, and set as the active context using `xray_recorder.set_trace_entity(entity)`. This ensures that downstream HTTP calls and AWS SDK operations executed in the worker threads are correctly attached as subsegments to the parent trace.

Adım Adım Çözüm

Identify why tracing context is lost across threads in the AWS X-Ray SDK for Python.

The SDK uses thread-local storage by default, meaning new threads generated by a thread pool executor do not inherit the parent thread's tracing context.

Understanding thread-local storage helps identify why subsegments generated in child threads appear as orphaned or missing.

Determine the mechanism to pass and set the tracing context across threads.

Retrieve the trace entity from the parent thread with `xray_recorder.get_trace_entity()` and set it in the child thread using `xray_recorder.set_trace_entity(entity)`.

Explicitly setting the trace entity on the child thread's recorder links all subsequent HTTP requests and SDK operations in that thread to the main segment.

Anahtar Kavram

X-Ray context propagation in multi-threaded environments

Tahmini Süre:2m 0s

Soru 113Soru →

A developer has deployed a Node.js-based AWS Lambda function that retrieves user profiles from an Amazon RDS PostgreSQL database. To minimize latency, the database connection client is declared and initialized globally outside the handler function. During load testing with high request volumes, the function performs correctly. However, during periods of low traffic, subsequent requests fail with database connection errors, causing the Lambda function to time out. Which of the following is the most likely cause of this issue?

The Lambda function is configured to run in a private subnet, preventing it from reaching the database endpoint in another subnet without routing through a NAT Gateway.

The function is attempting to reuse a database connection that was established during a previous container execution and has since been closed by the database due to idle timeout.

The IAM execution role assigned to the Lambda function lacks a trust policy that allows the Amazon RDS database service to assume the role.

The function retrieves database credentials from Systems Manager Parameter Store, which does not support caching parameters during container reuse, leading to authentication failures.

Cevabı ve açıklamayı göster

Cevap: The function is attempting to reuse a database connection that was established during a previous container execution and has since been closed by the database due to idle timeout.

Cevap

The Lambda function is attempting to reuse a database connection that was initialized outside the handler function but has since been terminated by the database due to inactivity.

The correct option identifies that the global database client is reused during warm starts. Because of the low-traffic period, the database terminates the idle connection, leaving a stale connection object in the Lambda execution environment. Subsequent handler invocations attempt to reuse this dead connection, causing timeouts.

Adım Adım Çözüm

Analyze the scope of the database connection client declaration in the function code.

The client is declared globally outside the handler function.

Variables declared outside the handler persist across warm starts due to execution environment reuse.

Identify the behavior difference between high-traffic load testing and low-traffic periods.

High-traffic requests succeed because the connection remains active, whereas low-traffic periods allow the database to terminate the idle connection.

Amazon RDS PostgreSQL has default idle connection timeout configurations that terminate inactive TCP connections.

Determine the failure mechanism during the subsequent execution.

The Lambda function attempts to execute query commands over the stale socket, leading to socket hang-ups or TCP timeout errors.

Since the connection client is not re-validated or re-initialized inside the handler, the dead connection is reused.

Anahtar Kavram

AWS Lambda execution environment reuse and global variable persistence (warm starts)

Soru 114Soru →

A developer is hosting a single-page web application in an Amazon S3 bucket. The application makes API calls to an Amazon API Gateway endpoint that is integrated with a Lambda function using Lambda Proxy integration. During testing, the browser console displays a CORS error stating that the preflight request was blocked because the Access-Control-Allow-Origin header is missing. Which two steps must the developer take to resolve this CORS error? (Select TWO.)

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

Configure the API Gateway resource to handle the preflight OPTIONS request and return the Access-Control-Allow-Origin header.

Modify the backend Lambda function to include the Access-Control-Allow-Origin header in its response JSON object.

Configure a CORS policy on the Amazon S3 bucket hosting the frontend application to allow requests from the API Gateway endpoint.

Change the Lambda function to return a plain text string with the headers instead of a structured JSON response.

Deploy a custom Lambda authorizer to generate and inject the Access-Control-Allow-Origin header into the client request.

Cevabı ve açıklamayı göster

Cevap: Configure the API Gateway resource to handle the preflight OPTIONS request and return the Access-Control-Allow-Origin header.; Modify the backend Lambda function to include the Access-Control-Allow-Origin header in its response JSON object.

Cevap

Configure the API Gateway resource to handle the preflight OPTIONS request and modify the backend Lambda function to include the Access-Control-Allow-Origin header in its response JSON object.

To resolve CORS errors when using Amazon API Gateway with Lambda Proxy integration, two actions are required: enabling CORS on the API Gateway resource to handle the OPTIONS preflight request, and modifying the backend Lambda function to return the Access-Control-Allow-Origin header in its response JSON object.

Adım Adım Çözüm

Identify the source of the preflight failure.

Recognize that the browser initiates an OPTIONS preflight request before sending the actual API request.

Before sending non-simple HTTP requests, browsers perform preflight checks to verify allowed origins.

Configure the OPTIONS method response in API Gateway.

Enable CORS on the API Gateway resource to return the Access-Control-Allow-Origin header for the preflight OPTIONS request.

This satisfies the browser's preflight requirements.

Configure the backend response headers.

Update the Lambda function's JSON payload response to include 'Access-Control-Allow-Origin' under the 'headers' object.

For Lambda Proxy integrations, API Gateway does not modify the backend response, requiring the Lambda function to supply the CORS header directly.

Anahtar Kavram

Cross-Origin Resource Sharing (CORS) resolution in API Gateway Lambda Proxy integrations requires both the preflight OPTIONS response from API Gateway and the custom origin headers returned by the Lambda function.

Tahmini Süre:1m 0s

Soru 115Soru →

A developer is troubleshooting a hotel reservation system. A backend microservice runs an AWS Lambda function that processes booking requests. The function is configured to connect to an Amazon Aurora PostgreSQL database deployed in private subnets within a custom VPC. After successfully updating the database, the function makes an HTTPS call to a third-party SMS gateway to send confirmation messages. During testing, database updates succeed, but the Lambda function execution fails. The Amazon CloudWatch logs show that the HTTPS request to the external SMS gateway times out, leading to a function-level timeout error: `Task timed out after $15.03$ seconds`. The VPC configurations are as follows: the Lambda function is associated with the same private subnets as the Aurora database; an Internet Gateway is attached to the VPC; the route tables for the private subnets have a default route ( $0.0.0.0/0$ ) pointing directly to the Internet Gateway; and the security group associated with the Lambda function allows all outbound traffic ( $0.0.0.0/0$ ). Which two actions should the developer take to resolve this network connectivity issue?

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

Deploy a NAT Gateway in a public subnet of the VPC.

Update the route table of the private subnets to direct traffic destined for

0.0.0.0/0

to the NAT Gateway.

Move the Lambda function configuration to use the public subnets of the VPC that have a direct route to the Internet Gateway.

Enable the public IP mapping configuration on the Elastic Network Interfaces (ENIs) created by the Lambda function.

Increase the Lambda function timeout configuration to

15

minutes to accommodate the connection attempts.

Cevabı ve açıklamayı göster

Cevap: Deploy a NAT Gateway in a public subnet of the VPC.; Update the route table of the private subnets to direct traffic destined for $0.0.0.0/0$ to the NAT Gateway.

Cevap

To resolve the network connectivity issue, the developer must deploy a NAT Gateway in a public subnet and update the route tables of the private subnets containing the Lambda function to route outbound internet traffic through the NAT Gateway.

The correct response is to deploy a NAT Gateway in a public subnet and update the private subnet route tables to direct internet-bound traffic (

0.0.0.0/0

) to the NAT Gateway. Lambda functions deployed within a VPC must run in private subnets to access VPC resources like databases. Because Lambda ENIs lack public IP addresses, they cannot communicate with the internet directly via an Internet Gateway. A NAT Gateway situated in a public subnet acts as a bridge, translating the private IP traffic to a public IP and forwarding it to the Internet Gateway.

Adım Adım Çözüm

Analyze the network route requirements of the Lambda function.

The function requires private connectivity to the Aurora database and public connectivity to the third-party SMS gateway.

This determines that both internal VPC and external internet routing paths must be established.

Identify why the direct Internet Gateway route fails for the Lambda function.

Lambda functions in a VPC do not get assigned public IP addresses, meaning they cannot directly use an Internet Gateway even if associated with a public subnet or if a route exists.

This rule explains why the current configuration fails to connect to the external API.

Deploy a NAT Gateway to enable private-to-public network address translation.

A NAT Gateway is created in a public subnet, which has a route to the Internet Gateway.

The NAT Gateway acts as an intermediary that translates private traffic to a public IP.

Configure the private subnets to route outbound traffic through the NAT Gateway.

The route table for the private subnets where the Lambda function resides is updated to direct

0.0.0.0/0

traffic to the NAT Gateway.

This directs the Lambda function's external internet traffic correctly, resolving the timeouts.

Anahtar Kavram

Configuring VPC routing and NAT Gateways for AWS Lambda to access external internet endpoints

Tahmini Süre:2m 0s

Soru 116Soru →

A developer has a Java application running on Amazon EC2 instances. The developer has instrumented the application code using the AWS X-Ray SDK to trace incoming HTTP requests and downstream AWS service calls. However, no trace data is appearing in the AWS X-Ray console. Which TWO actions must the developer take to ensure that trace data is successfully sent to AWS X-Ray?

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

Install and run the AWS X-Ray daemon on the EC2 instances.

Attach an IAM role with the AWSXrayWriteOnlyAccess policy to the EC2 instances.

Configure the AWS SDK client in the code by hardcoding the credentials of an IAM user with X-Ray permissions.

Increase the visibility timeout of the Amazon SQS queue that triggers the application to allow enough time for tracing.

Configure Amazon API Gateway to use a Lambda custom integration to proxy the trace data to the EC2 instances.

Cevabı ve açıklamayı göster

Cevap: Install and run the AWS X-Ray daemon on the EC2 instances.; Attach an IAM role with the AWSXrayWriteOnlyAccess policy to the EC2 instances.

Cevap

To successfully send trace data to AWS X-Ray from Java applications on EC2, the developer must install and run the AWS X-Ray daemon on the EC2 instances and attach an IAM role with the AWSXrayWriteOnlyAccess policy to the EC2 instances.

For an application running on Amazon EC2 to send trace segments to AWS X-Ray, the X-Ray daemon must be installed and running on the EC2 instance to listen on UDP port 2000. Additionally, the instance must have permission to upload trace data, which is provided by attaching an IAM role with the AWSXrayWriteOnlyAccess policy to the EC2 instance.

Adım Adım Çözüm

Enable tracing daemon on the host.

The AWS X-Ray daemon is running on the EC2 instances, listening on UDP port 2000 for trace data sent by the SDK.

The X-Ray SDK sends trace segments to the daemon, which buffers and uploads them to the X-Ray service in batches.

Configure instance permissions.

An IAM role with the AWSXrayWriteOnlyAccess policy is attached to the EC2 instances.

The daemon running on the EC2 instances needs authorization to call the X-Ray API to write trace data.

Anahtar Kavram

AWS X-Ray EC2 configuration requires both the X-Ray daemon running on the host and an IAM instance profile with write permissions to send trace segments to the X-Ray API.

Tahmini Süre:1m 30s

Soru 117Soru →

A frontend Single Page Application (SPA) hosted at `https://dashboard.company.local` makes a cross-origin `POST` request to an Amazon API Gateway REST API configured with a Lambda Proxy Integration. In the browser developer tools, the developer observes that the preflight `OPTIONS` request succeeds with a `200 OK` status code, but the subsequent `POST` request is blocked. The browser console displays: `Access-Control-Allow-Origin 'https://dashboard.company.local' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource`. Additionally, the network tab shows that the `POST` request received a `502 Bad Gateway` status code from API Gateway. Which of the following is the most accurate explanation for this behavior, and what corrective actions should the developer take to resolve both issues?

The Lambda function returned a response payload that does not conform to the required JSON format for Lambda Proxy Integration, causing API Gateway to generate a default 502 Bad Gateway response that lacks the necessary CORS headers. The developer must update the Lambda function to return a structured JSON response containing statusCode, headers (including Access-Control-Allow-Origin), and body, and configure CORS headers on the API Gateway Gateway Responses for 5XX errors.

The CORS headers were only configured on the mock OPTIONS method in API Gateway, which does not propagate to the actual POST integration. The developer must change the integration type to Lambda Custom Integration, configure a custom Integration Response to map CORS headers from the Lambda response, and enable CORS on the S3 bucket hosting the client SPA.

The Lambda function is returning a raw string response because it is configured with Lambda Custom Integration, which requires the frontend to send custom preflight parameters. The developer should change the integration type to Lambda Proxy Integration because proxy integrations automatically inject the required Access-Control-Allow-Origin headers on behalf of the backend Lambda function.

The request failed authentication at the API Gateway level because the custom Lambda Authorizer returned an invalid or expired IAM policy, triggering a 502 error. The developer must modify the Lambda Authorizer to return a policy that allows the OPTIONS method and configure the authorizer to bypass CORS validation for cross-origin client apps.

Cevabı ve açıklamayı göster

Cevap: The Lambda function returned a response payload that does not conform to the required JSON format for Lambda Proxy Integration, causing API Gateway to generate a default 502 Bad Gateway response that lacks the necessary CORS headers. The developer must update the Lambda function to return a structured JSON response containing statusCode, headers (including Access-Control-Allow-Origin), and body, and configure CORS headers on the API Gateway Gateway Responses for 5XX errors.

Cevap

The correct response accurately explains that a 502 Bad Gateway error occurs when the Lambda function output does not conform to the expected schema for Lambda Proxy Integration. Because API Gateway generates this 502 response itself, it bypasses the integration response headers. To fix this, the developer must ensure the Lambda function returns a properly formatted JSON object with 'statusCode', 'headers' (including the 'Access-Control-Allow-Origin' header), and a stringified 'body'. Additionally, to prevent future API Gateway-generated errors from being blocked by CORS, Gateway Responses for 5XX errors must be configured to return the CORS headers.

Adım Adım Çözüm

Inspect CloudWatch Logs for the Lambda function backend.

Identify any formatting errors in the returned payload or unhandled exceptions that prevent Lambda from returning the expected JSON structure.

API Gateway generates a 502 Bad Gateway error when the backend Lambda function output does not match the expected structure required by the Lambda Proxy Integration.

Format the Lambda function's return object according to Lambda Proxy Integration specifications.

Ensure the response dictionary contains 'statusCode', 'body' (as a string), and 'headers' (containing 'Access-Control-Allow-Origin').

Under Lambda Proxy Integration, API Gateway expects the backend code to explicitly define the CORS headers in its response payload.

Configure CORS headers on Gateway Responses for 5XX and 4XX errors in API Gateway.

Ensure that if API Gateway itself encounters an error (e.g., Lambda timeout or gateway error), the browser receives the correct Access-Control-Allow-Origin header to avoid CORS errors masking the HTTP error code.

Default gateway-generated errors do not contain CORS headers unless they are configured in Gateway Responses.

Anahtar Kavram

API Gateway Lambda Proxy Integration response format and CORS troubleshooting

Soru 118Soru →

A developer has a Java-based microservice running on Amazon ECS on AWS Fargate. The microservice reads messages from an Amazon SQS queue, processes them, and writes results to an Amazon DynamoDB table. The developer needs to instrument the application with AWS X-Ray to trace the processing from the SQS queue to the DynamoDB calls. The X-Ray daemon is deployed as a sidecar container in the same task definition. Which two actions should the developer take to configure AWS X-Ray tracing and resolve the missing downstream segments?

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

Add the AWSXRayDaemonWriteAccess policy to the IAM ECS Task Role used by the ECS container.

Configure the AWS SDK for Java client with the TracingInterceptor to intercept and trace calls to DynamoDB.

Add the AWSXRayDaemonWriteAccess policy to the IAM ECS Task Execution Role.

Rely on the Amazon SQS queue to automatically propagate the trace context to DynamoDB without instrumenting the AWS SDK client inside the Java application.

Initialize the DynamoDB client inside the application code by hardcoding temporary IAM user access keys that have X-Ray write permissions.

Cevabı ve açıklamayı göster

Cevap: Add the AWSXRayDaemonWriteAccess policy to the IAM ECS Task Role used by the ECS container.; Configure the AWS SDK for Java client with the TracingInterceptor to intercept and trace calls to DynamoDB.

Cevap

To configure AWS X-Ray tracing for this application, the developer must attach the AWSXRayDaemonWriteAccess policy to the IAM ECS Task Role used by the ECS container, and configure the AWS SDK for Java client with the TracingInterceptor to intercept and trace calls to DynamoDB.

To trace downstream requests to DynamoDB, the developer must instrument the AWS SDK client inside the Java microservice using the AWS X-Ray SDK (for example, by adding TracingInterceptor). In addition, since the X-Ray daemon runs in a sidecar container, it needs permissions to upload segment data to the AWS X-Ray service. These permissions must be attached to the ECS Task Role.

Adım Adım Çözüm

Configure permissions for the X-Ray daemon container to upload traces.

The AWSXRayDaemonWriteAccess policy is attached to the ECS Task Role, allowing the sidecar daemon to communicate with the AWS X-Ray service.

The running container requires runtime permissions to write trace segments.

Instrument the application's AWS SDK clients.

The AWS SDK for Java client is configured with TracingInterceptor.

This allows the application to capture calls to downstream services such as DynamoDB as subsegments in the trace context.

Anahtar Kavram

Instrumenting microservices running on ECS with AWS X-Ray requires both configuring the container's IAM Task Role for write permissions and instrumenting the application's SDK client to record downstream calls.

Soru 119Soru →

A developer is building a fitness tracking web application that retrieves user statistics by calling a REST API. The API is hosted on Amazon API Gateway and uses a Lambda Proxy integration. During testing, the web browser console displays a CORS error indicating that the 'Access-Control-Allow-Origin' header is missing. The developer has already enabled CORS on the API Gateway resources using the AWS Management Console, but the error remains. Which of the following is the correct action to resolve this issue?

Modify the backend Lambda function to return the Access-Control-Allow-Origin header in its response JSON.

Configure a CORS policy on the Amazon S3 bucket hosting the web application to allow requests from the API Gateway URL.

Add the Access-Control-Allow-Origin header to the API Gateway Method Response configuration and redeploy the API.

Create an IAM role that allows the API Gateway execution role to trust the Amazon S3 bucket hosting the application.

Cevabı ve açıklamayı göster

Cevap: Modify the backend Lambda function to return the Access-Control-Allow-Origin header in its response JSON.

Cevap

Modify the backend Lambda function to return the Access-Control-Allow-Origin header in its response JSON.

Under a Lambda Proxy integration, Amazon API Gateway passes the backend response directly to the client without modifying the headers. Therefore, enabling CORS on the API Gateway resource only sets up the preflight OPTIONS endpoint. The developer must update the Lambda function code to return the Access-Control-Allow-Origin header in the headers key of the response JSON payload.

Adım Adım Çözüm

Determine the integration type of the API Gateway resource.

The resource is configured with Lambda Proxy integration.

Integration type dictates how requests and responses are mapped between API Gateway and the backend.

Understand how headers are managed in Lambda Proxy integration.

API Gateway does not modify or inject response headers for proxy integrations.

The backend Lambda function has full control over the response structure, including HTTP headers.

Add the required CORS header to the Lambda function's response payload.

The Lambda function returns a JSON response containing 'Access-Control-Allow-Origin' under the 'headers' key.

This satisfies the browser's origin-check validation for the client request.

Anahtar Kavram

CORS handling in API Gateway Lambda Proxy integrations

Tahmini Süre:1m 0s

Soru 120Soru →

A developer is containerizing a Java application that uses the AWS SDK for Java v2 to read objects from an Amazon S3 bucket. Access to the bucket requires assuming an IAM role. The developer has configured the local development host's `~/.aws/config` file with a profile named `dev-role` that specifies a `role_arn` and a `source_profile`. Running the AWS CLI command `aws s3 ls --profile dev-role` on the host machine successfully lists the bucket contents. However, when the Java application is run inside a local Docker container using the environment variable `AWS_PROFILE=dev-role`, the application fails with a `SdkClientException` indicating that credentials cannot be loaded.

Which two actions should the developer take to resolve this issue? (Choose two.)

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

Mount the host's `~/.aws` directory to the home directory of the user running the application inside the container.

Add the `software.amazon.awssdk:sts` dependency to the application's build file (e.g., `pom.xml`).

Hardcode the AWS Access Key ID and Secret Access Key associated with the target IAM role in the S3 client initialization code.

Modify the IAM trust policy of the target IAM role to trust the private IP address of the local Docker container.

Configure the application to bootstrap credentials from AWS Systems Manager Parameter Store by configuring a custom credential provider.

Cevabı ve açıklamayı göster

Cevap: Mount the host's `~/.aws` directory to the home directory of the user running the application inside the container.; Add the `software.amazon.awssdk:sts` dependency to the application's build file (e.g., `pom.xml`).

Cevap

Mount the host's `~/.aws` directory to the container user's home directory and add the `software.amazon.awssdk:sts` dependency to the application's build file.

The containerized application needs access to the host's AWS credentials configuration, which can be achieved by mounting the host's `~/.aws` directory to the container. Additionally, the AWS SDK for Java v2 requires the `software.amazon.awssdk:sts` dependency to assume the IAM role defined in the profile configuration. Together, these two steps satisfy the credentials requirement without violating security best practices.

Adım Adım Çözüm

Diagnose container isolation.

Identify that the local container has an independent filesystem and cannot read the host's `~/.aws/config` or `~/.aws/credentials` files.

Resolving the profile depends on accessing these configuration files from within the container's execution context.

Mount the credentials directory.

Map the host's `~/.aws` directory to the container user's home directory.

This allows the default credentials provider chain inside the container to read the configuration profiles.

Check SDK classpath dependencies.

Identify that the Java SDK v2 requires the STS module to perform the `AssumeRole` call specified in the profile.

Without the STS library, the SDK fails to instantiate the provider needed to assume the role defined by `role_arn`.

Anahtar Kavram

AWS SDK credentials resolution, credential file mounting in Docker, and the STS dependency requirement in the AWS SDK for Java v2.

Tahmini Süre:2m 0s

ÖncekiSayfa 6 / 14Sonraki

Troubleshooting and Optimization

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

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram