← AZ-400: DevOps from delivery to operations
03 / 8 · 40 MIN

Artifacts, dependencies, and agents

Build and promote identifiable outputs in reproducible environments.

Concept and mechanism

An approved artifact should retain stable identity between QA and production. Rebuilding with unpinned dependencies can produce different bytes even when the version number matches. Publish output from the identified run and promote those contents while retaining links to code, dependencies, and tests. With Microsoft-hosted agents, each job receives a fresh VM; the previous job’s disk is not a transfer contract. Publishing and downloading Pipeline Artifacts makes that transfer explicit. Do not confuse artifacts with caches: a cache is an optimization, can miss, and is immutable for an already created key and scope. Its key should reflect relevant inputs.

Guided application

In Azure Artifacts, saving a new upstream version requires Feed and Upstream Reader, also called Collaborator, or higher. Downloading an already saved version is a different situation. A published package version is immutable; retries should not attempt to exchange bytes under the same identifier. For self-hosted agents, document software and dependencies because persistent state can hide requirements. Four available machines also do not guarantee four simultaneous jobs: confirm applicable parallel-job capacity. Finally, connect retention to recovery. Deleting a run deletes its Pipeline Artifacts; if rollback relies exclusively on that output, cleanup can remove recovery capability.

IN PRACTICE

QA validated hash A; production rebuilt hash B. Promote A or validate B as different contents.

Common pitfalls

Same name as same bytes; cache as archive; assumed shared disk; retention without rollback.

Related topics: YAML, conditions, and approvals · Release, slots, and data effects

Take this idea with you

Identify, retain, and promote the contents actually validated.

Create account

Reference: Pipeline artifacts · AZ-400 objectives 2026-07-27