Microsoft AZ-400: Containerizzazione e Kubernetes — 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

La containerizzazione e Kubernetes sono alla base del DevOps moderno su Azure, combinando build riproducibili, distribuzione sicura e orchestrazione di runtime dichiarativa e auto-riparante (self-healing). La padronanza della materia richiede la comprensione di come le immagini vengono assemblate e ottimizzate, come i registry replicano e attestano il contenuto, come AKS viene progettato e aggiornato senza interruzioni, come viene implementata la progressive delivery e come proteggere i workload end-to-end. Oltre a Kubernetes “puro”, si utilizzeranno Helm per il packaging, GitOps per la riconciliazione e, nell’ambito serverless, Azure Container Apps con Dapr e KEDA per semplificare i pattern dei microservizi e lo scaling basato su eventi (event-driven). Le sezioni seguenti distillano le decisioni di piattaforma e le pratiche operative necessarie per implementare pipeline robuste e conformi e cluster di produzione resilienti.

Fondamenti di Build e Registry: Docker e ACR

Un’immagine container performante inizia con un Dockerfile deterministico e un contesto di build (build context) disciplinato. I build multi-stage consentono di separare le fasi di compilazione, pesanti in termini di toolchain, da immagini di runtime snelle. Ad esempio, si può compilare un binario .NET o Go in una fase “builder”, per poi copiare solo l’artefatto compilato in un’immagine di base “distroless” o minimale (es. mcr.microsoft.com/dotnet/runtime-deps o gcr.io/distroless/base), ottenendo superfici di attacco più piccole e tempi di pull più rapidi. Ogni istruzione RUN, COPY e ADD crea un layer; è bene ristrutturare i Dockerfile per massimizzare i riscontri nella cache dei layer (layer cache hits), posizionando alla fine i passaggi che cambiano meno di frequente e aggregando i comandi con raggruppamenti logici, preservando al contempo la leggibilità. Includere sempre un file .dockerignore per escludere bin/obj, node_modules, test, documentazione e segreti; un contesto di build sovradimensionato rallenta gli upload e riduce l’efficacia della cache remota. Utilizzare installazioni di pacchetti deterministiche (version pinning, lock file) e argomenti di build con attenzione; i file specifici per l’ambiente dovrebbero essere forniti tramite la configurazione di runtime, non inseriti in immagini immutabili.

Azure Container Registry (ACR) è la spina dorsale per l’archiviazione e la distribuzione delle immagini. Sfruttare gli ACR Tasks per delegare i build ad Azure: task rapidi per build on-demand (az acr run), task automatizzati attivati da commit Git, aggiornamenti dell’immagine di base o pianificazioni, e Task YAML multi-step per immagini multi-architettura utilizzando Buildx. La geo-replica (SKU Premium) esegue il mirroring degli artefatti tra le region, minimizzando la latenza di pull e i costi di egress per le distribuzioni multi-region di AKS/ACA; va combinata con endpoint privati e RBAC con ambito a livello di repository per il principio del privilegio minimo (least privilege). Abilitare il content trust per firmare le immagini e verificarne la provenienza: Docker Content Trust/Notary e gli ecosistemi di firma OCI in evoluzione (es. cosign) possono essere imposti in fase di ammissione (admission) tramite i vincoli di OPA Gatekeeper, che richiedono firme per i namespace protetti. Integrare la scansione delle vulnerabilità: Microsoft Defender for Cloud esegue la scansione delle immagini al momento del push e a riposo (at rest), evidenzia le CVE con indicazioni per la correzione e può bloccare le distribuzioni tramite Azure Policy e controlli di CI; includere l’automazione per l’aggiornamento delle immagini di base per ridurre i layer con vulnerabilità note.

Piattaforma AKS e Delivery dei Workload

Creare cluster AKS con impostazioni sicure per default: identità gestita, integrazione con Azure AD per RBAC, Azure CNI per l’integrazione con VNET, network policy (Azure o Calico), provider Azure Key Vault (Secrets Store CSI) per l’utilizzo dei segreti e cluster privati con intervalli di IP autorizzati. Scegliere pool di nodi appropriati per il carico di lavoro: pool di sistema per i componenti critici del control plane; pool utente per le applicazioni; pool GPU per il ML; pool spot per job stateless a basso costo; pool di nodi Windows per i container Windows. Utilizzare taints/tolerations e topology spread constraints per controllare lo scheduling e la resilienza. Eseguire l’autoscaling con il cluster autoscaler e l’Horizontal Pod Autoscaler per ogni deployment; considerare dischi OS effimeri e availability zones per migliorare prestazioni e resilienza.

