Microsoft AZ-400: Infrastruttura come codice e gestione della configurazione — Guida allo studio

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

Fa parte della Microsoft DevOps Engineer Expert AZ-400 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Panoramica

L’Infrastructure as Code (IaC) e la Configuration Management su Azure consentono di definire, effettuare il provisioning e applicare le impostazioni dell’infrastruttura e delle applicazioni in modo ripetibile e sicuro. Azure supporta nativamente ARM JSON e Bicep e si integra bene con Terraform e Ansible. Lo stato della configurazione può essere dichiarato con PowerShell Desired State Configuration (DSC), Azure Automation DSC, Chef e Puppet. Il rollout delle funzionalità applicative e la gestione delle chiavi sono centralizzati con Azure App Configuration e Key Vault. Le immagini immutabili create con Packer riducono il drift. La governance viene applicata come policy-as-code con Azure Policy e OPA/Gatekeeper per Kubernetes.

IaC nativo di Azure: Template ARM e Bicep

I template ARM sono documenti JSON dichiarativi che Azure Resource Manager utilizza per creare e aggiornare le risorse. La struttura di primo livello include $schema, contentVersion, parameters, variables, resources e outputs. I parameters consentono l’input specifico per l’ambiente; le variables aiutano a derivare valori calcolati; le resources dichiarano lo stato desiderato; gli outputs pubblicano risultati come gli ID delle risorse. I template supportano espressioni e funzioni di runtime (ad es. resourceId, reference, concat, uniqueString) per comporre nomi e recuperare proprietà.

Per suddividere i deployment di grandi dimensioni in unità manutenibili, è possibile utilizzare template annidati (nested) o collegati (linked). Un template annidato inserisce il JSON direttamente nella proprietà template di una risorsa Microsoft.Resources/deployments. Un template collegato fa riferimento a un template remoto tramite templateLink.uri, tipicamente archiviato in Azure Storage con una SAS a tempo per garantirne l’integrità. Utilizzare i template annidati quando tutto può risiedere in un singolo artefatto e si desidera un deployment transazionale tra le varie parti. Utilizzare i template collegati per topologie molto grandi o quando si riutilizzano i template tra repository o team diversi. È possibile definire lo scope dei deployment a livello di gruppo di risorse, sottoscrizione, management group o tenant, a seconda delle necessità, impostando lo scope del deployment sulla risorsa deployments.

ARM supporta due modalità di deployment. Incremental (predefinita) crea o aggiorna le risorse presenti nel template senza eliminare nulla che non sia dichiarato. Complete elimina le risorse nello scope di destinazione che non sono specificate nel template, rendendolo utile per garantire un drift minimo ma anche più rischioso se il template non è autorevole per quello scope. Le operazioni di Validate e What-If aiutano a visualizzare in anteprima le modifiche per ridurre i rischi prima dell’esecuzione.

Bicep è un linguaggio specifico di dominio (DSL) che compila in ARM JSON e offre un’ergonomia di authoring di prima classe. Le dichiarazioni delle risorse utilizzano nomi simbolici, impongono i tipi e supportano la parola chiave existing per fare riferimento a risorse preesistenti senza doverle ridefinire. Le dichiarazioni di parametri, variabili, output e risorse sono concise, e le relazioni padre-figlio e gli scope sono espliciti. I moduli consentono la composizione e il riutilizzo; ogni modulo è un file Bicep referenziato con la parola chiave module e può essere pubblicato e consumato da registri di template spec o artefatti OCI. Le condizioni sono espresse inline con if su risorse o moduli, e i cicli utilizzano espressioni for per dichiarare istanze multiple con una gestione chiara delle dipendenze. La migrazione da ARM JSON è semplice:

undefined

) converte il JSON in Bicep; successivamente si effettua il refactoring in moduli e si adottano i nomi simbolici. Bicep è lossless rispetto ad ARM e supporta l’intera superficie della piattaforma;

undefined

produce l’ARM JSON standard per il deployment.

IaC multipiattaforma su Azure con Terraform

Terraform integra l’IaC nativo di Azure quando sono necessari flussi di lavoro multi-cloud o agnostici rispetto al provider. Il provider azurerm gestisce le risorse di Azure Resource Manager e la sua versione dovrebbe essere bloccata (version-pinned); includere

undefined

