Microsoft AZ-204: Soluzioni Container di Azure — Guida allo studio

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Fa parte della Microsoft Azure Developer Associate AZ-204 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Panoramica

Azure offre una gamma di opzioni per container che spaziano dall’esecuzione di container singoli, a cluster orchestrati, fino a una supply chain di immagini sicura e di livello enterprise. Azure Container Instances (ACI) è il modo più rapido per eseguire container Linux o Windows senza dover gestire server. Azure Kubernetes Service (AKS) è un control plane Kubernetes gestito che permette di scalare microservizi con funzionalità avanzate di scheduling, networking, sicurezza e integrazioni DevOps. Azure Container Registry (ACR) è il registry privato e geo-replicato che funge da punto di riferimento per i flussi di build, tagging, push/pull e distribuzione di Helm. La padronanza della creazione di immagini Docker e della gestione del loro ciclo di vita è fondamentale per deployment affidabili su qualsiasi di queste piattaforme. Questa sezione stabilisce una visione pratica e incentrata sullo sviluppatore di come i vari componenti si integrano tra loro, includendo deployment basati su YAML, packaging con Helm, esposizione dei servizi e pattern di identità e sicurezza.

Docker e Azure Container Registry (ACR)

La distribuzione affidabile di container inizia con solide basi di Docker. Ogni immagine è composta da layer formati dalle istruzioni del Dockerfile; il riutilizzo dei layer e i cache hit sono fondamentali per build veloci.

• Istruzioni comuni del Dockerfile e linee guida:
  • FROM definisce l’immagine di base. Preferire immagini minimali (es. distroless, alpine quando appropriato) per ridurre la superficie d’attacco e le dimensioni.
  • RUN esegue comandi per installare dipendenze. Combinare comandi correlati per ridurre il numero di layer, ma evitare righe RUN monolitiche che possono nascondere gli errori.
  • COPY e ADD inseriscono gli artefatti dell’applicazione. Usare .dockerignore per evitare di appesantire il contesto; vincolare COPY a percorsi espliciti.
  • WORKDIR imposta la directory di lavoro; usarlo invece di concatenare cd nei comandi RUN.
  • EXPOSE documenta le porte di ascolto previste (non è un firewall).
  • ENV e ARG configurano variabili d’ambiente e di build-time; promuovere il determinismo in fase di build fissando i valori predefiniti di ARG o passando valori espliciti.
  • ENTRYPOINT definisce l’eseguibile principale; usare CMD per gli argomenti predefiniti. Preferire la forma exec (array JSON) per preservare la gestione dei segnali e consentire uno shutdown controllato (graceful shutdown).
  • HEALTHCHECK abilita la valutazione della liveness per permettere agli orchestratori di reagire.
• Le build multi-stage separano le fasi di build e di runtime, copiando solo gli artefatti necessari in un’immagine di runtime pulita, riducendo drasticamente le dimensioni e l’esposizione a CVE. Ad esempio, compilare con l’SDK, pubblicare i binari e poi copiarli in un’immagine di base per il runtime.
• I layer delle immagini sono immutabili e indirizzati tramite il loro contenuto (content-addressed). Riorganizzare le istruzioni altera il funzionamento della cache. Posizionare le istruzioni che cambiano di frequente (es. COPY del codice sorgente) alla fine del Dockerfile per massimizzare i cache hit.

Con ACR, è possibile archiviare e distribuire privatamente immagini e chart Helm:

• Repository e tagging: Eseguire il push delle immagini come <registry>.azurecr.io/<repo>:<tag>. Preferire tag semantici o basati su Git (es. 1.4.0, build SHA) e usare digest immutabili nei deployment di produzione per garantire la ripetibilità.
• Push e pull:
  • Autenticarsi ad ACR usando az acr login -n <acr-name> o docker login con un token Azure AD. Evitare di abilitare l’utente amministratore di ACR in produzione.
  • Taggare ed eseguire il push: docker tag app:1.0 <acr>.azurecr.io/apps/app:1.0; docker push <acr>.azurecr.io/apps/app:1.0. Eseguire il pull con docker pull o tramite i riferimenti all’immagine in Kubernetes.
  • Importare immagini upstream in ACR per controllare la supply chain: az acr import -n <acr> --source docker.io/library/nginx:1.25 --image base/nginx:1.25.
