Microsoft AZ-400: Package Management and Artifact Management — Study Guide

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Part of the Microsoft DevOps Engineer Expert AZ-400 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.

Overview

Package management is the backbone of reproducible builds, reliable deployments, and secure supply chains in Azure DevOps. Azure Artifacts centralizes package storage and governance across ecosystems—NuGet, npm, Maven, Gradle, and Universal packages—while enabling upstream caching from public registries and fine-grained controls for promotion, retention, and permissions. Combined with semantic versioning automation and security/compliance tooling, it lets you standardize how internal and external dependencies are produced, discovered, approved, and consumed at scale.

Azure Artifacts Core Concepts

A feed is the unit of storage and access control for packages. Teams typically organize feeds by product, platform, or trust boundary (e.g., one feed for all public OSS dependencies via upstream, one for shared internal libraries, and one per product). Feeds support multiple package types, each with its own client tooling.

Views implement a gated promotion model within a single feed:

• local: all newly published packages appear here
• prerelease: used to expose beta/nightly builds to early adopters and integration pipelines
• release: only production-approved packages are promoted here for broad consumption Consumers point at a specific view to automatically avoid unstable content. Promote or demote versions as part of your release process to control blast radius.

Upstream sources connect a feed to public registries (NuGet.org, npmjs.com, Maven Central). When enabled, developers resolve public dependencies through your feed. Azure Artifacts transparently proxies and caches exact versions that are used, improving reliability, enabling air-gapped scenarios, and allowing you to later “freeze” supply by disabling new upstream downloads. You can scope which upstreams are enabled per feed to meet policy.

Retention is enforced to reduce storage costs while preserving what matters. Define policies to keep the latest N versions per package, only retain versions promoted to release, and automatically delete old prereleases. Pin specific versions to exempt them from cleanup (e.g., those embedded in a long-lived product branch). Align retention windows to audit and rollback requirements to balance traceability against storage cost.

Feed permissions follow least-privilege:

• Owner: manage feed settings, permissions, views, and retention policies
• Contributor: publish, unlist, deprecate, and promote packages; cannot change feed-level settings
• Reader: restore/consume only; cannot modify packages Note: “Collaborator” is not an Azure Artifacts feed role. If you encounter that term, map its intended capability (often “can publish”) to the Contributor role in Azure Artifacts.

Managing Package Ecosystems