anche se vuoto per abilitare le funzionalità del provider. Altri provider comuni includono azuread per gli oggetti AAD e random per valori di utilità. L’autenticazione può avvenire tramite un service principal, una Managed Identity su agenti hosted o la Azure CLI. Adottare una strategia di configurazione del provider chiara per ogni ambiente e centralizzare i moduli riutilizzabili con variabili di input e output.

La gestione dello stato (state management) è fondamentale. Utilizzare il backend azurerm per archiviare lo stato remoto in Azure Storage: configurare

undefined

; autenticarsi con una managed identity o una SAS; e abilitare la soft delete e il versioning sul container blob. Il backend utilizza i lease dei blob per bloccare lo stato (state lock) e prevenire modifiche concorrenti. L’accesso allo storage account dovrebbe essere controllato tramite RBAC e, opzionalmente, limitato con Private Endpoints. Mantenere i file di stato isolati per ambiente e, per design, non archiviare mai segreti nello stato: utilizzare Key Vault e le data source per il recupero dei segreti quando necessario.

I workspace forniscono un isolamento logico dello stato all’interno della stessa configurazione per la gestione di ambienti diversi come dev, test e prod. Utilizzare

undefined

e assicurarsi che la key del backend codifichi il workspace per evitare collisioni (ad es.

undefined

). I workspace sono eccellenti per la parità tra ambienti con piccole differenze; quando le topologie divergono in modo significativo, utilizzare configurazioni o moduli separati per evitare il drift e la complessità condizionale. Integrare con Azure Pipelines utilizzando le service connection e i task della Terraform CLI per standardizzare

undefined

tra le varie fasi (stage) e per subordinare gli apply ad approvazioni e controlli di policy.

Gestione della configurazione su larga scala: DSC, Azure Automation DSC, Ansible, Chef e Puppet

PowerShell Desired State Configuration (DSC) dichiara lo stato di sistemi Windows e multipiattaforma tramite risorse. Esistono due modalità di distribuzione: la modalità push invia i file MOF direttamente ai nodi; la modalità pull fa sì che i nodi recuperino i propri MOF da un servizio di pull secondo una pianificazione. Il Local Configuration Manager (LCM) applica la policy. Le impostazioni chiave dell’LCM includono:

ConfigurationMode: ApplyOnly (configura una sola volta, nessuna correzione del drift), ApplyAndMonitor (rileva il drift, nessuna correzione), ApplyAndAutoCorrect (rileva e corregge il drift).
ConfigurationModeFrequencyMins e RefreshFrequencyMins per regolare la cadenza di applicazione e di pull.
RebootNodeIfNeeded e ActionAfterReboot per gestire i riavvii.
Configurazioni parziali per comporre lo stato di un nodo da più file MOF che gestiscono in modo indipendente funzionalità specifiche (ad es., hardening del sistema operativo di base e ruolo dell’applicazione).

Azure Automation State Configuration (Azure Automation DSC) è un servizio di pull gestito. Si creano le configurazioni in PowerShell, le si importa in un Automation Account e si avviano processi di compilazione che producono le configurazioni dei nodi (MOF). I nodi si registrano con Register-AzAutomationDscNode utilizzando una chiave di registrazione e un endpoint, e possono essere raggruppati e assegnati a configurazioni con valori di parametri specifici per nodo. Il reporting di conformità mostra l’ultima configurazione applicata e lo stato di drift; i nodi in modalità ApplyAndAutoCorrect eseguiranno la correzione automatica al loro prossimo check-in. I processi di compilazione sono artefatti di build verificabili, e il controllo degli accessi basato sui ruoli (RBAC) limita la creazione delle configurazioni e l’assegnazione ai nodi.

Ansible è agentless (senza agenti) e particolarmente adatto per la configurazione di flotte Linux e per l’orchestrazione ad-hoc. Su Azure, si utilizza la azure.azcollection, che fornisce moduli per il calcolo, il networking, Key Vault e altro ancora. L’inventario dinamico con il plugin azure_rm rileva gli host dalle sottoscrizioni o da gruppi di risorse e tag specifici; l’acquisizione delle credenziali può utilizzare un service principal, Azure CLI o un’identità gestita. Si integra con Azure Pipelines installando Ansible su un agente Linux, effettuando l’accesso tramite AzureCLI@2 o una service connection di Azure Resource Manager, ed eseguendo playbook che fanno riferimento all’inventario dinamico, a gruppi di variabili e a file sicuri. Ansible eccelle in attività idempotenti e leggibili e può integrare DSC in ambienti prevalentemente Windows, gestendo flussi di lavoro e orchestrazione multipiattaforma.