• ACR Tasks: Eseguire build, test e patching delle immagini nativamente in Azure. Usare az acr build -r <acr> -t apps/app:1.0 . per build on-demand; automatizzare gli aggiornamenti con az acr task create per attivarli a seguito di commit Git o aggiornamenti dell’immagine di base, consentendo la correzione di CVE senza modificare il codice dell’applicazione.
• Geo-replication (SKU Premium) fornisce località di pull multi-regionale e resilienza. Configurare repliche in regioni vicine ai cluster AKS per ridurre la latenza di pull e il traffico in uscita (egress) tra regioni.
• Controllo degli accessi:
  • Integrare con Azure AD e assegnare ruoli predefiniti come AcrPull all’identità del kubelet di AKS e AcrPush alle pipeline di CI. Sono disponibili permessi a livello di repository (repository-scoped) tramite token e scope map per un controllo granulare.
  • Limitare l’accesso di rete con private endpoint, service endpoint e regole di firewall. Preferire i private endpoint per l’ambiente di produzione.
  • Collegare ACR ad AKS con az aks update --attach-acr <acr> per semplificare l’assegnazione del ruolo AcrPull.

Azure Container Instances (ACI)

ACI esegue container on-demand senza la gestione di un cluster. L’unità primaria è un gruppo di container (container group), un insieme di container pianificati congiuntamente (co-scheduled) che condividono lo stesso kernel del sistema operativo host, ciclo di vita, IP e volumi. Usare i gruppi di container per implementare il pattern sidecar (es. log shipper, proxy) o per combinare un processo principale con un processo di supporto (helper).

• I gruppi multi-container condividono un namespace di rete, abilitando la comunicazione tra container tramite localhost. Condividono anche volumi montati (Azure Files, emptyDir) e il ciclo di vita, rendendoli adatti per attività singole e coese che richiedono un accoppiamento stretto.
• Le policy di riavvio (restart policy) controllano la semantica di esecuzione:
  • Always riavvia i container quando terminano. Ideale per servizi a lunga esecuzione (long-running).
  • OnFailure riavvia solo in caso di codice di uscita diverso da zero. Adatta per attività batch che devono ritentare in caso di fallimento.
  • Never esegue i container una sola volta e non li riavvia mai, ideale per job idempotenti.
• Le integrazioni di rete includono un IP pubblico con etichetta DNS, IP privati in una subnet delegata di una VNet di Azure, e un’uscita (egress) sicura tramite NAT o firewall. Un’istanza ACI inserita in una VNet (VNet-injected) abilita l’accesso privato a servizi (database, storage) senza esposizione pubblica.
• Considerazioni operative:
  • Iniettare i segreti usando variabili d’ambiente sicure o montando volumi Azure Files; per una postura di sicurezza più robusta, recuperare i segreti a runtime tramite un’identità gestita (managed identity) da Key Vault.
  • Monitorare con az container logs e az container attach; eseguire comandi interattivi con az container exec.
  • La fatturazione è al secondo per vCPU e GiB di memoria. I container si avviano rapidamente e sono adatti per carichi di lavoro con picchi (bursty), attività di supporto per la CI, test di integrazione e job attivati da code, dove l’overhead di Kubernetes non è necessario.

Azure Kubernetes Service (AKS)

AKS fornisce un piano di controllo gestito con pool di nodi, scalabilità automatica e opzioni avanzate di networking e identità.

I pool di nodi strutturano la capacità e il posizionamento dei carichi di lavoro. I pool di nodi di sistema eseguono i servizi principali; i pool di nodi utente eseguono i pod delle applicazioni. Utilizzare più pool per separare i carichi di lavoro in base alle esigenze di CPU/Memoria/GPU, al sistema operativo (Linux/Windows), alle dimensioni della VM e alla zona di disponibilità. Impiegare taint/tolleranze per proteggere i pool di sistema, etichette per la selezione e il cluster autoscaler per aggiungere/rimuovere nodi in base ai pod in attesa. Considerare il maxPods per nodo e la densità dei pod durante il dimensionamento.

La pianificazione dei pod è guidata da richieste/limiti di risorse, classi QoS (Guaranteed/Burstable/BestEffort) e vincoli. Utilizzare nodeSelector/affinità e anti-affinità per indirizzare i pod verso i pool appropriati e distribuire le repliche tra zone e domini di errore. I vincoli di distribuzione della topologia (topology spread constraints) migliorano la distribuzione uniforme. Per i servizi critici, definire PodDisruptionBudgets e PriorityClasses per gestire le interruzioni volontarie e il comportamento di prelazione. I DaemonSets posizionano agenti su ogni nodo (logging, monitoraggio) e i CronJobs pianificano container per attività periodiche.

