Microsoft AZ-400: Pipeline CI/CD con Azure Pipelines — 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

Azure Pipelines offre CI/CD end-to-end as code, con pipeline YAML multi-stage che unificano build, test e rilascio, preservando al contempo i controlli enterprise. La padronanza dell’authoring di YAML, dei trigger, degli agenti, delle variabili, dei template, dei job di deployment, degli artefatti, del caching e delle connessioni ai servizi è essenziale per costruire sistemi di delivery scalabili, sicuri e ripetibili.

Authoring con YAML e Template

Una pipeline YAML è composta da stage, job e step. Gli stage modellano i confini del ciclo di vita come Build, Test, Release; i job vengono eseguiti su agenti e possono essere eseguiti in parallelo; gli step sono task o script eseguiti all’interno di un job. Le dipendenze sono esplicite tramite dependsOn, consentendo un’orchestrazione granulare e un’esecuzione condizionale. Lo YAML multi-stage consolida CI e CD, supporta pattern di tipo fan-in/fan-out e lega le approvazioni agli ambienti piuttosto che a un costrutto di release autonomo.

I template abilitano la composizione e il riutilizzo a diverse granularità:

Template di step: incapsulano una sequenza di task (es. setup degli strumenti, restore, build, test) per il riutilizzo tra repository.
Template di job: raggruppano gli step con una specifica dell’agente e una strategia (es. un job con matrice di test).
Template di stage: impacchettano interi stage, incluse approvazioni, condizioni e targeting dell’ambiente, per flussi di promozione coerenti.
Template extends: impongono l’ereditarietà della pipeline. Un extends di primo livello fa riferimento a un template centrale che prescrive stage/job/step e governance richiesti. Questo è un meccanismo potente per le policy a livello di organizzazione, garantendo che ogni team erediti scansioni di sicurezza, controlli di conformità e convenzioni di denominazione.

La valutazione dei template avviene in fase di compilazione (compile-time) prima dell’esecuzione a runtime. Usa ${{ }} per le espressioni di template per creare ramificazioni nella struttura della pipeline in fase di compilazione (ad esempio, includere certi job solo per il branch main). La sintassi delle macro $(var) e le espressioni a runtime $[ ] vengono risolte a runtime, il che influisce su quando i segreti e i gruppi di variabili sono disponibili. Archivia i template condivisi in un repository centrale e importali tramite resources: repositories; fissa (pin) la versione a un branch o a un tag per build deterministici.

Trigger, Agenti, Variabili ed Espressioni

I trigger governano i punti di ingresso dell’automazione:

I trigger di CI avviano le esecuzioni della pipeline quando viene pushato codice su branch tracciati. I filtri sui percorsi (path) di inclusione ed esclusione riducono il numero di esecuzioni non necessarie (churn). L’opzione batch consente di raggruppare più push.
I trigger di PR validano le pull request. Configura i branch di destinazione e i filtri sui percorsi, e abilita la cancellazione automatica delle esecuzioni superate.
I trigger pianificati vengono eseguiti in base a espressioni cron per supportare build notturni o validazioni periodiche con controllo del fuso orario.
I trigger di pipeline si attivano quando una pipeline a monte (upstream) pubblica una nuova esecuzione o un artefatto. Dichiara le risorse della pipeline e imposta trigger: true con filtri sui branch per concatenare le pipeline tra repository o progetti.

Agenti e pool di agenti determinano dove vengono eseguiti i job:

Gli agenti ospitati da Microsoft (Microsoft-hosted) forniscono VM effimere su immagini ubuntu-latest, windows-latest o macOS con set di strumenti preinstallati. Sono ideali per l’elasticità e la manutenzione minima. Pianifica la concorrenza acquistando job paralleli e considera i limiti di riscaldamento della cache (warm-up).
Gli agenti self-hosted vengono eseguiti sulla tua infrastruttura per toolchain personalizzate, accesso a reti private e prestazioni prevedibili. Esegui l’hardening dell’host, limita il traffico in uscita (egress) secondo necessità e ruota il PAT dell’agente usato per registrarlo. Usa scale set o agenti containerizzati per l’elasticità.
I pool di agenti raggruppano logicamente gli agenti e sono usati per delegare i permessi. Concedi ai pool i diritti di “Uso” a livello di progetto e isola i carichi di lavoro sensibili tramite pool dedicati. I job specificano il pool e, opzionalmente, le demands per selezionare agenti con le capability richieste.

