Implement an instrumentation strategy →mediumMultiple SelectObjective-mapped

AZ-400 Implement an instrumentation strategy Practice Question

Your organization uses Azure Pipelines with multiple release stages. You need to instrument the pipeline to capture the duration of each stage and the number of failed tasks. Which TWO approaches should you use?

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Use the Azure DevOps REST API to retrieve pipeline run statistics after each run.

Options D and E are correct. The goal is to capture stage duration and failed task counts. Option D uses the Azure DevOps REST API to programmatically retrieve pipeline run statistics, which includes stage-level durations and failure information. Option E adds a script task at the end of each stage that logs the stage's duration and task results to a custom log file, providing direct instrumentation. Option A is incorrect because pipeline notifications only alert on failures, they don't capture or log durations. Option B is incorrect because 'runOnce' is a deployment strategy that ensures sequential stages, not an instrumentation method. Option C is incorrect because the 'Summary' tab in the pipeline run provides a high-level overview, not detailed per-stage duration data that can be programmatically captured.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Configure pipeline notifications for failed tasks.
Why it's wrong here
Pipeline notifications for failed tasks are purely reactive alerts; they fire on failure events and do not persist any historical data, so they cannot be used to analyze trends, compare stage durations, or build a dataset of run statistics for post-run analysis.
✗
Implement a 'runOnce' deployment strategy to ensure sequential stages.
Why it's wrong here
A 'runOnce' deployment strategy only controls how the deployment task executes (single execution per run) and does not affect whether pipeline run data is captured or logged. It is a deployment behavior, not an instrumentation mechanism, so it does not help collect stage durations or task results.
✗
Enable the 'Summary' tab in the pipeline run to view stage durations.
Why it's wrong here
The Summary tab in the Azure Pipelines UI presents a read-only, predefined view of the run's high-level status and duration. It doesn't expose raw run statistics in a structured form that you can programmatically retrieve, analyze, or store for historical comparison.
✓
Use the Azure DevOps REST API to retrieve pipeline run statistics after each run.
Why this is correct
The Azure DevOps REST API (e.g., Builds - Get or Timelined endpoints) returns detailed run metadata including stage/task durations, results, and timestamps for every run. Calling this API after each pipeline run lets you programmatically collect and persist the exact statistics needed for performance analysis.
✓
Add a script task at the end of each stage to log stage duration and task results to a custom log file.
Why this is correct
Adding a script task at the end of each stage that logs stage duration and task results to a custom log file captures the specific metrics you want, providing a persistent, queryable dataset. This approach is flexible and works even when you need to record custom business or performance data beyond what the built-in pipeline views expose.

Visual reference

Go deeper

AZ-400 Implement an instrumentation strategy Practice Question

Why each option matters

Option-by-option breakdown

Related to this question