I deployment in AKS sono dichiarativi. I manifest YAML definiscono apiVersion, kind, metadata e spec per Deployments, StatefulSets, Jobs, Services e Ingress. Mantenere i manifest nel controllo di versione, parametrizzarli con overlay di Kustomize per le differenze tra ambienti e applicarli con kubectl apply -f. Il server-side apply e l’uso corretto di etichette/annotazioni aiutano a gestire la proprietà e il rilevamento del drift. Per il packaging di app riutilizzabili, Helm 3 raggruppa template e values. Ospitare i chart Helm come artefatti OCI in ACR e installarli con helm upgrade --install <release> oci://<acr>.azurecr.io/helm/<chart> -f values.yaml. Utilizzare file di values per ogni ambiente, tracciare le versioni dei chart ed eseguire il rollback con helm rollback per un ripristino rapido.

Comandi kubectl che userai quotidianamente:

• Accedere al contesto del cluster: az aks get-credentials -g <rg> -n <cluster> unisce il kubeconfig; l’uso di una macchina aggiunta ad Azure AD con kubectl è sufficiente—non è richiesto Docker per distribuire i manifest.
• Ispezionare e operare: kubectl get nodes,pods,deploy,svc -A; kubectl describe pod <name>; kubectl logs -f <pod>; kubectl exec -it <pod> -- sh; kubectl rollout status deploy/<name>; kubectl set image deploy/<name> container=<image>:<tag>; kubectl top pods; kubectl cordon/drain dei nodi per la manutenzione; kubectl auth can-i per verificare l’RBAC.
• Applicare/patchare: kubectl apply -f k8s/; kubectl patch deploy <name> --type merge -p '{...}'.

Il networking in AKS espone pod e servizi con responsabilità chiare:

• ClusterIP fornisce IP virtuali e DNS interni, con scope a livello di cluster, per la service discovery. È l’impostazione predefinita per il traffico est-ovest tra microservizi.
• NodePort apre la stessa porta su ogni nodo; è meglio utilizzarlo dietro un Ingress o un LB esterno piuttosto che direttamente.
• LoadBalancer esegue il provisioning di un frontend di Azure Load Balancer che punta ai NodePort. Contrassegnare i servizi come interni annotando service.beta.kubernetes.io/azure-load-balancer-internal: "true", o assegnare un IP pubblico statico per un DNS stabile.
• I controller di Ingress forniscono routing L7, terminazione TLS e regole basate su percorso/host. Il NGINX Ingress Controller è una scelta predefinita versatile con annotazioni avanzate. L’Application Gateway Ingress Controller (AGIC) si integra con Azure Application Gateway per funzionalità WAF, autoscaling e capacità L7 di livello enterprise, mantenendo al contempo manifest nativi di Kubernetes. Usare cert-manager per automatizzare il TLS con ACME, o sincronizzare i certificati di Key Vault nei secret di Kubernetes con CSI Secret Store.

L’identità e l’autorizzazione integrano Azure AD senza secret all’interno del cluster:

• Le identità gestite per AKS consistono nell’identità del cluster/piano di controllo e nell’identità del kubelet. Concedere al kubelet il ruolo AcrPull su ACR (az aks update --attach-acr <acr>) in modo che i nodi possano eseguire il pull delle immagini in modo sicuro.
• L’identità del carico di lavoro (workload identity) consente ai pod di accedere alle risorse Azure utilizzando credenziali federate di Azure AD mappate a service account di Kubernetes—senza credenziali a livello di nodo o sidecar. Abilitare l’issuer OIDC sul cluster, creare un’identità gestita assegnata dall’utente, configurare una FederatedIdentityCredential per il service account/namespace e utilizzare l’SDK Azure Identity nell’app. Questo sistema sostituisce il vecchio modello AAD Pod Identity e si allinea con gli standard aperti.
• L’RBAC governa i permessi dell’API di Kubernetes. Associare Role/ClusterRole di Kubernetes a utenti o gruppi di Azure AD tramite RoleBindings/ClusterRoleBindings quando AKS è integrato con Azure AD. In alternativa, abilitare Azure RBAC for Kubernetes Authorization per gestire l’accesso con ruoli RBAC di Azure come Azure Kubernetes Service RBAC Reader, Writer e Admin. Seguire il principio del privilegio minimo, separare i namespace per team o carico di lavoro e controllare l’accesso alla produzione tramite binding basati su gruppi.

