Examkin

Question

Difficulty: MediumInstrumenting Distributed Tracing with AWS X-Ray

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.)

  1. Add a sidecar container to the ECS task definition using the official AWS X-Ray daemon image.Answer
  2. Attach the AWSXRayWriteOnlyAccess policy to the IAM role specified as the ECS Task Role (taskRoleArn).Answer
  3. C
    Set the visibility timeout of downstream Amazon SQS queues to be greater than the application processing time to prevent trace context propagation from failing.
  4. D
    Update the API Gateway integration to custom integration mode to ensure the raw tracing header is correctly mapped to the container environment.
  5. E
    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.

Answer

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.

Step-by-Step Solution

1
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.
2
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.
3
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.

Key Concept

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

Topics

Instrumenting Distributed Tracing with AWS X-Ray

More questions from this topic