AZ-400 DevOps Engineer Expert: guida completa

La certificazione Microsoft Certified: DevOps Engineer Expert si ottiene superando un unico esame, AZ-400 — Designing and Implementing Microsoft DevOps Solutions. È l’unica credenziale expert del catalogo Azure che non parla di infrastruttura o di architettura, ma di come il software arriva in produzione: flusso di lavoro, source control, pipeline, sicurezza della catena di build e osservabilità.

La differenza rispetto agli altri esami Azure è sostanziale. AZ-104 chiede cosa sai configurare, AZ-305 chiede cosa sai decidere, AZ-400 chiede cosa sai costruire e mantenere nel tempo. Le domande sono spesso implementative fino al dettaglio: quale sezione di un file YAML usare, quale meccanismo di autenticazione scegliere per una service connection, come si struttura un template riutilizzabile fra più repository. È l’esame più concreto della famiglia expert, e proprio per questo il meno tollerante verso una preparazione fatta solo di video.

A chi si rivolge

Il profilo descritto da Microsoft è quello di uno sviluppatore o di un amministratore di infrastruttura che ha anche competenza su persone, processi e prodotti per abilitare la continuous delivery. In pratica:

• DevOps engineer e platform engineer che già gestiscono pipeline in produzione e vogliono una credenziale che renda leggibile un ruolo spesso difficile da descrivere in un curriculum.
• Sviluppatori senior con responsabilità sul rilascio, che padroneggiano il codice ma hanno una visione parziale di release gate, approvazioni e strategie di deployment.
• System engineer e Azure administrator che arrivano dal lato infrastruttura e devono spostarsi verso l’automazione: per loro la curva più ripida è il branching e il ciclo di vita del codice.
• Site reliability engineer che vogliono formalizzare la parte di instrumentation e di feedback loop.
• Team lead tecnici che devono disegnare il processo di delivery di più squadre e argomentarlo davanti alla direzione.

Non è un esame di ingresso al cloud. Se non hai mai lavorato su una sottoscrizione Azure reale, il punto di partenza corretto è altrove.

Prerequisiti reali

Qui c’è una differenza importante rispetto ad AZ-305, e viene ignorata da molti candidati: il prerequisito non è un consiglio, è un requisito formale. Per ottenere la certificazione DevOps Engineer Expert devi possedere almeno una fra la certificazione Azure Administrator Associate, che si ottiene con AZ-104, e la certificazione Azure Developer Associate, che si ottiene con AZ-204. Puoi sostenere e superare AZ-400 prima, ma la credenziale expert viene rilasciata soltanto quando anche il prerequisito risulta valido sul tuo profilo.

Attenzione: dei due prerequisiti oggi ne resta praticabile uno solo. AZ-204 è stato ritirato e non è più sostenibile dal 31 luglio 2026. Chi ha già ottenuto la certificazione Azure Developer Associate la conserva e può continuare a usarla come prerequisito per la credenziale expert. Chi invece deve ancora conquistarsi il prerequisito e sta pianificando adesso il percorso ha una sola strada che regge nel tempo: AZ-104, che resta pienamente attivo e ha una simulazione disponibile su CertUp. Prima di prenotare qualsiasi tappa del percorso conviene controllare il calendario aggiornato dei ritiri degli esami, perché le date di pensionamento vengono riviste da Microsoft con pochi mesi di preavviso.

Al di là del requisito formale, l’esperienza che serve davvero è questa:

• Aver amministrato e sviluppato su Azure, con competenza solida in almeno uno dei due ambiti.
• Aver implementato soluzioni sia su GitHub sia su Azure DevOps. È il punto in cui cade la maggior parte dei candidati, perché quasi tutti conoscono bene una piattaforma sola.
• Saper leggere e scrivere YAML senza esitazioni: stage, job, step, template, variable group.
• Conoscere Git oltre i comandi quotidiani: rebase, cherry-pick, recupero di dati, rimozione di informazioni dalla storia del repository.
• Avere dimestichezza con Microsoft Entra ID su service principal e identità gestite, perché è il fondamento di tutta la parte di autenticazione delle pipeline.

Cosa misura l’esame

Le aree sono cinque, elencate nella study guide ufficiale su Microsoft Learn. I pesi non sono affatto uniformi, ed è la cosa più importante da sapere per impostare lo studio.

L’area build e release pipelines vale da sola più della metà dell’esame. Non è un dettaglio da bilanciare: è il baricentro assoluto della preparazione. Le altre quattro aree, sommate, pesano meno di questa. Se hai tempo limitato, l’allocazione corretta non è un quinto per area ma qualcosa di molto più sbilanciato verso le pipeline. Evita comunque di azzerare l’instrumentation, che è l’area più leggera ma anche la più facile da chiudere in poche ore di studio mirato.

Aree e relativi pesi vengono aggiornati periodicamente da Microsoft, quindi verifica sempre la study guide ufficiale e il suo change log prima di prenotare, insieme a numero di domande, durata e lingue disponibili.

Le competenze pratiche che contano davvero

Cinque blocchi concentrano la maggior parte del valore.

YAML, sul serio. Devi saper leggere una pipeline multi-stage e capire in quale ordine viene eseguita, cosa attiva un trigger, come si passano artefatti fra stage. Soprattutto devi conoscere i template riutilizzabili: estrarre una sequenza di step in un file separato e richiamarlo da più pipeline è uno dei pattern più ricorrenti.

stages:
  - stage: build
    jobs:
      - template: templates/dotnet-build.yml
        parameters:
          buildConfiguration: Release
  - stage: deploy
    dependsOn: build
    jobs:
      - deployment: production
        environment: prod-env