Pianificare gli aggiornamenti per minimizzare le interruzioni. AKS aggiorna prima il control plane, poi i pool di nodi. Utilizzare max-surge durante l’aggiornamento dei pool di nodi per aggiungere capacità di surge, eseguire il drain dei nodi in modo controllato (gracefully) e rispettare i PodDisruptionBudgets. Adottare canali di aggiornamento automatico (rapido/stabile/solo patch) per una cadenza prevedibile; separare gli aggiornamenti dei pool di sistema e utente per limitare il blast radius. Eseguire regolarmente gli aggiornamenti dell’immagine dei nodi per applicare fix al kernel/runtime anche senza un aumento di versione di Kubernetes, e fissare (pin) versioni compatibili di CNI/CSI. Utilizzare pool di nodi blue-green per modifiche alla piattaforma senza downtime: eseguire cordon/drain dal pool green al blue e fare lo switch tramite nodeSelector/affinity.

I Deployment in Kubernetes supportano nativamente i rolling update con maxUnavailable e maxSurge per mantenere la capacità durante il rollout; abbinarli a readiness/liveness probe e startup probe per prevenire l’invio prematuro di traffico. La delivery blue-green su Kubernetes si implementa eseguendo Deployment paralleli (blue e green) e commutando un selettore di un Service stabile o un oggetto Endpoint verso la revisione di destinazione; ciò consente un fallback quasi istantaneo invertendo le label. La delivery canary è gestita al meglio a livello di edge tramite ingress: NGINX Ingress supporta il canary pesato tramite annotazioni; l’Application Gateway Ingress Controller (AGIC) può suddividere il traffico tra più backend; le service mesh offrono il traffic shifting con policy granulari e telemetria. Per pipeline robuste, validare con smoke test e controlli di disponibilità di App Insights prima di promuovere i pesi.

