To identify the slowest endpoint, you should sort by a tail latency metric. The p99 latency column represents the response time for the 99th percentile of requests, meaning only 1% of requests are slower. Sorting by p99 latency effectively highlights the endpoints that deliver the worst performance to a segment of users, which is the standard method for finding the "slowest" endpoints that require optimization.

B. Sorting by requests shows the most frequently used endpoints (throughput), not the slowest ones in terms of duration.

C. Total time is a cumulative metric (average latency × request count). A fast but high-traffic endpoint can have a high total time.

E. Error rate measures reliability and the frequency of failed requests, not the duration of successful requests.

1. Datadog Documentation, "Service Page". The documentation describes the Resources tab on the Service Page, which lists all endpoints. It details the available columns for sorting, including latency percentiles like p99, to investigate performance bottlenecks.

2. Datadog Documentation, "Key APM Metrics". This page defines core APM metrics, explaining that p99 latency is a crucial indicator for identifying poor user experience and slow performance.

The Datadog .NET Tracer for Windows applications writes its diagnostic logs to a dedicated directory by default. This location is %ProgramData%\Datadog .NET Tracer\logs\. This path is distinct from the Datadog Agent's log directory, allowing for separate troubleshooting of the tracer and the agent. While the location can be overridden with the DDTRACELOGDIRECTORY environment variable, the question asks for the default location.

B. This is the default log directory for the main Datadog Agent, not the specific .NET Tracer library.

C. This path uses a Linux/Unix forward-slash format and is the default location for the .NET Tracer on Linux systems, not Windows.

D. This is the specific log directory for .NET applications instrumented by Datadog within the Azure App Service environment.

1. Datadog Documentation, ".NET Tracer and Agent Logs". In the ".NET Tracer Logs" section, it explicitly states: "By default, the .NET Tracer's logs are located in %ProgramData%\Datadog .NET Tracer\logs\ on Windows". It also lists the paths for Linux and Azure App Service, confirming options C and D are for different environments.

RUM ↔ APM correlation requires the browser-generated trace context to reach backend services. You therefore must permit Datadog propagation headers (x-datadog-trace-id, x-datadog-parent-id, x-datadog-sampling-priority, etc.) through proxies, load balancers, and application servers.

B: clientToken authenticates RUM event ingestion and has no impact on trace propagation.

C: traceRetentionRate pertains to Session Replay retention, not header propagation for trace correlation.

1. Datadog Docs – “Connect RUM and backend traces,” section “Forward Datadog headers to your backend”, https://docs.datadoghq.com/realusermonitoring/connectrumandtraces/

2. Datadog Docs – Browser RUM SDK Initialization, no mention of clientToken change for APM, https://docs.datadoghq.com/realusermonitoring/browser/

The "Code Hotspots" tab in the APM trace panel provides a direct link to data from the Datadog Continuous Profiler that corresponds to the trace's endpoint. The profiler captures granular, code-level performance data, including CPU usage, wall time, and contention metrics. "Lock wait time," which is the time a thread spends waiting to acquire a lock on a synchronized object, is a key contention metric captured by the profiler and displayed under this tab.

A. The "Infrastructure" tab correlates the trace with host-level metrics like CPU and memory usage, not code-level lock contention.

B. The "Network" tab displays metrics related to network communication between services, such as latency and traffic volume, not internal code execution.

C. The "Processes" tab shows information about the running processes on the host at the time of the trace, not specific code-level metrics like lock wait times.

1. Datadog Documentation, "Continuous Profiler > Code Hotspots". This section explicitly states, "The Code Hotspots tab in the trace view shows you the top 5 most time-consuming methods from the corresponding profile." It lists "Lock wait" as one of the available profile types.

2. Datadog Documentation, "APM Trace View". This page describes the various tabs available in the trace panel, clarifying that Code Hotspots connects the trace to profiling data for deep, code-level analysis.

To connect frontend user actions (RUM) with backend performance data (traces), the Datadog RUM SDK must inject tracing headers into outgoing requests. The allowedTracingUrls configuration parameter is set within the RUM SDK during initialization. This parameter specifies a list of backend endpoints or regular expressions to which the SDK is permitted to add these headers. This ensures that tracing context is only sent to trusted, instrumented backend services, preventing accidental data leakage to third-party domains.

A. The Datadog Agent forwards data but does not configure the client-side SDK's behavior for injecting trace headers into browser requests.

C. The Datadog Tracing Library (on the backend) receives and processes tracing headers; it does not initiate them from the browser.

D. An Application Gateway is a generic network component and is not used for this specific Datadog RUM-to-APM connection configuration.

1. Datadog Documentation, "Connect RUM and Traces", Browser Monitoring. (docs.datadoghq.com/realusermonitoring/connectrumandtraces/). This document states, "To link RUM data with backend traces, the RUM SDK adds tracing headers to the requests sent to your backend. The allowedTracingUrls initialization parameter allows you to specify the backends that can receive these headers."

2. Datadog Documentation, "RUM Browser Monitoring", Setup. (docs.datadoghq.com/realusermonitoring/browser/setup/). The setup guide shows allowedTracingUrls as a key initialization parameter for the RUM SDK.

