Microsoft AZ-400: Paketverwaltung und Artefaktverwaltung — Lernleitfaden

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

Teil des Microsoft DevOps Engineer Expert AZ-400 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Microsoft-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Die Paketverwaltung ist das Rückgrat für reproduzierbare Builds, zuverlässige Deployments und sichere Lieferketten in Azure DevOps. Azure Artifacts zentralisiert die Speicherung und Governance von Paketen über verschiedene Ökosysteme hinweg – NuGet, npm, Maven, Gradle und Universal Packages – und ermöglicht gleichzeitig Upstream-Caching aus öffentlichen Registries sowie feingranulare Kontrollen für die Beförderung, Aufbewahrung und Berechtigungen. In Kombination mit der Automatisierung der semantischen Versionierung und Werkzeugen für Sicherheit/Compliance können Sie standardisieren, wie interne und externe Abhängigkeiten in großem Maßstab erstellt, gefunden, genehmigt und konsumiert werden.

Azure Artifacts-Kernkonzepte

Ein Feed ist die Einheit für die Speicherung und Zugriffskontrolle von Paketen. Teams organisieren Feeds typischerweise nach Produkt, Plattform oder Vertrauensgrenze (z. B. ein Feed für alle öffentlichen OSS-Abhängigkeiten über Upstream, einer für gemeinsam genutzte interne Bibliotheken und einer pro Produkt). Feeds unterstützen mehrere Pakettypen, jeder mit seinen eigenen Client-Werkzeugen.

Ansichten (Views) implementieren ein gestaffeltes Beförderungsmodell innerhalb eines einzigen Feeds:

local: Alle neu veröffentlichten Pakete erscheinen hier
prerelease: Wird verwendet, um Beta-/Nightly-Builds für Early Adopter und Integrationspipelines bereitzustellen
release: Nur für die Produktion genehmigte Pakete werden hier für die breite Nutzung hochgestuft Konsumenten verweisen auf eine bestimmte Ansicht, um instabile Inhalte automatisch zu vermeiden. Befördern (Promote) oder stufen Sie Versionen (Demote) als Teil Ihres Release-Prozesses herab, um den Auswirkungsradius zu kontrollieren.

Upstream-Quellen verbinden einen Feed mit öffentlichen Registries (NuGet.org, npmjs.com, Maven Central). Wenn aktiviert, lösen Entwickler öffentliche Abhängigkeiten über Ihren Feed auf. Azure Artifacts fungiert transparent als Proxy und cacht die exakten Versionen, die verwendet werden. Dies verbessert die Zuverlässigkeit, ermöglicht Air-Gapped-Szenarien und erlaubt es Ihnen, später die Zufuhr durch Deaktivieren neuer Upstream-Downloads „einzufrieren“. Sie können pro Feed festlegen, welche Upstreams aktiviert sind, um Richtlinien zu erfüllen.

Aufbewahrungsrichtlinien werden durchgesetzt, um Speicherkosten zu senken und gleichzeitig wichtige Artefakte zu erhalten. Definieren Sie Richtlinien, um die letzten N Versionen pro Paket zu behalten, nur in die Release-Ansicht beförderte Versionen aufzubewahren und alte Prereleases automatisch zu löschen. Heften Sie bestimmte Versionen an (Pin), um sie von der Bereinigung auszunehmen (z. B. solche, die in einem langlebigen Produkt-Branch eingebettet sind). Richten Sie die Aufbewahrungszeiträume an Audit- und Rollback-Anforderungen aus, um eine Balance zwischen Nachverfolgbarkeit und Speicherkosten zu finden.

Feed-Berechtigungen folgen dem Prinzip der geringsten Rechte (Least-Privilege):

Owner (Besitzer): Verwaltet Feed-Einstellungen, Berechtigungen, Ansichten und Aufbewahrungsrichtlinien
Contributor (Mitwirkender): Veröffentlicht, entfernt (Unlist), stuft als veraltet ein (Deprecate) und befördert Pakete; kann keine Einstellungen auf Feed-Ebene ändern
Reader (Leser): Nur Wiederherstellen/Konsumieren; kann keine Pakete ändern Hinweis: „Collaborator“ ist keine Azure Artifacts-Feed-Rolle. Wenn Sie auf diesen Begriff stoßen, ordnen Sie die beabsichtigte Fähigkeit (oft „kann veröffentlichen“) der Contributor-Rolle in Azure Artifacts zu.

Verwalten von Paket-Ökosystemen