Helm impacchetta i manifest di Kubernetes in chart che comprendono Chart.yaml, template e un values.yaml di default. I file values si sovrappongono in modo deterministico; utilizzare overlay come values.<env>.yaml e un blocco “global” per impostazioni condivise tra sub-chart. Preferire Helm 3 con lo storage dei chart basato su OCI in ACR (helm registry login && helm push oci://…), abilitando parità di RBAC e geo-replica con le immagini. In Azure Pipelines, installare una versione fissata (pinned) di Helm (HelmInstaller) ed eseguire il deploy (HelmDeploy) tramite una service connection di tipo Kubernetes/Azure Resource Manager; il linting dei template, insieme a dry-run e diff (plugin helm diff), dovrebbe fungere da gate per le release. Evitare di committare segreti nei file values; integrare external-secrets o CSI Key Vault per materializzare i segreti a runtime. Versionare i chart semanticamente e fissare (pin) l’appVersion al digest dell’immagine per la tracciabilità.

Operation, Sicurezza e Controllo del Traffico

Il GitOps con Flux o Argo CD assicura che i cluster convergano continuamente verso uno stato dichiarato. Flux v2 si integra nativamente con AKS tramite l’estensione di Azure CLI, riconciliando Sources (Git/OCI/Bucket) e Kustomizations a intervalli regolari, e include l’automazione delle immagini per aggiornare Helm/Kustomize a nuovi tag in base a delle policy. Argo CD traccia le Application e il loro stato di salute (health), supporta l’SSO con Azure AD e può operare in modelli pull-based e app-of-apps per la separazione multi-tenant. Entrambi rilevano il drift e possono correggerlo automaticamente, emettere eventi/alert e supportare la progressive delivery; abbinarli a Flagger per automatizzare canary e test A/B usando NGINX, Istio o Linkerd, promuovendo in base alle metriche ed eseguendo il rollback in caso di violazione degli SLO.

La sicurezza inizia nella supply chain e viene applicata in fase di ammissione (admission) e a runtime. Scansionare continuamente le immagini con Defender for Cloud e implementare gate nei processi di CI/CD. Adottare i Kubernetes Pod Security Standards (baseline/restricted) con le label di Pod Security Admission sui namespace per bloccare di default pod privilegiati, hostPath e sysctl non sicuri. Applicare le policy organizzative con OPA Gatekeeper: i constraint template vietano container privilegiati, richiedono registry approvati, impongono limiti di risorse e richiedono immagini firmate o la presenza di un SBOM. Applicare network policy per definire il traffico pod-to-pod e in uscita (egress) consentito; AKS supporta Azure Network Policies (con Azure CNI) e Calico. Completare con il controllo del traffico in uscita (egress) tramite Azure Firewall o NVA e con l’ingress tramite WAF di Application Gateway. Eseguire l’hardening dei workload con utenti non-root, filesystem root di sola lettura, profili seccomp e AppArmor e aggiornamenti regolari dell’immagine dei nodi. Abilitare l’audit e il rilevamento delle minacce tramite Defender for Kubernetes e aggregare la telemetria in Azure Monitor Container Insights; standardizzare log e trace con OpenTelemetry.

Una service mesh (Istio o Linkerd) aggiunge gestione del traffico, crittografia e osservabilità uniformi. Usare DestinationRules/VirtualServices (Istio) o ServiceProfiles (Linkerd) per definire tentativi (retry), timeout, circuit breaking e routing pesato. Abilitare il mutual TLS per la crittografia e l’identità service-to-service; applicare policy come mTLS “STRICT” per colmare le lacune di sicurezza. Esportare le metriche verso Prometheus e le dashboard verso Grafana; catturare le trace distribuite (Jaeger/Zipkin) e inviarle ad Application Insights o Azure Monitor tramite i collector di OpenTelemetry. I canary basati su mesh e la fault injection potenziano test affidabili e la progressive delivery, con Flagger che automatizza l’analisi rispetto agli SLO.

Produttività degli sviluppatori e container serverless su Azure

Gli strumenti di integrazione DevOps di AKS semplificano i cicli di sviluppo interni (inner loop). Draft rileva i framework dei linguaggi e crea lo scaffolding per Dockerfile, chart Helm e configurazioni di avvio, accelerando la containerizzazione. Bridge to Kubernetes reindirizza le chiamate ai servizi da un cluster attivo alla workstation locale, permettendo di iterare ed eseguire il debug di un singolo microservizio in locale mentre il resto è in esecuzione nel cluster con dati e dipendenze reali. Azure Dev Spaces è stato ritirato; Bridge to Kubernetes è l’esperienza di sviluppo locale supportata e si integra con VS Code e Visual Studio.

Azure Container Apps (ACA) offre un runtime serverless e completamente gestito per microservizi e processi (job) senza la necessità di gestire Kubernetes. Ogni deployment crea una revisione; è possibile instradare il traffico tra le revisioni in base a una percentuale per implementare rollout di tipo blue-green o canary con un singolo comando o una modifica YAML. L’integrazione nativa con Dapr abilita l’invocazione di servizi, pub/sub, binding, state store e gestione dei segreti senza la necessità di codice personalizzato (plumbing); i componenti collegabili (ad es. Azure Service Bus, Key Vault, Cosmos DB) accelerano la creazione di funzionalità coerenti tra i vari servizi. KEDA alimenta l’autoscaling basato su eventi in base alla concorrenza HTTP e a più di 60 scaler (Azure Queue/Service Bus, Kafka, Prometheus, personalizzati), scalando fino a zero per l’efficienza dei costi. Utilizzare gli ambienti ACA (ACA Environments) per l’isolamento di rete e l’integrazione con VNET, collegare ACR tramite identità gestita e gestire la configurazione tramite YAML di containerapps per mantenere la parità dichiarativa con le pratiche GitOps.

Scenario pratico

Adobe deve modernizzare un servizio di analisi dei clienti multi-regionale, riducendo il rischio dei rilasci e rafforzando al contempo la sicurezza della supply chain e del runtime. Il team deve standardizzare le build, automatizzare i rollout sicuri e garantire una delivery rapida e conforme negli Stati Uniti e in Europa.

Implementare Dockerfile multi-stage e file .dockerignore per tutti i servizi

Perché: Riduce al minimo le dimensioni dell’immagine e la superficie di attacco, migliora gli accessi alla cache di build (build cache hit) e previene l’inclusione accidentale di segreti o di asset di test di grandi dimensioni nell’immagine.

Creare e firmare le immagini con ACR Tasks, quindi effettuarne il push su un ACR con replica geografica

Perché: Le build in cloud eliminano le varianze locali; i trigger di aggiornamento dell’immagine di base riducono l’esposizione a CVE. La replica geografica di ACR Premium colloca gli artefatti vicino ai cluster AKS, riducendo la latenza e il traffico in uscita (egress). Le firme digitali garantiscono la provenienza.

Abilitare la scansione delle immagini con Defender for Cloud e imporla tramite gate di CI e OPA Gatekeeper

Perché: Le scansioni al momento del push e a riposo (at rest) individuano precocemente le CVE. I vincoli di Gatekeeper impongono regole come “solo registri approvati”, “richieste immagini firmate” e limiti di risorse, impedendo l’ammissione di workload non sicuri.

Effettuare il provisioning di cluster AKS privati per regione con Azure CNI, network policy e identità gestita

Perché: Gli endpoint privati limitano l’esposizione del control plane; Azure CNI si integra con le VNET aziendali; le network policy limitano i movimenti laterali; l’identità gestita elimina la proliferazione di segreti (secret sprawl).

Creare pool di nodi separati per il sistema e per gli utenti, aggiungere pool di nodi spot per i processi batch

Perché: Isola i pod critici della piattaforma, fornisce capacità a basso costo per i workload non critici e semplifica gli aggiornamenti e la gestione degli SLO.

Adottare Helm per il packaging, con i chart archiviati in ACR (OCI), ed eseguire il deploy tramite Azure Pipelines

Perché: Rilasci coerenti e versionati con valori specifici per ogni ambiente. Le pipeline eseguono

undefined

prima di

undefined

, utilizzando una service connection di Kubernetes per connettersi ai cluster di destinazione.

Eseguire il deploy di Flux v2 per la riconciliazione GitOps e il rilevamento delle deviazioni (drift detection), integrare Flagger per i rilasci canary

Perché: La sincronizzazione dichiarativa basata su pull riduce le credenziali nella CI e garantisce la convergenza. Flagger automatizza i rilasci canary ponderati rispetto agli SLO utilizzando le metriche di NGINX Ingress, eseguendo il rollback in caso di errori o picchi di latenza.

Configurare aggiornamenti progressivi (rolling update) con PDB e probe di readiness/startup; utilizzare il blue-green per i componenti a rischio

Perché: I rolling update preservano la capacità; i probe proteggono il traffico degli utenti. Il blue-green, con uno scambio di etichette (label) sul Service, consente un rollback istantaneo per i componenti ad alto rischio come l’API gateway.

Introdurre la service mesh Istio con mTLS strict, tentativi (retry) e timeout; esportare la telemetria su Application Insights

Perché: Crittografia a livello di mesh, policy di traffico robuste e osservabilità uniforme. I collector di OpenTelemetry inviano tracce/metriche a un archivio centrale per il monitoraggio degli SLO e il triage degli incidenti.

Stabilire una strategia di aggiornamento controllata con il canale di auto-aggiornamento di AKS e gli aggiornamenti dell’immagine dei nodi

Perché: Aggiornamenti regolari e prevedibili della piattaforma riducono l’esposizione a vulnerabilità zero-day. Le impostazioni

undefined

e i PDB garantiscono un’interruzione minima; gli aggiornamenti separati dei pool di nodi utente limitano il raggio d’impatto (blast radius).

Utilizzare Bridge to Kubernetes per lo sviluppo in inner-loop; creare lo scaffolding con Draft

Perché: Gli sviluppatori eseguono il debug in locale rispetto alle dipendenze presenti nel cluster senza doverle simulare (mocking). Draft accelera la containerizzazione coerente e la creazione di scaffolding Helm tra i vari team.

Delegare i servizi di coda lunga (long-tail) ad Azure Container Apps con Dapr e KEDA

Perché: I microservizi basati su eventi e con scalabilità fino a zero (ad es. ingestione e arricchimento) vengono eseguiti a basso costo con suddivisione del traffico integrata per i rilasci canary; i componenti Dapr standardizzano le chiamate tra servizi e il pub/sub senza codice personalizzato.

Questo design end-to-end allinea il determinismo delle build con una distribuzione sicura, operazioni dichiarative e delivery progressiva, fornendo ad Adobe rilasci rapidi a basso rischio e un runtime protetto (hardened) in tutte le regioni.

← Infrastruttura come codice e gestione della configurazione · Tutti i domini · Gestione dei rilasci e strategie di distribuzione →

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