The firstPartyHosts property is used during the initialization of the RUM React Native SDK to identify which network requests are made to your own backend services. For any request matching a host in this list, the SDK automatically adds Datadog tracing headers. This allows the backend APM agent to link the server-side trace with the originating frontend user action, creating a complete distributed trace from the client to the backend.

This question was presented in a fill-in-the-blank format; therefore, no incorrect options were available for evaluation.

1. Datadog Documentation, "React Native Monitoring," Connect RUM and Traces. (https://docs.datadoghq.com/realusermonitoring/reactnative/datacollected/connectrumandtraces/). This page explicitly states: "To link RUM data with traces, you need to specify the hosts of your first party requests in the firstPartyHosts array during the SDK initialization."

2. Datadog Github Repository, dd-sdk-react-native, "Advanced Usage" documentation. The README.md file in the repository details the firstPartyHosts configuration option for enabling distributed tracing.

The Datadog Service Catalog uses a key-value syntax for searching and filtering services. To find services of a specific type, such as web services, you use the type key followed by the desired value. The query type:web correctly filters the catalog to display only the services that have been identified or tagged as web type. This is a standard, predefined facet within the Service Catalog for categorizing services based on their function (e.g., web, db, cache).

A. source is a standard attribute typically used to identify the origin of logs or metrics (e.g., nginx, redis), not the service type in the catalog.

C. version is a reserved tag used to filter services by their application version, which is essential for tracking deployments, not for filtering by service type.

D. infratype is not a standard facet key for filtering by service type in the Datadog Service Catalog. The correct key is simply type.

1. Datadog Documentation, "Service Catalog". Section: Search and Filter. The documentation lists type as a primary facet and provides type:web as an example query for filtering services.

This query combines two main conditions with an implicit AND. The first condition, env:dev, filters for traces tagged with the development environment. The second condition, (@http.method:POST OR @http.method:GET), is a grouped clause that uses an explicit OR to find traces containing a span with an HTTP method of either POST or GET. The query returns traces that satisfy both the environment and the method conditions.

B. The space between env:dev and the parenthetical group acts as an implicit AND, not an OR.

C. The query explicitly searches for traces tagged with env:dev; it does not negate or exclude this tag.

D. The OR operator requires the trace to match one of the conditions (POST or GET), not both simultaneously.

1. Datadog Documentation, "Search for Traces". Section: "Search Syntax". States: "Use boolean operators AND, OR, and NOT to create your query." and "Use parentheses to group boolean operators." This confirms the logic for grouping and the OR operator.

2. Datadog Documentation, "Search for Traces". Section: "Search Syntax". Also confirms that a space between terms acts as an implicit AND, connecting env:dev to the grouped condition.

3. Datadog Documentation, "Standard Attributes". This page lists http.method as a standard attribute available for searching on spans.

Datadog's Error Tracking for APM serves multiple crucial functions. Its primary purpose is to reduce alert fatigue by intelligently grouping thousands of individual error occurrences into a smaller number of unique issues (B). It provides a timeline and trend analysis for each issue, allowing teams to follow them over time and understand their history and impact (C). Furthermore, you can create monitors directly from these tracked issues to set alerts for critical problems, such as a spike in a fatal error type (A). Therefore, all the listed options are correct.

A. This is a correct function of Error Tracking, but it is not the only one, making "All are correct" a better choice.

B. This is a correct function of Error Tracking, but it is not the only one, making "All are correct" a better choice.

C. This is a correct function of Error Tracking, but it is not the only one, making "All are correct" a better choice.

1. Datadog Documentation, "Error Tracking". This page describes the core functionality: "Error Tracking allows you to group similar errors together into a manageable number of issues."

2. Datadog Documentation, "Monitors". The documentation on creating monitors shows that you can create an "Error Tracking Monitor" to "get alerted on the errors that matter most to you." This confirms the alerting capability (A).

3. Datadog Blog, "Triage and prioritize APM errors faster with Datadog Error Tracking". This article highlights the benefits, stating it helps "reduce noise," "understand the lifecycle of an error," and "proactively monitor errors." This covers points B, C, and A.

The "Code Hotspots" tab within a trace view integrates data from the Datadog Continuous Profiler. The profiler analyzes code-level execution and can identify performance bottlenecks, including time spent waiting for the garbage collector (GC). This information is presented in a flame graph, allowing you to see precisely which methods are consuming CPU or wall time, with GC activity being one of the identifiable sources of latency.

A. The Infrastructure tab correlates the trace with host-level metrics (CPU, memory), not application-specific GC time for that trace.

B. The Network tab shows TCP-level metrics for the request and is unrelated to the application's internal memory management or GC.

C. The Processes tab lists running processes on the host but does not provide a detailed breakdown of GC time for a specific trace.

- Datadog Documentation, "Continuous Profiler > Explore Profiles". This page notes: "The profiler is able to distinguish time spent on CPU, waiting for I/O, waiting for locks, and other time sinks such as garbage collection."

- Datadog Documentation, "APM > Traces > Trace View". The documentation describes the integration of Profiler data into the trace view under tabs like "Code Hotspots" to pinpoint performance issues.