Chef e Puppet forniscono modelli maturi di policy-as-code e reporting di conformità. Sulle VM di Azure, le estensioni VM per Chef e Puppet eseguono il bootstrap degli agenti al momento del provisioning, garantendo una convergenza tempestiva. Chef Infra utilizza cookbook e Policyfile per fissare le dipendenze e garantire esecuzioni riproducibili; Chef InSpec esprime la compliance-as-code e invia i report a Chef Automate per il monitoraggio del drift e della postura di controllo. I manifesti e i moduli di Puppet codificano lo stato desiderato, con Code Manager e gli ambienti che forniscono flussi di promozione; Puppet Enterprise offre reporting centralizzato, classificazione basata sui ruoli e correzione automatica. Entrambi gli strumenti si integrano con Azure tramite moduli e provider di risorse e possono coesistere con DSC nativo di Azure quando è richiesta una migrazione o in ambienti misti.

Configurazione delle Applicazioni, Immagini Immutabili e Policy as Code

Azure App Configuration centralizza le impostazioni delle applicazioni e i feature flag. I feature flag abilitano il rollout progressivo: si definiscono i flag e, se necessario, si associano filtri come il rollout basato su percentuale o il targeting degli utenti tramite le librerie di Feature Manager. Le etichette (label) consentono di separare i valori per ambiente o per anello di distribuzione (ring). Gli snapshot di configurazione acquisiscono una vista immutabile e puntuale (point-in-time) di un insieme di chiavi ed etichette, permettendo rollout coerenti e riproducibili su più servizi senza race condition dovute a modifiche simultanee delle chiavi. I riferimenti a Key Vault permettono di mantenere i segreti in Key Vault, memorizzando solo i riferimenti in App Configuration; l’identità gestita dell’applicazione deve avere il permesso get sul segreto, e le librerie client risolvono e mettono in cache i segreti con un aggiornamento dinamico opzionale. Utilizzare RBAC e l’isolamento di rete su entrambi i servizi per proteggere l’accesso.

L’infrastruttura immutabile elimina il configuration drift ricostruendo da un’immagine nota invece di modificare gli host esistenti. Il builder azure-arm (ora azure) di Packer crea immagini da un sistema operativo di base, esegue i provisioner (shell, PowerShell, Ansible) e le pubblica in una Shared Image Gallery con regioni replicate e versioning semantico. Una pipeline per le golden image tipicamente esegue il linting dei template di Packer, costruisce l’immagine, esegue scansioni di vulnerabilità e conformità (es. InSpec), la sottopone a test di integrazione, la promuove nella gallery e quindi aggiorna i VM Scale Set o gli host pool. Con i VM Scale Set, gli aggiornamenti di tipo rolling o basati sull’integrità (health-based) e gli aggiornamenti automatici dell’immagine del sistema operativo, si ottengono rollout sicuri e coerenti e un facile rollback selezionando una versione precedente dell’immagine.

La Policy as Code impone delle barriere di protezione (guardrail). Le definizioni di Azure Policy sono oggetti JSON con una policyRule che valuta le proprietà delle risorse e applica effetti come deny, audit, append, modify o deployIfNotExists per la correzione automatica. Parametrizzare le definizioni per il riutilizzo; raggrupparle in iniziative (definizioni di set di policy) per assegnazioni coerenti e un monitoraggio centralizzato della conformità. Assegnare le policy a livello di management group, sottoscrizione o resource group; abilitare le attività di correzione (remediation task) per le policy modify e deployIfNotExists per rendere conformi le risorse esistenti. Archiviare gli artefatti delle policy nel controllo di versione, revisionarli tramite pull request e distribuirli tramite Bicep, ARM o Terraform per una promozione coerente tra gli ambienti.

Per Kubernetes, OPA/Gatekeeper impone vincoli al momento dell’ammissione (admission-time). I ConstraintTemplate definiscono le policy Rego e i loro schemi; i Constraint istanziano tali policy per un cluster. I controlli comuni includono la restrizione delle immagini a registri attendibili, la richiesta di etichette/annotazioni o l’impedimento di pod con privilegi elevati. Gatekeeper si integra con strumenti GitOps (Flux/Argo CD) e con i test in CI tramite conftest. Azure Policy for Kubernetes si basa su Gatekeeper per fornire assegnazioni e viste di conformità native di Azure su tutti i cluster AKS, unificando la governance del cloud e dei cluster in un’unica dashboard di postura.

