Su AZ-400 il configuration management non è “installare Ansible”. È la domanda: dato questo parco di infrastruttura applicativa, quale meccanismo garantisce che lo stato desiderato sia dichiarato una volta e mantenuto nel tempo, e quale parte di quello stato va congelata prima del deployment. Diamo per acquisiti i meccanismi di base e concentriamoci sulle decisioni di design e sui trade-off.

Scegliere la tecnologia: decide il perimetro, non il tool

La prima leva è capire dove vive lo stato da governare. Tre perimetri distinti, tre famiglie di risposta.

In-guest, su macchine Azure e ibride. La risposta nativa è Azure Machine Configuration, la funzionalità di Azure Policy che permette di auditare o configurare le impostazioni del sistema operativo come codice su macchine Azure e su macchine abilitate ad Azure Arc. Il valore architetturale non è la singola configurazione ma l’orchestrazione: assegni la configurazione tramite Azure Policy e ottieni il compliance reporting nello stesso piano di controllo che già usi per la governance. È anche la destinazione di migrazione obbligata, perché Azure Automation State Configuration verrà ritirata il 30 settembre 2027 e Microsoft indica esplicitamente Machine Configuration come target di transizione (la DSC extension per Linux è già ritirata dal 30 settembre 2023). Se in uno scenario compare Automation DSC come soluzione esistente, la scelta di design è pianificarne la migrazione, non estenderla.

Due vincoli da conoscere prima di raccomandarla: supporta VMSS Flexible ma non VMSS Uniform, e consente fino a 50 guest assignment per macchina.

Tooling di terze parti già adottato. Ansible, Chef e Puppet restano legittimi quando l’organizzazione ha competenze consolidate o quando lo stesso codice deve girare su cloud diversi. Microsoft documenta Ansible su Azure con playbook YAML e dynamic inventory, che ricava l’inventario dalle risorse Azure e consente di targettizzarle per tag: è il modello da preferire quando il requisito è riusare l’automazione esistente. Il trade-off è che il compliance reporting resta fuori da Azure Policy, quindi mantieni un secondo piano di controllo.

Configurazione applicativa a runtime. Non è configuration management del sistema operativo, ed è l’errore di categoria più frequente. Impostazioni e feature flag dell’applicazione appartengono ad Azure App Configuration, che centralizza settings e feature flag, supporta le label per differenziare ambienti e geografie, il replay point-in-time delle impostazioni e soprattutto permette di cambiare le impostazioni dinamicamente senza redeploy né restart dell’applicazione. I segreti restano in Azure Key Vault: App Configuration lo complementa, non lo sostituisce.

Idempotenza: un requisito di pipeline, non un dettaglio di stile

Un’operazione idempotente porta il sistema allo stesso stato finale indipendentemente da quante volte la esegui. In una pipeline che rideploya a ogni merge questa non è eleganza: è la precondizione per poter rieseguire senza paura.

La distinzione operativa è fra codice dichiarativo e codice imperativo. Bicep, Terraform e le risorse DSC dichiarano lo stato desiderato e lasciano al motore il calcolo del delta. Uno script shell o PowerShell lanciato da una Custom Script Extension esegue passi: la creazione di un utente fallisce alla seconda esecuzione, un append a un file di configurazione duplica la riga. Regola di design: quando il requisito parla di esecuzione ripetuta a ogni commit, scegli lo strumento dichiarativo; se sei costretto a script imperativi, l’idempotenza va costruita a mano con controlli di stato preventivi, e diventa debito che paghi a ogni run.

L’idempotenza rende praticabile anche il rollforward: se lo stato desiderato è dichiarato in un solo posto e riapplicarlo è sicuro, la risposta a un incidente di configurazione è “riapplica la baseline”.

Drift: rilevare, correggere o impedire

Il drift è la divergenza fra stato dichiarato e stato reale, prodotta da modifiche manuali, aggiornamenti fuori pipeline o interventi d’emergenza. Le domande di design sul drift si risolvono scegliendo il livello a cui intervenire.

Dentro la macchina. Machine Configuration espone tre modalità di enforcement per assegnazione, ed è esattamente qui che si gioca la risposta:

  • Audit: riporta soltanto lo stato della macchina. È la scelta quando il requisito è visibilità e la correzione deve restare un cambiamento controllato e pianificato.
  • Apply and Monitor: applica la configurazione e poi monitora i cambiamenti, senza ripristinarli.
  • Apply and Autocorrect: applica la configurazione e riporta la macchina in conformità quando il drift si verifica. È la risposta quando il requisito chiede correzione automatica e continua.