Variabili e parametri guidano la configurabilità:

Le variabili di pipeline sono coppie chiave/valore disponibili per i task come variabili d’ambiente e tramite la macro $(name). Le variabili segrete sono mascherate nei log e non vengono mai esposte nelle espressioni di template in fase di compilazione. Contrassegnale come segrete nella Libreria (Library) o nella pipeline.
I gruppi di variabili centralizzano valori e segreti condivisi nella Libreria. Collegali ad Azure Key Vault per recuperare i segreti a runtime, garantendo che i valori non siano archiviati nella pipeline. Controlla i permessi della pipeline per limitare quali pipeline possono utilizzare un gruppo.
I parametri a runtime definiscono input fortemente tipizzati al momento dell’accodamento (stringa, numero, booleano, oggetto) e sono valutati in fase di compilazione tramite ${{ parameters.* }} per modellare la pipeline (es. abilitare/disabilitare gli stage). Preferisci i parametri quando devi alterare la struttura della pipeline; preferisci le variabili quando hai bisogno di valori a runtime all’interno degli step.
Espressioni: usa ${{ }} per la logica dei template in fase di compilazione, $(var) per la sostituzione di macro e $[condition()] per i condizionali a runtime nelle proprietà. Imposta le variabili dai task tramite comandi di logging e propaga gli output tra i job usando le variabili isOutput.

Distribuzioni, Ambienti, Strategie e Gate

I processi di distribuzione (deployment job) forniscono una semantica di prima classe per la CD. Un processo di distribuzione si rivolge a un ambiente e viene eseguito secondo una strategia che controlla i rollout e gli hook del ciclo di vita:

Gli Ambienti rappresentano le destinazioni di distribuzione (es. dev, test, prod) e possono contenere risorse come cluster Kubernetes, macchine virtuali o risorse generiche “none” per distribuzioni indipendenti dalla piattaforma. Gli ambienti unificano telemetria, approvazioni e controlli.
Approvazioni e controlli sono associati ad ambienti e connessioni al servizio. Le approvazioni richiedono l’intervento di approvatori designati prima che la distribuzione possa procedere. I controlli agiscono come gate che valutano condizioni quali l’orario di lavoro, elementi di lavoro richiesti, segnali di Azure Monitor, l’invocazione di API REST o Azure Functions e la protezione dei rami. Questi impediscono la promozione a una fase successiva se le baseline delle prestazioni o le condizioni di conformità non sono soddisfatte.
Le Strategie definiscono le modalità di rollout degli aggiornamenti:
- runOnce applica le modifiche in una singola ondata, con hook preDeploy e postDeploy.
- rolling distribuisce in batch attraverso le istanze, con soglie maxParallel e di fallimento per una progressione sicura.
- canary sposta il traffico gradualmente attraverso incrementi, con fasi routeTraffic e postRouteTraffic per la convalida prima del rollout completo.
- blue-green (chiamata anche red/black) viene implementata distribuendo su un ambiente o uno slot parallelo e scambiando il traffico a livello di load balancer o tramite lo swap degli slot di App Service. Sebbene blue-green non sia una strategia YAML nominata, si realizza tramite ambienti, routing e task di swap, e fornisce un rollback rapido ripristinando il traffico.

Codificate la logica di distribuzione come un processo di distribuzione per ogni fase (stage) dell’ambiente. Sfruttate i controlli dell’ambiente per creare gate robusti, non un polling tramite script ad-hoc. Quando sono necessari dei segreti, recuperateli da Azure Key Vault tramite una connessione al servizio anziché incorporarli nelle variabili.

Artefatti, Caching e Connessioni al Servizio

Artefatti e caching migliorano il riutilizzo e le prestazioni:

Gli artefatti della pipeline sono il modo nativo per pubblicare e utilizzare gli output della build. Usate PublishPipelineArtifact per pubblicare artefatti nominati e DownloadPipelineArtifact per recuperarli dalla esecuzione corrente o da una specifica. Sono ottimizzati per l’affidabilità e la condivisione tra fasi (stage) in YAML. Quando si utilizzano artefatti da un’altra pipeline, dichiarate una risorsa di tipo pipeline e usate il nome della sua risorsa artefatti per un recupero preciso.
I pacchetti universali forniscono una distribuzione di binari immutabili e versionati tramite Azure Artifacts per asset non specifici di un linguaggio (es. strumenti CLI, file di dati). Pubblicate e scaricate con i task Universal Packages, organizzate tramite le viste del feed (es. prerelease vs release) e gestite la retention nei feed.
Il caching della pipeline accelera il ripristino delle dipendenze. Il task Cache utilizza una chiave (key) e un percorso (path). Le chiavi dovrebbero includere l’hash dei file di lock (package-lock.json, Pipfile.lock, packages.lock.json, go.sum) più le versioni del sistema operativo e degli strumenti per un’invalidazione precisa. Le chiavi di ripristino (Restore keys) forniscono corrispondenze di fallback per riscontri parziali nella cache (partial cache hit). Evitate di incorporare segreti nei percorsi della cache, rispettate i limiti di dimensione della cache e disabilitate il caching per strumenti effimeri quando i file di lock sono instabili. Osservate la variabile cacheHitVar per modificare il comportamento dei task.

Le connessioni al servizio definiscono l’identità che Azure Pipelines utilizza per raggiungere sistemi esterni:

I tipi includono Azure Resource Manager (per sottoscrizioni e gruppi di risorse Azure), GitHub (lettura/scrittura del repository, reporting dello stato) e Docker/Container Registry (Docker Hub, ACR). Ne esistono altri per AWS, GCP, endpoint di servizio generici e registri di pacchetti.
La federazione OIDC (workload identity federation) elimina i segreti a lunga durata stabilendo una relazione di trust tra Azure DevOps e i provider di identità cloud. Per ARM, configurate un’applicazione Entra ID con una credenziale federata legata all’issuer di Azure DevOps e ai claim del repository/pipeline. In fase di esecuzione, Azure DevOps scambia un token di breve durata con un token di accesso al cloud, eliminando i segreti del service principal e riducendo il rischio di fuga di credenziali.
La definizione dell’ambito (scoping) e la governance sono fondamentali. Limitate l’ambito delle connessioni ARM al minimo privilegio (idealmente a livello di gruppo di risorse con RBAC personalizzato). Disabilitate l’opzione “Grant access permission to all pipelines” (Concedi l’autorizzazione di accesso a tutte le pipeline) e autorizzate invece esplicitamente le pipeline. Associate approvazioni e controlli alle connessioni al servizio per richiedere una revisione umana o una convalida delle policy prima dell’uso.

Classiche vs YAML e Migrazione

Le pipeline classiche utilizzano il designer visuale con concetti separati di Build e Release. Offrono creazione basata su task, gestione delle variabili, ambienti di rilascio e gate. Le pipeline YAML forniscono pipeline-as-code, unificazione multi-stage, template e un robusto versioning con il repository. La parità di funzionalità è in gran parte raggiunta: le approvazioni e i controlli (check) sugli ambienti sostituiscono i gate di rilascio; i deployment job modellano gli ambienti; gli artefatti di pipeline sostituiscono gli artefatti di build; e i template e la direttiva extends implementano una governance centralizzata su larga scala. Le differenze rimanenti riguardano tipicamente interventi manuali basati sull’interfaccia utente e alcune funzionalità di nicchia del designer di rilascio, che sono coperte in YAML tramite task di convalida manuale (Manual Validation) e controlli di ambiente.

Un percorso di migrazione pragmatico è:

Inventariare le definizioni di build e rilascio classiche, i task, le variabili, gli ambienti, le approvazioni e i gate.
Convertire la build in YAML usando l’assistente o l’esportazione in YAML, quindi effettuare il refactoring in template per il riutilizzo e la manutenibilità.
Modellare ogni ambiente di rilascio come uno stage YAML con un deployment job che punta a un ambiente. Tradurre i gate di rilascio in approvazioni e controlli di ambiente (es. controlli di query su Azure Monitor, controlli di query su work item).
Esternalizzare le variabili condivise in gruppi di variabili (variable groups) e collegare Key Vault per i segreti. Sostituire i segreti dei service principal con service connection basate su OIDC.
Sostituire i trigger basati sugli artefatti di rilascio con trigger di risorsa pipeline (pipeline resource triggers). Pubblicare gli artefatti di pipeline nella fase di CI e consumarli nelle fasi di CD.
Convalidare la parità eseguendo temporaneamente entrambe le pipeline, quindi effettuare il passaggio definitivo e ritirare le definizioni classiche con piani di rollback appropriati.

Scenario Pratico

Starbucks sta standardizzando il delivery per una piattaforma di microservizi e deve migrare dalle release classiche a YAML, imponendo al contempo gate di performance, riducendo il rischio legato alle credenziali e accelerando le build.

Creare YAML multi-stage con template extends

Approccio: Creare un template extends centrale a livello di organizzazione che inserisca stage comuni per analisi statica, SCA e controlli di sicurezza, oltre a notifiche standard. Ogni pipeline di servizio estende questo template e definisce i propri stage di build e deploy specifici.
Motivazione: extends impone una governance uniforme e mantiene snelle le pipeline di servizio, garantendo al contempo i passaggi di conformità richiesti.

Implementare trigger di CI, PR, schedulati e di pipeline

Approccio: Configurare trigger di CI e PR con filtri sui percorsi (path filters) per ogni servizio; aggiungere una schedulazione notturna per test di integrazione a lunga esecuzione; concatenare una pipeline di packaging per attivare una pipeline di deployment tramite risorse di pipeline (pipeline resources).
Motivazione: Garantisce un feedback rapido sulle modifiche al codice, controlli periodici sullo stato di salute (health check) e una promozione deterministica di artefatti noti.

Utilizzare una strategia di agenti mista con pool di agenti

Approccio: I job di build su agenti Microsoft-hosted ubuntu-latest per l’elasticità; i job di deploy su agenti self-hosted all’interno della VNet di Starbucks con accesso ai cluster interni. Isolare gli agenti per pool in base all’ambiente e limitare l’uso dei pool.
Motivazione: Gli agenti hosted minimizzano la manutenzione per la CI; gli agenti self-hosted forniscono una connettività di rete sicura per la CD. La suddivisione in pool (scoping) applica il principio del privilegio minimo (least privilege).

Gestire le variabili con gruppi di variabili e parametri di runtime

Approccio: Inserire i valori condivisi non segreti in gruppi di variabili (variable groups), recuperare i segreti da Azure Key Vault tramite gruppi di variabili collegati ed esporre un parametro booleano enablePerfGate per attivare/disattivare i gate di performance nei branch non di produzione.
Motivazione: La configurazione centralizzata evita duplicazioni; Key Vault protegge i segreti; i parametri guidano le scelte strutturali a tempo di compilazione (compile-time).

Definire deployment job con ambienti, approvazioni e controlli (check)

Approccio: Modellare dev, staging e prod come ambienti. Aggiungere approvazioni per staging e prod. Aggiungere controlli: orario di lavoro (business hours) per prod e un controllo di query su Azure Monitor che blocca la promozione se la latenza in staging supera una baseline.
Motivazione: Le approvazioni e i controlli a livello di ambiente implementano una promozione controllata e impongono il rispetto degli SLO prima del deployment in produzione.

Applicare strategie canary e poi blue-green

Approccio: Utilizzare una strategia canary in staging per convalidare gli incrementi. In produzione, effettuare il deploy in uno slot/ambiente parallelo e scambiare il traffico (blue-green/red-black) con capacità di rollback istantaneo.
Motivazione: La strategia canary riduce il rischio durante la validazione; la blue-green minimizza i tempi di deployment e fornisce il rollback più rapido.

Ottimizzare con artefatti di pipeline e caching

Approccio: Pubblicare gli output della build come artefatti di pipeline; consumarli negli stage di deployment. Mettere in cache il ripristino delle dipendenze usando chiavi basate sull’hash del lockfile con restoreKeys per il fallback.
Motivazione: Gli artefatti garantiscono una promozione immutabile e tracciabile; il caching riduce significativamente i tempi di build senza sacrificare la correttezza.

Mettere in sicurezza le service connection con OIDC e permessi con scope limitato

Approccio: Creare service connection ARM utilizzando la workload identity federation con uno scope limitato ai resource group. Richiedere approvazioni e controlli per le service connection e disabilitare l’opzione “Grant access to all pipelines”.
Motivazione: Rimuove i segreti a lunga durata e applica il principio del privilegio minimo con approvazioni verificabili (auditable).

Questo design end-to-end allinea la governance YAML-as-code con approvazioni e controlli di livello enterprise, accelera il delivery tramite caching e artefatti, e rafforza la sicurezza tramite OIDC e service connection con scope limitato.

← Controllo del codice sorgente e gestione dei repository · Tutti i domini · Infrastruttura come codice e gestione della configurazione →

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