NuGet (dotnet/C#)

Versionierung: Bevorzugen Sie SemVer 2.0.0 (z. B. 1.4.0, 1.4.1-alpha.3+build.45). Pre-Release-Labels steuern die Verteilung über Ansichten; Konsumenten der Release-Ansicht stoßen niemals auf -alpha/-beta-Varianten.
Veröffentlichen: dotnet pack oder nuget pack, dann dotnet nuget push oder nuget push zu Ihrem Feed-Endpunkt. Verwenden Sie die NuGet-Tasks von Azure Pipelines und befördern Sie Pakete bei Erreichen von Quality Gates in die Prerelease-/Release-Ansichten.
Konsumieren: Konfigurieren Sie die nuget.config mit der Quell-URI des Feeds (optional auf eine Ansicht beschränkt). Stellen Sie Pakete über dotnet restore oder den NuGet Restore-Task wieder her.
Authentifizierte Feeds: Verwenden Sie den Azure Artifacts Credential Provider (in neueren dotnet SDKs integriert) oder den NuGet Authenticate-Pipeline-Task. Entwickler melden sich über Visual Studio/Azure CLI an; für CI gewähren Sie dem Build Service Principal je nach Bedarf die Rolle Reader/Contributor.

npm (JavaScript/TypeScript)

Gescopte Pakete (Scoped Packages): Veröffentlichen Sie interne Pakete unter einem Organisations-Scope, z. B. @fabrikam/button. Scopes lassen sich natürlich auf Feed-Berechtigungen abbilden und ermöglichen die Einschränkung der projektübergreifenden Nutzung.
.npmrc: Setzen Sie registry=https://pkgs.dev.azure.com/ORG/PROJECT/_packaging/FEED/npm/registry/, always-auth=true und optional @scope:registry=... für Setups mit mehreren Registries. Verwenden Sie in der CI den npm Authenticate-Task, um ein temporäres Authentifizierungstoken einzufügen. Für die lokale Entwicklung nutzen Sie npm login mit einem PAT.
Private Registry: Azure Artifacts fungiert als private npm-Registry mit Upstream zu npmjs.com. Konsumieren Sie Pakete nur aus der Release-Ansicht, um nicht genehmigte Prereleases zu blockieren.

Maven und Gradle (Java/Kotlin)

Veröffentlichen (Maven): Definieren Sie distributionManagement in der pom.xml, das auf Ihren Feed verweist, und einen server-Eintrag in der settings.xml mit Anmeldeinformationen (PAT oder Service Connection). Verwenden Sie mvn deploy oder den Maven-Task in Azure Pipelines.
Veröffentlichen (Gradle): Wenden Sie das maven-publish-Plugin an und konfigurieren Sie repositories { maven { url = "https://pkgs.dev.azure.com/..." credentials { } } }, dann veröffentlichen Sie mit gradle publish.
Abhängigkeitsauflösung: Fügen Sie Ihren Feed-Endpunkt (optional mit Ansichts-Suffix) zu den repositories in Gradle oder den repositories in der pom.xml für Maven hinzu. Verwenden Sie SNAPSHOT-Versionen für Entwicklungs-Builds und befördern Sie Release-Versionen für stabile Konsumenten in die Release-Ansicht.

Universal Packages (binäre Blobs, Skripte, Modelle)

Versionierung: Folgen Sie dem SemVer-Stil oder ganzzahligen Versionen; jede Veröffentlichung ist unveränderlich (immutable). Verwenden Sie dies für Artefakte, die nicht in sprachspezifische Ökosysteme passen.
Publish/Download-Tasks: Verwenden Sie die Azure DevOps-Tasks Universal Publish und Universal Download in Pipelines oder die Azure CLI (az artifacts universal publish/download). Authentifizieren Sie sich über eine Azure DevOps Service Connection oder eine angemeldete Identität.
Anwendungsfälle: Gemeinsam genutzte CLIs, IaC-Module, Testdaten, ML-Modelle oder sprachübergreifende Assets, bei denen Sie RBAC, Aufbewahrung und Beförderung benötigen, aber keine sprachspezifischen Werkzeuge.

### Praktisches Problemszenario

Adobe muss die Paket-Governance über mehrere Clouds und Sprachen hinweg standardisieren, Ausfälle durch die Instabilität öffentlicher Registries reduzieren und Lizenzrichtlinien durchsetzen. Die Teams veröffentlichen interne NuGet-, npm- und Maven-Artefakte und teilen große, sprachübergreifende CLI-Tools.

Zentralisierte Feeds und Upstreams einrichten

Aktion: Erstellen Sie drei Azure Artifacts-Feeds: „oss-upstream“ (mit Upstreams zu NuGet.org, npmjs.com, Maven Central), „shared-libs“ (interne Bibliotheken) und „productA“ (Pakete auf Anwendungsebene). Aktivieren Sie Ansichten (local, prerelease, release) für alle Feeds.
Begründung: „oss-upstream“ wird zum einzigen Ingress-/Caching-Punkt; „shared-libs“ und „productA“ trennen Vertrauensgrenzen und Promotion-Workflows.

Client-Nutzung über Ansichten konfigurieren

Aktion: Verweisen Sie in nuget.config, .npmrc und den Repositories in settings.xml/Gradle auf die release-Ansicht jedes Feeds für Laufzeit-Consumer und auf prerelease für Integrationstest-Pipelines.
Begründung: Ansichten stellen sicher, dass nur hochgestufte (promoted), geprüfte Pakete die Produktions-Consumer erreichen, ohne dass Client-Konfigurationen geändert werden müssen.

Publishing mit semantischer Versionierung implementieren

Aktion: Fügen Sie GitVersion zur CI für Bibliotheken und Apps hinzu. Steuern Sie die Version-Injection in dotnet pack, npm version (ohne Git-Tagging, durch die Pipeline gesteuert) und die Versionsfelder von Gradle/Maven. Veröffentlichen Sie in local; stufen Sie bei erfolgreicher CI nach prerelease hoch; automatische Hochstufung nach release nach erfolgreichen Staging-Tests.
Begründung: Eine deterministische Versionierung, die auf den Git-Flow abgestimmt ist, gewährleistet kohärente Pre-Release-Labels und automatisierbare Promotions.

Authentifizierte Feeds und Developer Experience absichern

Aktion: Verwenden Sie die Tasks NuGet Authenticate und npm Authenticate in Pipelines; aktivieren Sie den Azure Artifacts Credential Provider für Entwickler-Rechner; konfigurieren Sie die Server in der settings.xml von Maven mit PATs, die über Variablengruppen in Azure DevOps rotiert werden.
Begründung: Nahtlose, tokenbasierte Authentifizierung verhindert die unkontrollierte Verbreitung von Anmeldeinformationen (Credential Sprawl) und unterstützt nicht-interaktive Wiederherstellungen in der CI.

Schwachstellen- und Lizenzrichtlinien durchsetzen

Aktion: Fügen Sie SonarQube Quality Gates zu den Builds hinzu; integrieren Sie Black Duck, um Lizenz-Allow-Listen durchzusetzen und Builds mit unzulässigen Lizenzen oder CVEs mit hohem Schweregrad zu blockieren. Führen Sie für npm und .NET npm audit und dotnet list package –vulnerable aus; veröffentlichen Sie SBOMs als Build-Artefakte.
Begründung: Mehrere komplementäre Scanner reduzieren blinde Flecken; Black Duck gewährleistet Lizenzkonformität im großen Maßstab, während SonarQube und Ökosystem-Tools Sicherheitsregressionen frühzeitig erkennen.

Ingress kontrollieren und bei Bedarf einfrieren

Aktion: Erlauben Sie Upstream-Downloads nur von „oss-upstream“; deaktivieren Sie neue Upstream-Ingresses während der Reaktion auf einen Vorfall (Incident Response), um die Zufuhr einzufrieren. Verlassen Sie sich auf zwischengespeicherte Pakete, um die Builds aufrechtzuerhalten.
Begründung: Ein zentraler Kontrollpunkt (Choke Point) ermöglicht eine schnelle Eindämmung, falls eine öffentliche Registry kompromittiert oder instabil ist.

Aufbewahrungsrichtlinien und Pinning anwenden

Aktion: Behalten Sie die letzten 5 Versionen für „shared-libs“ und „productA“ bei; löschen Sie nicht hochgestufte Versionen, die älter als 30 Tage sind; heften Sie Versionen an (pin), die mit LTS-Branches und regulatorischen Baselines verbunden sind.
Begründung: Die automatisierte Bereinigung senkt die Speicherkosten, während Pins die Auditierbarkeit und Rollback-Fähigkeit erhalten.

Zugriff nach dem Least-Privilege-Prinzip delegieren

Aktion: Weisen Sie die Rolle Owner dem Platform Engineering zu, Contributors den Maintainern von Bibliotheken, die veröffentlichen/als veraltet markieren müssen, und Readers den Produktteams, die nur Release-Artefakte konsumieren.
Begründung: Gleicht Berechtigungen mit Verantwortlichkeiten ab; Entwickler können Pakete aus der Liste entfernen (unlist)/als veraltet markieren, ohne weitreichende administrative Rechte zu benötigen.

Universal Packages für sprachübergreifende Tools

Aktion: Veröffentlichen Sie interne CLIs und IaC-Module als Universal Packages über die Tasks Universal Publish/Download; versionieren Sie sie semantisch und stufen Sie sie über Ansichten hoch.
Begründung: Bietet RBAC, Aufbewahrungsrichtlinien und Promotion für nicht sprachspezifische Artefakte mit einem konsistenten Nutzungsmodell.

Messen und iterieren

Aktion: Verfolgen Sie den Speicherverbrauch der Feeds, die Cache-Trefferquoten und die Durchlaufzeiten für Promotions; passen Sie die Schwellenwerte für die Aufbewahrung, die Upstream-Richtlinien und die Promotionskriterien entsprechend an.
Begründung: Kontinuierliche Optimierung gewährleistet Zuverlässigkeit, Kosteneffizienz und Compliance, während der Umfang des Portfolios wächst.

← Monitoring · Alle Domänen · Agile Planung und Arbeitsmanagement →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →