Übungsfragen auf offizieller Grundlage. Gründlich geprüft.

Azure Resource Manager (ARM)-Vorlagen verwenden deklarative JSON-Syntax, um den gewünschten Zustand deiner Infrastruktur zu definieren. Zu den wichtigsten Vorteilen zählen: wiederholbare Bereitstellungen (dieselbe Vorlage erzeugt jedes Mal identische Umgebungen), Konsistenz über Dev/Staging/Prod hinweg, Idempotenz (eine erneute Bereitstellung derselben Vorlage führt zum selben Ergebnis, ohne Ressourcen zu duplizieren) und eingebaute Orchestrierung (ARM löst die Reihenfolge der Abhängigkeiten automatisch auf). Vorlagen ersetzen keine Abonnements — du brauchst weiterhin ein Abonnement als Ziel der Bereitstellung. Eine einzige Vorlage kann Dutzende Ressourcen gleichzeitig bereitstellen, nicht nur eine. Kostenoptimierung ist Sache von Azure Advisor, nicht der ARM-Vorlagen. Prüfungstipp: ARM-Vorlagen = deklarative, wiederholbare, konsistente, idempotente Infrastructure-as-Code. Beachte außerdem, dass Bicep der empfohlene Nachfolger von JSON-ARM-Vorlagen ist. (Ref: learn.microsoft.com/azure/azure-resource-manager/templates/overview)

Azure Cloud Shell ist ein browserbasiertes, authentifiziertes Terminal, das du über das Azure-Portal, shell.azure.com oder die mobile Azure-App erreichst. Sowohl Azure CLI (az-Befehle) als auch Azure PowerShell (Az-Modul) sind vorinstalliert, dazu Tools wie kubectl, Terraform, git und Code-Editoren. Die Dateipersistenz läuft über eine Azure Files-Freigabe (5 GB), die in dein $HOME-Verzeichnis eingebunden wird, damit Skripte und Konfigurationen einen Neustart der Sitzung überstehen. Cloud Shell läuft auf einem temporären Linux-Host, der sich automatisch mit deinen Azure-Anmeldedaten authentifiziert. Sitzungen laufen nach 20 Minuten Inaktivität ab. Beim Start wählst du zwischen Bash und PowerShell. Die Aussage ist „Wahr“, weil beide CLIs vorinstalliert sind und Azure Files die sitzungsübergreifende Persistenz bereitstellt. (Ref: learn.microsoft.com/azure/cloud-shell/overview)

Azure resource locks verhindern das versehentliche Löschen oder Ändern kritischer Resources. Zwei Lock-Typen: CanNotDelete (Delete lock) — autorisierte Benutzer können die Resource lesen und ändern, sie aber nicht löschen. ReadOnly — autorisierte Benutzer können die Resource lesen, sie aber nicht ändern oder löschen. Locks können auf Subscription-, Resource group- oder einzelner Resource-Ebene angewendet werden und werden an untergeordnete Resources vererbt. Locks überschreiben RBAC-Berechtigungen — selbst Owners können eine mit CanNotDelete gesperrte Resource nicht löschen, ohne zuerst den Lock zu entfernen. Azure Policy erzwingt Compliance-Regeln, verhindert das Löschen aber nicht direkt. RBAC steuert den Zugriff, kann aber Löschvorgänge auf Owner-Ebene nicht verhindern. Prüfungstipp: Resource locks = versehentliches Löschen/Ändern verhindern. Zwei Typen: CanNotDelete und ReadOnly. Überschreiben RBAC.

Die Azure-Ressourcenhierarchie vom höchsten bis zum niedrigsten Geltungsbereich lautet: Management groups → Subscriptions → Resource groups → Resources. Management groups stehen ganz oben, organisieren mehrere Subscriptions und wenden Governance im großen Maßstab an. Subscriptions sind Abrechnungs- und Zugriffsgrenzen, die Resource groups enthalten. Resource groups sind logische Container, die zusammengehörige Resources für das Lifecycle Management gruppieren. Resources sind die einzelnen Azure-Services (VMs, Datenbanken, Storage accounts). Policies und RBAC-Zuweisungen auf höheren Ebenen werden an niedrigere Ebenen vererbt. Eine Resource kann nur zu einer Resource group gehören, eine Resource group zu einer Subscription und eine Subscription zu einer Management group. Prüfungstipp: Hierarchie von oben nach unten: Management groups > Subscriptions > Resource groups > Resources.