How would you trace one user request through an Azure-hosted .NET API and its downstream dependencies?

How would you trace a request across Azure-hosted services?

Explains correlation IDs, distributed tracing, dependency telemetry, message boundaries, and logs across App Service, queues, and downstream APIs.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would use distributed tracing so one user operation can be followed across the API and its dependencies. HTTP calls would carry trace context, logs would include the trace or operation id, and queue messages would include correlation metadata when work becomes asynchronous. I would avoid putting secrets or sensitive personal data into correlation values because those values spread into logs and telemetry.

Full answer below

Practice focus

Correlation IDs, distributed tracing, trace context propagation, structured logs, dependency telemetry, queues, and investigation flow.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
When a request crosses APIs, databases, and queues, isolated logs are not enough. This drill matters because the production behavior is shaped by platform configuration, code boundaries, and the operational path the team will use during a real incident.
I would use distributed tracing so one user operation can be followed across the API and its dependencies. HTTP calls would carry trace context, logs would include the trace or operation id, and queue messages would include correlation metadata when work becomes asynchronous. I would avoid putting secrets or sensitive personal data into correlation values because those values spread into logs and telemetry.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would standardize how services create and propagate correlation. For HTTP I would rely on W3C trace context where possible, and for queues I would store the parent trace or operation id in message metadata. Structured logs would include route, operation name, deployment version, and safe business identifiers. That makes it possible to answer whether a slow request was caused by the API, Azure SQL, a downstream service, or queued background work.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Generating a new unrelated ID in every service.
Not propagating context through queue messages.
Logging only free-form text without structured fields.
Putting sensitive data into correlation identifiers.

How would you trace one user request through an Azure-hosted .NET API and its downstream dependencies?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Tech stacks

Skill areas

Suggest an improvement