AZ-400 Configure processes and communications 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.

• ✗

  Add more agents to the pool

  Why it's wrong here

  Adding more agents to the pool expands the number of machines (or VMs) available to run jobs, which distributes load and provides fresh disk space on the new agents. However, it does nothing to clean the original agent's existing `_work` directory; that agent continues to fill up because previously completed builds leave their artifacts in place. The root cause—unbounded artifact retention on self-hosted agents—remains unchanged, so the original agent will still run out of space, even while the pool shows spare capacity on other agents.

• ✗

  Use the 'Clean all build directories' option in the agent configuration

  Why it's wrong here

  The 'Clean all build directories' option, configured at the agent level (often via a local settings file or environment variables), deletes the contents of the `_work` build directories *before* the next job begins. This prevents stale files from one build contaminating the next, but it does not execute any cleanup *after* a build completes. Consequently, the largest build may consume nearly all available disk during its execution, and that space stays occupied until the *next* build's pre-clean step runs—meaning the disk can remain in a full state and cause failures between builds.

• ✓

  Enable the 'Clean after build' option on the build pipeline

  Why this is correct

  Enabling 'Clean after build' on the build pipeline triggers an automated workspace purge, typically using commands like `git clean -fdx` or equivalent, immediately after each job finishes. This removes source files, compiled outputs, test binaries, and cached dependencies from the agent's working directory (e.g., `_work`) at the point when they are no longer needed, so disk space is reclaimed on a per-build basis. This directly prevents the steady accumulation of stale build artifacts that ultimately exhausts the agent's local storage.

• ✗

  Set 'Maximum number of parallel jobs' to 1

  Why it's wrong here

  Setting 'Maximum number of parallel jobs' to 1 restricts the agent to run only one job at a time, which avoids the spike in storage usage that occurs when multiple builds write to the same disk concurrently. Yet this limitation does not delete any files from jobs that already finished; each completed build's workspace remains on disk in its entirety. Therefore, even a serial sequence of builds will accumulate the same total amount of stale artifacts over time, just without the temporary peak of two simultaneous builds, so disk exhaustion eventually occurs at roughly the same point.

Go deeper

Related to this question