Microsoft Azure Fundamentals (AZ-900) — Questions d'entraînement et examen blanc

Les modèles Azure Resource Manager (ARM) utilisent une syntaxe JSON déclarative pour définir l'état souhaité de ton infrastructure. Leurs principaux avantages : des déploiements reproductibles (le même modèle produit chaque fois des environnements identiques), la cohérence entre dev/staging/prod, l'idempotence (redéployer le même modèle donne le même résultat sans dupliquer les ressources) et une orchestration intégrée (ARM résout automatiquement l'ordre des dépendances). Les modèles ne remplacent pas les abonnements — tu as toujours besoin d'un abonnement comme cible de déploiement. Un seul modèle peut déployer des dizaines de ressources en même temps, pas une seule. L'optimisation des coûts relève d'Azure Advisor, pas des modèles ARM. Conseil d'examen : modèles ARM = infrastructure as code déclarative, reproductible, cohérente et idempotente. Note aussi que Bicep est le successeur recommandé des modèles ARM en JSON. (Ref: learn.microsoft.com/azure/azure-resource-manager/templates/overview)

Azure Cloud Shell est un terminal authentifié, accessible depuis un navigateur via le portail Azure, shell.azure.com ou l'application mobile Azure. Il est livré avec Azure CLI (commandes az) et Azure PowerShell (module Az) préinstallés, ainsi que des outils comme kubectl, Terraform, git et des éditeurs de code. La persistance des fichiers passe par un partage Azure Files (5 GB) monté dans ton répertoire $HOME, ce qui permet aux scripts et aux configurations de survivre au redémarrage d'une session. Cloud Shell s'exécute sur un hôte Linux temporaire qui s'authentifie automatiquement avec tes identifiants Azure. Les sessions expirent après 20 minutes d'inactivité. Au lancement, tu choisis entre Bash et PowerShell. L'affirmation est « Vrai » parce que les deux CLI sont préinstallées et qu'Azure Files assure la persistance entre les sessions. (Ref: learn.microsoft.com/azure/cloud-shell/overview)

Les Azure resource locks empêchent la suppression ou la modification accidentelle de ressources critiques. Deux types de locks : CanNotDelete (Delete lock) — les utilisateurs autorisés peuvent lire et modifier la resource, mais ne peuvent pas la supprimer. ReadOnly — les utilisateurs autorisés peuvent lire la resource, mais ne peuvent pas la modifier ni la supprimer. Les locks peuvent être appliqués au niveau subscription, resource group ou resource individuelle, et sont hérités par les resources enfants. Les locks remplacent les permissions RBAC — même les Owners ne peuvent pas supprimer une resource verrouillée avec CanNotDelete sans d’abord retirer le lock. Azure Policy applique des règles de conformité, mais n’empêche pas directement la suppression. RBAC contrôle l’accès, mais ne peut pas empêcher les suppressions au niveau Owner. Astuce d’examen : Resource locks = empêcher la suppression/modification accidentelle. Deux types : CanNotDelete et ReadOnly. Remplacent RBAC.

La hiérarchie des ressources Azure, de la portée la plus élevée à la plus basse, est : Management groups → Subscriptions → Resource groups → Resources. Les Management groups se trouvent au sommet, organisent plusieurs subscriptions et appliquent la gouvernance à grande échelle. Les Subscriptions sont des limites de facturation et d’accès qui contiennent des resource groups. Les Resource groups sont des conteneurs logiques qui regroupent des resources liées pour la gestion du cycle de vie. Les Resources sont les services Azure individuels (VMs, bases de données, storage accounts). Les attributions Policies et RBAC aux niveaux supérieurs sont héritées par les niveaux inférieurs. Une resource ne peut appartenir qu’à un seul resource group, un resource group à une seule subscription, et une subscription à un seul management group. Astuce d’examen : hiérarchie de haut en bas : Management groups > Subscriptions > Resource groups > Resources.