AZ-400 Design and implement source control Practice Question

Answer analysis

Option-by-option breakdown

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

• ✓

  Review pipeline logs, then identify the failing task, then check variable values and conditions, then run in debug mode, then apply a fix and retrigger

  Why this is correct

  Reviewing pipeline logs first is critical because the logs contain the exact error message, task output, and contextual timestamps needed to isolate which task actually failed. After identifying the failing task, you can then examine agent-scoped variables, variable groups, and task conditions that may have influenced its behavior, and then enable debug mode (e.g., system.debug=true) to capture verbose diagnostic traces. This sequence is efficient because each step narrows the investigation: logs point to the task, variable inspection explains why, and debug mode reveals hidden runtime details before you apply and validate a fix.

• ✗

  Run in debug mode, then review pipeline logs, then identify the failing task, then check variable values and conditions, then apply a fix and retrigger

  Why it's wrong here

  Starting with debug mode before reviewing pipeline logs is inefficient because debug produces a massive volume of additional logging that obscures the high-level failure signal you need to locate the failing task. In Azure DevOps, setting system.debug to true increases log verbosity for every task, so without first reviewing the standard logs to know which task requires deeper tracing, you will often spend time wading through irrelevant output. The correct approach is to let the normal logs guide you to the specific task, then enable debug selectively to reduce noise and focus on the actual root cause.

• ✗

  Identify the failing task, then check variable values and conditions, then run in debug mode, then review pipeline logs, then apply a fix and retrigger

  Why it's wrong here

  Trying to identify the failing task without consulting the pipeline logs first is guesswork, as the log output is the authoritative source for which task emitted an error, warning, or non-zero exit code. Checking variable values before examining logs can also mislead you because the root cause may be a syntax error or missing argument that is only visible in the task output, not in the variable definitions. Additionally, running debug mode before reviewing logs is premature because debug traces are far more useful once you have narrowed the failure to a specific task, whereas doing so upfront floods you with unrelated diagnostic data.

• ✗

  Check variable values and conditions, then apply a fix and retrigger, then review pipeline logs, then identify the failing task, then run in debug mode

  Why it's wrong here

  This order is fundamentally flawed because it applies a fix before analyzing the logs, meaning you are attempting to resolve an issue without knowing the actual error or root cause—a classic guess-and-test antipattern that can introduce new side effects. After the unvalidated fix and retrigger, the pipeline logs should be reviewed to see whether the fix even addressed the correct failure, but that review happens too late to guide the earlier decisions. Debug mode, which should be used to verify behavior before finalizing the fix, is placed last, making it useless for the initial diagnosis and leaving no verification step before the premature fix.

Go deeper

Related to this question