GitHub Actions e Azure Pipelines in parallelo. Non basta saper usare uno dei due: serve saper mappare i concetti fra i due mondi. Workflow e pipeline, job e stage, secret di repository e variable group, environment con approvazioni su entrambe le piattaforme, runner self-hosted e agent pool. Studia le equivalenze in una tabella tua, perché le domande giocano proprio su quel confine.

Infrastructure as code. L’esame chiede di definire una strategia IaC che includa source control, test e deployment automatizzati, e di implementare desired state configuration. Bicep è il linguaggio dichiarativo di riferimento per Azure e va saputo leggere e integrare in una pipeline. Il punto non è ricordare la sintassi a memoria, ma capire quando un approccio dichiarativo e idempotente è la risposta giusta.

Gestione dei segreti. Qui il tema centrale è chiaro: ridurre i segreti a lungo termine. Azure Key Vault per chiavi, segreti e certificati; identità gestite al posto dei service principal con password dove possibile; workload identity federation per autenticare le pipeline verso Azure tramite credenziali federate OpenID Connect invece che con una password memorizzata nella service connection. In Azure Pipelines la service connection Azure Resource Manager può essere configurata proprio così, associando una credenziale federata a un’app registration o a una identità gestita. Aspettati anche domande su come evitare la fuoriuscita di informazioni sensibili nei log di build.

Strategie di deployment. Blue-green, canary, ring e progressive exposure, feature flag, A/B testing, deployment slot con swap. Per ciascuna devi sapere quale problema risolve, che cosa costa in complessità e quando è la scelta corretta rispetto ai vincoli dello scenario. La parte di feature flag ha un riferimento implementativo preciso in Azure App Configuration.

Come prepararsi

Un piano realistico per chi ha già una delle certificazioni prerequisito e può dedicare 6-8 ore a settimana si sviluppa su circa 8-10 settimane.

Settimane 1-2 — Source control e processo. Branching strategy a confronto, pull request workflow, branch policies e protection rules, Azure Boards collegato a un repository GitHub. Chiudi qui anche wiki, metriche e integrazioni: sono aree leggere e non conviene tornarci.

Settimane 3-6 — Pipeline, senza risparmiare. È il blocco centrale, e merita metà del tempo totale. Costruisci una pipeline reale da zero: build, test con pubblicazione dei risultati, code coverage, artefatto versionato, deployment su due ambienti con approvazione. Poi rifattorizzala in template, aggiungi un runner self-hosted, misura durata e costo e ottimizzala.

Settimane 7-8 — Sicurezza e IaC. Sposta i segreti in Key Vault, converti l’autenticazione a identità federata, attiva le scansioni di dipendenze e di segreti, aggiungi un deployment Bicep alla pipeline. Approfondisci qui il percorso di studio dedicato e la scheda completa della certificazione.

Settimane 9-10 — Instrumentation e simulazioni. Collega Application Insights, imposta alert sui fallimenti di pipeline, scrivi qualche query KQL di base. Poi passa alle prove cronometrate, con l’obiettivo di capire perché ogni errore era un errore.

Formato, costo e validità

Il punteggio minimo per superare l’esame è 700 su 1000, su una scala che non corrisponde a una percentuale semplice di risposte esatte, perché le domande hanno pesi diversi. Il formato include scelta singola e multipla, ordinamento, drag and drop e sequenze di domande collegate a uno scenario. Numero di domande, durata effettiva e lingue disponibili variano nel tempo: vanno verificati sulla pagina ufficiale dell’esame su Microsoft Learn.

Il rinnovo gratuito si fa da casa, senza proctoring e senza costi. L’unico rischio concreto è dimenticarsene e lasciar scadere la certificazione, il che obbligherebbe a ripetere l’esame completo a pagamento.

Errori comuni

Studiare una sola piattaforma. È l’errore numero uno. Chi arriva da Azure DevOps trascura GitHub Actions, Dependabot e le protection rules; chi arriva da GitHub trascura variable group, task group e la migrazione da pipeline classiche a YAML. Entrambi lasciano punti sul tavolo.

Distribuire lo studio in modo uniforme fra le cinque aree. Le pipeline valgono più di tutto il resto messo insieme. Dedicare lo stesso tempo a ciascuna area significa arrivare deboli proprio dove si gioca l’esito dell’esame.

Non aver mai scritto una pipeline end to end. Leggere YAML e scriverlo sono attività diverse. Le domande su template, parametri, ordine di esecuzione e dipendenze fra stage si risolvono in pochi secondi se hai costruito qualcosa di reale, e diventano indovinelli se no.

Confondere strategie di deployment simili. Canary, ring e progressive exposure vengono spesso trattate come sinonimi. Non lo sono, e le domande sfruttano esattamente questa confusione.

Trascurare identità e autenticazione. Service principal contro identità gestite, GITHUB_TOKEN contro personal access token, service connection e credenziali federate: è materiale meno appariscente delle pipeline, ma è distribuito su tutto l’esame e si porta dietro molti punti.

Impostare ancora oggi il percorso su AZ-204. Non è più una questione di rischio: l’esame è uscito dal catalogo il 31 luglio 2026 e oggi non è più né prenotabile né sostenibile. Se il prerequisito ti manca ancora, la scelta è AZ-104. Chi la certificazione Azure Developer Associate ce l’ha già, invece, la conserva e la usa senza problemi come prerequisito.

Il modo più rapido per capire se la preparazione sta funzionando è metterla alla prova su domande in stile esame. La simulazione gratuita AZ-400 su CertUp offre spiegazione ragionata di ogni risposta: usala come strumento diagnostico per individuare le aree ancora scoperte prima di prenotare. E se il tuo obiettivo di carriera è più architetturale che operativo, valuta se il percorso giusto per te non sia piuttosto AZ-305.