Il flusso end-to-end delle immagini verso AKS è semplice e sicuro. Costruire immagini multi-stage, etichettarle con versioni immutabili, caricarle su ACR e distribuirle su AKS con manifest o Helm. AKS esegue il pull da ACR utilizzando l’identità gestita del kubelet e i pod consumano le risorse Azure tramite la workload identity. I servizi sono esposti tramite ClusterIP/LoadBalancer e perfezionati con un controller di ingress che centralizza il TLS e il routing.

Scenario Pratico

Il team Creative Cloud di Adobe sta scomponendo un servizio monolitico di elaborazione multimediale in microservizi, puntando a una distribuzione globale a bassa latenza e a una supply chain rafforzata.

1. Creare e archiviare le immagini usando Dockerfile multi-stage in CI

• Usare Docker multi-stage per compilare i codec multimediali e copiare solo i binari di runtime in un’immagine di base snella, minimizzando le dimensioni e le CVE. Caricare le immagini come <acr>.azurecr.io/processing/encoder:<git-sha> su ACR. Ciò garantisce artefatti riproducibili e sicuri con digest immutabili per il pinning delle versioni in fase di deployment.

2. Rafforzare il registry e automatizzare l’applicazione delle patch

• Creare un registry ACR Premium con endpoint privati in ogni rete virtuale che ospita AKS. Abilitare la replica geografica in North Europe e East US per mantenere i pull locali. Configurare i Task di ACR per attivare la ricompilazione in caso di aggiornamenti dell’immagine di base a monte, propagando automaticamente i layer con le patch. Questo bilancia le prestazioni con la sicurezza e riduce il traffico in uscita (egress).

3. Creare un cluster AKS con pool di nodi e identità separati

• Distribuire AKS con Azure CNI e pool di nodi di sistema/utente: un piccolo pool di sistema per gli add-on del piano di controllo, pool di nodi utente con GPU per la transcodifica e pool per scopi generici per le API. Abilitare l’integrazione con Azure AD, l’issuer OIDC e la workload identity. Assegnare il ruolo AcrPull all’identità del kubelet tramite az aks update --attach-acr. Questo isola i carichi di lavoro, scala in modo efficiente ed elimina i pull di immagini basati su secret.

4. Definire deployment dichiarativi e il packaging

• Creare i file YAML di Kubernetes per Deployments, StatefulSets dove è richiesta la persistenza, Services, HorizontalPodAutoscaler e PodDisruptionBudgets. Impacchettare il servizio di codifica e l’API gateway come chart Helm, pubblicarli come artefatti OCI su ACR e distribuirli con helm upgrade --install utilizzando values specifici per l’ambiente. Ciò fornisce rilasci coerenti e versionati e rollback semplici.

5. Esporre i servizi e imporre la sicurezza L7

• Utilizzare ClusterIP per i microservizi interni e un servizio LoadBalancer con l’Application Gateway Ingress Controller per le API pubbliche. Terminare il TLS a livello di Application Gateway con una policy WAF, gestire i certificati usando cert-manager integrato con Azure DNS per le challenge ACME e instradare ai backend per host/percorso. Ciò produce una sicurezza L7 di livello enterprise con una configurazione nativa di Kubernetes.

6. Implementare l’accesso sicuro dei carichi di lavoro alle risorse Azure

• Per un servizio di creazione di anteprime che scrive su Blob Storage e legge secret, creare un’identità gestita assegnata dall’utente, federarla con il service account tramite la workload identity e concedere i ruoli Storage Blob Data Contributor e Key Vault Secrets User. Il pod si autentica con Azure AD, eliminando il montaggio di secret e abilitando un accesso granulare e verificabile.

7. Gestire il sovraccarico di elaborazione batch con ACI

• Per un sovraccarico sporadico e ad alta priorità di elaborazione batch, attivare gruppi multi-container ACI (codificatore + sidecar per la raccolta di metriche) con restartPolicy: Never all’interno di una subnet con VNet injection. Questo assorbe i picchi senza scalare AKS per gestire i picchi e preserva i percorsi dati privati verso gli account di archiviazione.

Ogni scelta supporta direttamente gli obiettivi di Adobe: ACR Premium con replica geografica ed endpoint privati protegge e accelera i pull delle immagini; AKS con pool di nodi specializzati e workload identity impone l’isolamento e l’accesso con privilegi minimi; Helm e YAML dichiarativo standardizzano i deployment e i rollback; AGIC con WAF fornisce un ingress L7 resiliente e sicuro; e ACI gestisce l’elaborazione batch di picco senza il costo persistente del cluster.

← Azure Cosmos DB · Tutti i domini · Autenticazione →

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

Sfoglia Microsoft →