Scenario Pratico

Spotify deve standardizzare l’infrastruttura Azure, ridurre il configuration drift e accelerare i rollout sicuri delle funzionalità tra microservizi che si estendono su Windows e Linux, AKS e carichi di lavoro basati su VM.

Modellare le risorse cloud con moduli Bicep per dominio (networking, dati, calcolo) e distribuirli tramite sottoscrizioni con scope a livello di management group. Questo produce dichiarazioni tipizzate e manutenibili, uno scoping chiaro e riutilizzo senza la verbosità del JSON di ARM.
Utilizzare un numero limitato di template spec ARM collegati per i servizi di piattaforma condivisi e consumati da più team. I template collegati ospitati come template spec forniscono artefatti versionati e immutabili e disaccoppiano la cadenza della piattaforma da quella dei team applicativi.
Scegliere Terraform per le dipendenze cross-cloud di edge e CDN, con il backend azurerm che memorizza lo stato remoto in Azure Storage per ogni workspace (dev/test/prod) e utilizza i lease dei blob per il locking. Questo preserva un unico pattern di pipeline isolando in modo sicuro lo stato e abilitando una promozione coerente.
Centralizzare la configurazione delle applicazioni e i feature flag in Azure App Configuration. I feature flag con filtri percentuali ed etichette abilitano i rollout basati su anelli (ring-based); gli snapshot di configurazione assicurano che ogni fase del deployment consumi un insieme di chiavi immutabile e verificato.
Archiviare i segreti in Azure Key Vault e farvi riferimento da App Configuration. La risoluzione dei riferimenti a runtime con un’identità gestita consente la rotazione delle chiavi senza nuovi deployment e rimuove i segreti dalla configurazione dell’applicazione e dalle pipeline.
Adottare immagini immutabili per i carichi di lavoro su VM utilizzando Packer per creare golden image pubblicate su una Shared Image Gallery. Una pipeline esegue script di hardening e scansioni InSpec, etichetta le immagini e promuove solo le versioni che superano i test. I VM Scale Set consumano le immagini dalla gallery per aggiornamenti blue/green e rolling, eliminando il drift.
Imporre barriere di protezione (guardrail) con iniziative di Azure Policy che negano l’esposizione di IP pubblici su subnet private, richiedono impostazioni di diagnostica verso Log Analytics e distribuiscono automaticamente policy di backup. Assegnare a livello di management group per una copertura ampia e creare attività di correzione per le risorse esistenti al fine di far convergere rapidamente la postura.
Proteggere AKS con OPA/Gatekeeper applicando vincoli che bloccano immagini non conformi e pod con privilegi elevati. Le policy sono archiviate e versionate in Git, validate con conftest in CI e applicate tramite GitOps per garantire che lo stato del cluster corrisponda sempre alla policy.
Gestire la configurazione dei server Windows con Azure Automation DSC. I nodi si registrano con Register-AzAutomationDscNode e utilizzano ConfigurationMode=ApplyAndAutoCorrect per rilevare e correggere il drift; i processi di compilazione emettono file MOF per ogni ruolo e le dashboard di conformità evidenziano il drift per l’analisi.
Gestire la configurazione e l’orchestrazione di Linux con Ansible utilizzando l’inventario dinamico azure_rm e i moduli azure.azcollection. Azure Pipelines si autentica con un’identità gestita, esegue i playbook in modo idempotente e coordina gli aggiornamenti tra i servizi, integrando DSC su Windows.
Sfruttare i profili Chef InSpec per la compliance-as-code multipiattaforma sia sulle immagini che sugli host in esecuzione, inviando i dati a Chef Automate per il reporting. Questo introduce controlli verificabili e testabili nella pipeline e in produzione, garantendo che i requisiti normativi siano continuamente convalidati.

Questa combinazione fornisce IaC tipizzato e modulare (Bicep/Terraform), host immutabili (Packer), configurazione centralizzata delle app (App Configuration/Key Vault), applicazione continua della configurazione (Azure Automation DSC, Ansible) e una forte governance (Azure Policy, Gatekeeper). Riduce il drift, abbrevia i tempi di ripristino e di rollout e rende la conformità dimostrabile.

← Pipeline CI · Tutti i domini · Containerizzazione e Kubernetes →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →