AZ-400 Practice Question: Design and implement build and release pipelines

Answer analysis

Option-by-option breakdown

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

• ✓

  Set retention policies to automatically delete old artifacts

  Why this is correct

  Setting retention policies automatically prunes outdated build artifacts, preventing storage bloat and reducing costs without manual intervention. You can define branch-specific or pipeline-specific retention rules, and the system cleans up old runs and their associated artifacts while preserving recent or stable builds. This ensures storage remains manageable and aligns with governance and compliance requirements.

• ✗

  Copy artifacts to each agent's local storage

  Why it's wrong here

  Copying build artifacts onto each agent's local disk duplicates the same data many times across a pool, consuming storage and assuming that a specific agent will still exist and be reachable when a later stage needs those files. Agents in Azure Pipelines are often ephemeral or dynamically scaled, so local copies can disappear without warning and cannot be shared across stages, users, or releases. A central Azure Pipelines artifact store provides one durable, versioned source of truth that any job can access, integrates natively with retention policies, and automatically carries build provenance for traceability.

• ✗

  Download all artifacts manually after each build

  Why it's wrong here

  Manually downloading artifacts after each build introduces human error and latency, and it bypasses the automated release pipeline that expects artifacts to be readily available in a known location. Manual downloads also lack traceability and version consistency, whereas Azure Pipelines automatically links build artifacts to the triggering build for downstream consumption. Automation via pipeline tasks is essential for reliable, repeatable artifact management.

• ✓

  Publish build artifacts using the Publish Build Artifacts task

  Why this is correct

  The Publish Build Artifacts task uploads build outputs directly to the Azure Pipelines artifact store and links them to the current run, producing a stable, versioned location that release pipelines and other stages can consume through download tasks. This centralization gives every downstream consumer a consistent artifact path, automatically associates the artifact with the exact source commit and build metadata, and enables retention policies to clean up old runs without manual intervention. Publishing this way is far more reliable than ad-hoc storage or manual copying because it embeds traceability into the pipeline itself.

• ✗

  Store artifacts as large single files to reduce number of files

  Why it's wrong here

  Combining all build outputs into a single monolithic archive eliminates granularity; even a one-line source change forces every consumer to download and extract the entire file, wasting bandwidth and defeating selective deployment or caching. Partial updates become impossible, per-file metadata is lost, and compliance audits are harder because you cannot inspect individual components without unpacking everything. A structured artifact folder, preserved through publishing, supports incremental transfers and lets downstream stages request only the files they actually need.

Go deeper

Related to this question