NuGet (dotnet/C#)

• Versioning: Prefer SemVer 2.0.0 (e.g., 1.4.0, 1.4.1-alpha.3+build.45). Pre-release labels gate distribution via views; consumers of the release view never encounter -alpha/-beta variants.
• Publishing: dotnet pack or nuget pack, then dotnet nuget push or nuget push to your feed endpoint. Use Azure Pipelines NuGet tasks and promote to prerelease/release views on quality gates.
• Consuming: configure nuget.config with the feed’s source URI (optionally scoped to a view). Restore via dotnet restore or NuGet Restore task.
• Authenticated feeds: use the Azure Artifacts Credential Provider (built into recent dotnet SDKs) or the NuGet Authenticate pipeline task. For developers, sign in via Visual Studio/Azure CLI; for CI, grant the build service principal Reader/Contributor as needed.

npm (JavaScript/TypeScript)

• Scoped packages: publish internal packages under an organization scope, e.g., @fabrikam/button. Scopes map naturally to feed permissions and allow restricting cross-project consumption.
• .npmrc: set registry=https://pkgs.dev.azure.com/ORG/PROJECT/_packaging/FEED/npm/registry/, always-auth=true, and optionally set @scope:registry=… for multi-registry setups. In CI, use the npm Authenticate task to inject a temporary auth token. For local, npm login with a PAT.
• Private registry: Azure Artifacts acts as a private npm registry with upstream to npmjs.com. Consume only from the release view to block unapproved prereleases.

Maven and Gradle (Java/Kotlin)

• Publishing (Maven): define distributionManagement in pom.xml pointing to your feed and a server entry in settings.xml with credentials (PAT or service connection). Use mvn deploy or the Maven task in Azure Pipelines.
• Publishing (Gradle): apply the maven-publish plugin and configure repositories { maven { url = “https://pkgs.dev.azure.com/..." credentials { } } } then publish with gradle publish.
• Dependency resolution: add your feed endpoint (optionally with view suffix) to repositories in Gradle or repositories in pom.xml for Maven. Adopt SNAPSHOT for development builds and promote release versions to the release view for stable consumers.

Universal packages (binary blobs, scripts, models)

• Versioning: follow SemVer-style or integer versions; each publication is immutable. Use this for artifacts that don’t fit language-specific ecosystems.
• Publish/download tasks: use the Azure DevOps tasks Universal Publish and Universal Download in pipelines, or the Azure CLI (az artifacts universal publish/download). Authenticate via Azure DevOps service connection or logged-in identity.
• Use cases: shared CLIs, IaC modules, test data, ML models, or cross-language assets where you need RBAC, retention, and promotion but no language-specific tooling.

Security and Compliance Controls

Vulnerability scanning must be enforced at commit and build time. Integrate tools that identify known-vulnerable dependencies and provide upgrade guidance. In many Azure DevOps environments, SonarQube is used as part of the quality gate strategy to flag issues, including rules that surface dependency risk; you can complement it with dedicated SCA tools (e.g., Snyk, Mend/WhiteSource, or Black Duck) for more exhaustive CVE coverage across ecosystems. For .NET, dotnet list package –vulnerable and for npm, npm audit can provide additional signals; for Java, OWASP Dependency-Check can be added as a build step.

License compliance is enforced by scanning SBOMs or manifests against an approved license allowlist. Black Duck is commonly added to Azure Pipelines to block builds when restricted licenses are detected. Store scan reports as pipeline artifacts and attach them to releases for auditability.

Allowed/blocked packages are best implemented as policy rather than ad hoc exceptions:

• Restrict consumers to the release view; only promote vetted versions.
• Disable new upstream downloads when you need a freeze, ensuring only cached versions are available.
• Use npm scopes and per-feed permissions to restrict namespaces.
• Add pipeline checks to fail builds on disallowed packages or licenses, and use artifact promotion as the approval workflow.

Audit and governance benefit from centralized feeds with upstream caching: you get a single choke point for package ingress, immutable histories, and consistent provenance for SBOM generation.

Versioning Automation and Retention Economics

Semantic versioning is easiest to maintain with automation:

• GitVersion reads your Git history and branch naming conventions to compute versions predictably (e.g., main produces 1.4.0, feature/* produces 1.5.0-feature.3). Configure mode (Mainline or Continuous Delivery), pre-release labels, and tag sources. Inject the computed version into csproj, package.json, or Gradle’s version property before packing.
• Automatic version bumping can follow commit semantics or PR labels. For example, chore does not bump, feat bumps minor, fix bumps patch; breaking-change bumps major. Use a pipeline step to set buildNumber and pass the version to pack/publish tasks.
• Pre-release labels should reflect branch intent (e.g., -alpha on feature, -rc on release branches). Publish prereleases to the prerelease view and promote to release on successful staging.

Retention and storage cost management require proactive policy:

• Automatic cleanup: configure per-feed retention to delete older, unpromoted versions after N days/versions. Extend periods for critical libraries with long support horizons.
• Pinning: explicitly pin versions that are embedded in long-lived products or compliance snapshots to exclude them from deletion.
• Storage optimization: prefer upstream caching over locally publishing duplicates of public packages, and consolidate feeds where practical to reduce overhead. Monitor feed storage growth and adjust policy thresholds periodically.

Upstream sources specifics:

• NuGet: connect to https://api.nuget.org/v3/index.json as upstream to proxy and cache NuGet.org packages.
• npm: connect to https://registry.npmjs.com to cache npmjs.com dependencies behind your authenticated feed.
• Maven: connect to Maven Central (e.g., https://repo.maven.apache.org/maven2) so enterprise consumers fetch through your feed with a single URL.

### Practical Problem Scenario

Adobe needs to standardize package governance across multiple clouds and languages while reducing outages from public registry instability and enforcing license policies. Teams publish internal NuGet, npm, and Maven artifacts and share large cross-language CLI tools.

1. Establish centralized feeds and upstreams

• Action: Create three Azure Artifacts feeds: “oss-upstream” (with upstreams to NuGet.org, npmjs.com, Maven Central), “shared-libs” (internal libraries), and “productA” (application-level packages). Enable views (local, prerelease, release) on all feeds.
• Rationale: “oss-upstream” becomes the single ingress/caching point; “shared-libs” and “productA” separate trust boundaries and promotion workflows.

2. Configure client consumption through views

• Action: Point nuget.config, .npmrc, settings.xml/Gradle repositories to the release view of each feed for runtime consumers, and prerelease for integration test pipelines.
• Rationale: Views enforce that only promoted, vetted packages reach production consumers without changing client configurations.

3. Implement publishing with semantic versioning

• Action: Add GitVersion to CI for libraries and apps. Drive version injection into dotnet pack, npm version (without Git tagging, controlled by pipeline), and Gradle/Maven version fields. Publish to local; promote to prerelease on successful CI; auto-promote to release after staging tests.
• Rationale: Deterministic versioning aligned to Git flow ensures coherent pre-release labels and automation-ready promotions.

4. Secure authenticated feeds and developer experience

• Action: Use NuGet Authenticate and npm Authenticate tasks in pipelines; enable Azure Artifacts Credential Provider for developer machines; configure Maven settings.xml servers with PATs rotated via Azure DevOps variable groups.
• Rationale: Seamless, token-based authentication prevents credential sprawl and supports non-interactive CI restores.

5. Enforce vulnerability and license policy

• Action: Add SonarQube quality gates to builds; integrate Black Duck to enforce license allowlists and block builds with disallowed licenses or high-severity CVEs. For npm and .NET, run npm audit and dotnet list package –vulnerable; publish SBOMs as build artifacts.
• Rationale: Multiple complementary scanners reduce blind spots; Black Duck provides license compliance at scale, while SonarQube and ecosystem tools catch security regressions early.

6. Control ingress and freeze when needed

• Action: Allow upstream downloads only from “oss-upstream”; disable new upstream ingresses during incident response to freeze supply. Rely on cached packages to maintain builds.
• Rationale: A choke point enables rapid containment if a public registry is compromised or unstable.

7. Apply retention and pinning

• Action: Retain last 5 versions for shared-libs and productA; delete unpromoted versions older than 30 days; pin versions tied to LTS branches and regulatory baselines.
• Rationale: Automated cleanup curbs storage cost while pins preserve auditability and rollback.

8. Delegate least-privilege access

• Action: Assign Owners to platform engineering; Contributors to library maintainers who must publish/deprecate; Readers to product teams that only consume release artifacts.
• Rationale: Aligns capabilities to responsibilities; developers can unlist/deprecate without broad administrative rights.

9. Universal packages for cross-language tools

• Action: Publish internal CLIs and IaC modules as Universal packages via Universal Publish/Download tasks; version them semantically and promote via views.
• Rationale: Provides RBAC, retention, and promotion for non-language-specific assets with a consistent consumption model.

10. Measure and iterate

• Action: Track feed storage, cache hit rates, and promotion lead times; adjust retention thresholds, upstream policies, and promotion criteria accordingly.
• Rationale: Continuous tuning maintains reliability, cost efficiency, and compliance as portfolio scale evolves.

← Monitoring · All domains · Agile Planning and Work Management →

Practice these questions → · Timed practice on ExamRoll.io →

Browse Microsoft →