GregLab | Exam Prep

Design and implement build and release pipelines

Packages, Feeds, and Versioning

Core

Choose package systems, feed topology, upstream caching, promotion views, and version semantics independently from pipeline artifact transport.

Aligned to AZ-400 skills measured as of July 27, 2026; guide and product behavior verified September 25, 2026.

Why this matters

A reproducible supply chain needs immutable identity, controlled origin, deliberate promotion, and consumer-compatible versions. A successful build alone supplies none of those guarantees.

Must Know

  • GitHub Packages integrates supported registries with GitHub repositories, Actions, identities, and package permissions.
  • Azure Artifacts provides multi-ecosystem feeds, project or organization scope, roles, views, upstream sources, immutability, and retention.
  • An upstream source saves an authorized restore into the feed, improving reliability and providing one governed package endpoint.
  • Azure Artifacts `@local` contains directly published and saved upstream packages; promoted views expose selected package versions and are read-only consumption surfaces.
  • SemVer major signals breaking change, minor adds backward-compatible functionality, and patch supplies backward-compatible fixes.
  • CalVer communicates time; it does not inherently communicate API compatibility unless the organization defines that meaning.
  • Pipeline artifacts are run outputs. Give them an immutable run or source-derived identity and promote the same bits rather than rebuilding per environment.

Compare and Distinguish

  • Package versions are immutable consumer contracts; pipeline run numbers identify executions; source tags identify commits.
  • Feed view promotion changes visibility, not package bits; an upstream source changes origin and caching behavior.

Scenario examples

  • Scenario: A compatible feature follows 2.4.7. Think: SemVer 2.5.0.
  • Scenario: Production must receive exactly what staging tested. Think: immutable artifact identity and build once, promote many.

Exam traps

  • Publishing a second package under the same immutable version is not a correction strategy.
  • A view does not copy or rebuild a package.
  • A pipeline cache is not a durable release artifact or governed package source.

Key takeaways

  • Separate package distribution from run-output transport.
  • Choose version meaning before automating increment.
  • Promote immutable content; do not rebuild for each environment.
How it works
  • Publishers create immutable package versions in a feed, roles govern access, and views change which versions consumers can resolve.
  • Run outputs carry pipeline and source identity so later stages can download the exact artifact without recompiling.
Objects and administrative surfaces
  • GitHub Packages registries, repository and organization package permissions, and Actions token permissions.
  • Azure Artifacts feeds, scopes, views, upstream sources, roles, retention, and Universal Packages.
When to use it
  • Use a package when multiple consumers need versioned dependency restore; use a pipeline artifact for stage-to-stage run output.
Security and governance implications
  • Grant publish and consume roles at the feed or package boundary and minimize GitHub workflow token package permissions.
Troubleshooting signals
  • For restore failures, inspect source order, feed view, saved upstream state, package version immutability, and caller feed role.
More detail
  • Choose GitHub Packages for GitHub-native registry and identity integration, or Azure Artifacts for Azure DevOps feed governance.
  • An Azure Artifacts upstream can save an authorized public restore, while a view exposes selected versions without rebuilding them.
  • SemVer communicates compatibility; CalVer communicates time unless the publisher separately defines compatibility semantics.

Ready for the quiz?

  • What is saved when Azure Artifacts consumes an upstream package?
  • Why is CalVer not automatically a compatibility promise?
  • When should an output become a package rather than a pipeline artifact?

Related objectives

  • D3.1.S1 — Recommend package management tools including GitHub Packages and Azure Artifacts
  • D3.1.S2 — Design and implement package feeds and views for local and upstream packages
  • D3.1.S3 — Design and implement a dependency versioning strategy for code assets and packages, including semantic versioning (SemVer) and date-based (CalVer)
  • D3.1.S4 — Design and implement a versioning strategy for pipeline artifacts

Learn more

Free Microsoft Certified: DevOps Engineer Expert prep

Build focused AZ-400 quizzes from skill areas, topics, and product references.

Practice with exam-style multiple-choice and multiple-response questions, score breakdowns, explanations, and a compact reference for this lane's official exam domains.

Read Topics Build a quiz

Exam Weights

Exam snapshot

AZ-400 at a glance

Level
Expert
Duration
No AZ-400-specific assessment duration published on the reviewed official pages
Questions
No fixed live question count published
Formats
No guaranteed question-type mix; the proctored exam may include interactive components
Scoring
Scaled score; 700 minimum passing score

Quiz builder

Choose your practice set

Mode

Exam fidelity: Microsoft does not publish a fixed live question count or guarantee a question-type mix for AZ-400. This lane contains multiple-choice and multiple-response exam-style practice. Practice percentages do not reproduce Microsoft's scaled scoring, and difficulty labels describe this site's Expert-level implementation and design complexity rather than a Microsoft-published question rating.

Reference

AZ-400 topics and reference map

Study links

AZ-400 resources