Sui contenuti custom l’assegnazione referenzia il pacchetto via contentUri e lo valida con contentHash. Il dettaglio tradisce il modello mentale corretto: la configurazione è un artefatto versionato e verificabile, non uno script scaricato al volo.

Sul piano di controllo Azure. Qui il drift si impedisce, non si corregge a posteriori. I deployment stack gestiscono un gruppo di risorse come unità e applicano deny settings (denyDelete oppure denyWriteAndDelete) che bloccano modifiche indesiderate alle risorse gestite. Tre limiti che pesano in sede di design: le deny settings agiscono sulle operazioni di control plane e non sul data plane (proteggono lo storage account, non i blob al suo interno); si applicano solo alle risorse create esplicitamente dal template, non a quelle create implicitamente da un servizio; e le esclusioni ammettono al massimo cinque principal, per cui la pratica raccomandata è escludere un gruppo Microsoft Entra e governare l’eccezione via membership anziché elencare le singole identità di pipeline. Il parametro actionOnUnmanage decide infine il destino delle risorse rimosse dal template: detachAll le lascia in vita fuori dallo stack, deleteResources e deleteAll le eliminano.

Immagine o deployment: dove collocare ogni impostazione

Il criterio decisionale è duplice: frequenza di cambiamento e variabilità per ambiente.

Appartiene all’immagine ciò che è stabile e identico ovunque: hardening del sistema operativo, runtime e agenti, pacchetti di base, baseline di sicurezza aziendale. Il beneficio è tempo di provisioning e determinismo. Lo strumento gestito è Azure VM Image Builder, costruito su HashiCorp Packer, che distribuisce il risultato su Azure Compute Gallery, come managed image o come VHD. La Gallery aggiunge ciò che serve a scala: versionamento, replica e distribuzione globale. Image Builder si integra nelle pipeline esistenti e può usare una managed identity per recuperare gli artefatti di customizzazione senza doverli rendere pubblicamente accessibili. Nota di design rilevante: il modello incoraggia a ricostruire la golden image partendo dall’ultima versione patchata dell’immagine sorgente. È la risposta corretta a “come mantengo aggiornata la baseline”, non il patching manuale delle macchine in esecuzione.

Appartiene al deployment ciò che varia per ambiente o cambia più spesso del ciclo di build: connection string, endpoint, feature flag, dimensionamenti. L’errore da evitare è cuocere valori d’ambiente dentro l’immagine, perché costringe a un’immagine per ambiente e distrugge la garanzia “lo stesso artefatto promosso attraverso gli stage”. Il non segreto va in App Configuration con le label, il segreto in Key Vault. Sul lato pipeline, gli environment di GitHub Actions ospitano secret e variabili accessibili solo ai job che dichiarano quell’environment, e vi si agganciano le protection rule — reviewer richiesti, wait timer, deployment branch policy — che trasformano la configurazione d’ambiente in un vero gate approvativo.

Resta una zona grigia: la configurazione uguale ovunque ma che cambia più spesso dell’immagine, come la versione di un modulo o una regola del web server. Qui la risposta è il configuration management continuo sulla macchina, che riconcilia senza imporre un nuovo build.

Trappole tipiche d’esame

  • “Le impostazioni del sistema operativo devono restare conformi anche su server on-premises, con reporting centralizzato” → Machine Configuration su macchine Arc-enabled, orchestrata da Azure Policy; non una soluzione per sole VM Azure.
  • “Esiste già Azure Automation State Configuration e serve una strategia a lungo termine” → pianificare la migrazione a Machine Configuration entro il ritiro del 30 settembre 2027; non investire ulteriormente su Automation DSC.
  • “Il drift va corretto automaticamente, senza intervento operativo” → assegnazione in Apply and Autocorrect; Audit riporta soltanto, Apply and Monitor non ripristina.
  • “Nessuno deve poter cancellare le risorse della landing zone, tranne la pipeline” → deployment stack con denyDelete ed esclusione di un gruppo Microsoft Entra (limite di cinque principal esclusi); ricorda che il blocco non copre il data plane.
  • “Ridurre il tempo di avvio delle nuove istanze mantenendo la baseline di sicurezza” → VM Image Builder verso Azure Compute Gallery, con ricostruzione periodica della golden image; non configurazione al primo boot.
  • “La stessa build deve passare da test a produzione cambiando solo endpoint e feature flag” → configurazione al deployment con App Configuration e Key Vault, più environment di GitHub Actions per secret e approvazioni; non immagini distinte per ambiente.
  • “La pipeline deve poter essere rieseguita su un ambiente già configurato senza effetti collaterali” → strumenti dichiarativi e idempotenti; gli script imperativi richiedono controlli di stato scritti a mano.