Microsoft AZ-104: Azure App Service e Compute PaaS — Guida allo studio

By Laurynas Brazys · 6 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

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

Panoramica

L’offerta di calcolo PaaS di Azure combina hosting di app e web completamente gestito, funzioni serverless, automazione dei flussi di lavoro, container on-demand e container orchestrati. Per un amministratore, il successo dipende dalla comprensione dei confini di ciascun servizio, di come gestiscono il networking e l’autenticazione, e di come distribuire e scalare in modo affidabile. Questa sezione tratta App Service (piani, slot di distribuzione, networking e autenticazione integrata), Azure Functions e Logic Apps (piani, trigger, connettori), Azure Container Instances e AKS (pianificazione, ridimensionamento, strumenti operativi) e l’ambiente isolato App Service Environment.

Fondamenti di calcolo di App Service e Functions

I Piani di servizio app (App Service Plan) determinano il pool di risorse di calcolo per Web App, App per le API e App per le funzioni in esecuzione sul piano dedicato. I livelli (tier) hanno capacità e modelli di ridimensionamento distinti:

Free (F1) e Shared (D1) vengono eseguiti su un’infrastruttura condivisa con quote e nessun SLA. Sono adatti solo per esperimenti. Funzionalità come gli slot di distribuzione, l’integrazione VNet e la scalabilità automatica non sono disponibili.
Basic (B) alloca VM dedicate su piccola scala con scalabilità orizzontale (scale-out) manuale. Manca della scalabilità automatica e degli slot di distribuzione.
Standard (S) introduce la scalabilità automatica, istanze multiple, backup giornalieri e slot di distribuzione. È il punto di partenza per i carichi di lavoro di produzione che necessitano di staging.
Premium (Pv2/Pv3) aumenta le prestazioni di CPU/memoria, I/O e i limiti delle funzionalità (più istanze, più slot), e aggiunge funzionalità di rete avanzate come l’integrazione con Endpoint privato (Private Endpoint) e la ridondanza di zona.
Isolated/Isolated v2 vengono eseguiti all’interno di un App Service Environment con risorse di calcolo dedicate e single-tenant all’interno della propria rete virtuale per un isolamento e una conformità rigorosi.

Il ridimensionamento si divide in verticale (scale-up), ovvero la modifica del livello di prezzo/dimensione della VM, e orizzontale (scale-out), ovvero la modifica del numero di istanze. La scalabilità automatica richiede il livello Standard o superiore ed è guidata da regole di Azure Monitor (CPU, memoria tramite le metriche di App Service o metriche personalizzate). Le operazioni di ridimensionamento avvengono per ogni Piano di servizio app e influenzano tutte le app all’interno del piano.

Gli slot di distribuzione forniscono istanze attive dell’app nello stesso piano per preparare (staging) le modifiche. Gli slot esistono dal livello Standard in su, con il livello Standard che ne supporta un numero inferiore e i livelli Premium/Isolated che ne supportano di più. Lo scambio (Swap) orchestra una promozione senza tempi di inattività scambiando il contenuto e la configurazione dello slot, rispettando al contempo le impostazioni specifiche dello slot (impostazioni dell’app e stringhe di connessione permanenti, o “sticky”, che rimangono associate allo slot). Lo scambio con anteprima (Swap with preview) “riscalda” lo slot di destinazione e ne valuta l’integrità prima di completare l’operazione. Il test in produzione (Testing in production) instrada una percentuale del traffico di produzione verso uno o più slot; il routing è permanente (sticky) per client per mantenere l’affinità di sessione durante un aumento graduale del test.

Il networking di App Service offre connettività controllata in uscita e in entrata:

L’integrazione VNet a livello di area geografica (Regional VNet Integration) instrada il traffico in uscita verso una subnet delegata in una rete virtuale nella stessa regione. Abilita il traffico in uscita (egress) verso endpoint privati, on-premise tramite VPN/ExpressRoute e endpoint di servizio. Non modifica il comportamento del traffico pubblico in entrata.
L’Endpoint privato (Private Endpoint) pubblica l’app privatamente all’interno della VNet mappando il frontend dell’app a un indirizzo IP privato; va combinato con le restrizioni di accesso per imporre un traffico in entrata (ingress) esclusivamente privato al di fuori di un ASE.
Le Connessioni ibride (Hybrid Connections) forniscono connettività TCP in uscita dall’app a specifici endpoint host:porta on-premise o in altre reti tramite Azure Relay, senza richiedere modifiche al firewall per il traffico in entrata. Non è un tunnel VNet generico e non supporta UDP.
Le Restrizioni di accesso (Access Restrictions) valutano regole ordinate di autorizzazione/negazione (allow/deny) per IP client, tag di servizio e traffico di rete virtuale (tramite Endpoint privati o regole VNet multi-tenant). Permettono di bloccare l’accesso limitandolo a intervalli specifici, VNet o front-end per soddisfare i requisiti di conformità.

L’Autenticazione/Autorizzazione integrata (“Easy Auth”) antepone alla tua app un gestore di autenticazione ospitato, demandando la convalida dei token senza modifiche al codice. I provider supportati includono Microsoft Entra ID (Azure AD), Microsoft Account, Google, Facebook, Twitter e OpenID Connect generico. È possibile imporre il login per tutte le richieste o lasciarle passare (pass-through) all’app, impostare i destinatari (audience) consentiti e limitare l’accesso a tenant specifici. L’archivio di token (token store) opzionale memorizza nella cache i token del provider ed espone i claim tramite l’endpoint /.auth/me e gli header della richiesta. Va combinato con un’identità gestita assegnata dal sistema per chiamare in modo sicuro i servizi Azure a valle.

Azure Functions offre calcolo basato su eventi attraverso tre modelli di hosting:

Il piano a consumo (Consumption plan) è serverless, con fatturazione per esecuzione e per GB-secondo, e ridimensionamento orizzontale automatico fino a zero istanze (scale-to-zero). Presenta avvii a freddo (cold start) e storicamente non offriva integrazione VNet per alcuni trigger; le funzionalità più recenti sono più ampie, ma per i carichi di lavoro sensibili alla rete è necessario verificare il supporto.
Il piano Premium (Premium plan) elimina gli avvii a freddo con istanze preriscaldate, supporta l’integrazione VNet e gli Endpoint privati, e si ridimensiona in base agli eventi con controlli sul numero minimo/massimo di istanze.
Il piano dedicato (App Service Plan) esegue le Funzioni sulla capacità del proprio Piano di servizio app; il costo è per le istanze riservate indipendentemente dall’uso, con scalabilità automatica opzionale a livello di piano. I trigger delle Funzioni includono HTTP, Timer, Archiviazione (Coda/Blob/Tabella), Service Bus, Event Hubs, Event Grid, Cosmos DB e altri, con binding di input/output per connettere i servizi in modo dichiarativo. Le Durable Functions aggiungono un’orchestrazione stateful in un modello code-first utilizzando funzioni orchestrator e activity, abilitando pattern come fan-out/fan-in, HTTP asincrono, interazione umana e saghe (saga). Lo stato viene reso persistente in un provider di archiviazione (Azure Storage è comune), garantendo flussi di lavoro resilienti e rieseguibili.

Il costo e il comportamento di ridimensionamento differiscono sostanzialmente tra i modelli Piano di servizio app e Consumo. Il Piano di servizio app addebita i costi in base alla dimensione e al numero di istanze sempre attive e si ridimensiona secondo le regole del piano. Il modello a consumo delle Funzioni addebita solo il tempo di esecuzione e la memoria, con un ridimensionamento automatico basato sulla concorrenza e la possibilità di scalare fino a zero. Il piano Premium si colloca tra questi due, combinando capacità preriscaldata riservata con ridimensionamento a raffica (burst scaling).

Container e Kubernetes

Azure Container Instances (ACI) fornisce container on-demand, con fatturazione al secondo, senza dover gestire VM o orchestratori. L’unità di deployment è un gruppo di container: uno o più container pianificati sullo stesso host, che condividono un IP, porte, volumi e ciclo di vita. Si definiscono CPU/memoria per container, si espongono porte e si montano volumi come Azure Files, segreti e emptyDir. Le variabili d’ambiente possono essere in chiaro o sicure (escluse dai log e dalle superfici di metadati). Le policy di riavvio controllano il ciclo di vita: Always (predefinita per servizi a lunga esecuzione), OnFailure (per processi che devono ritentare in caso di uscita con codice diverso da zero) e Never (per task “run-to-completion” per i quali si desidera ispezionare lo stato di uscita senza riavvii). Il networking supporta IP pubblici, IP privati con VNet injection in una subnet delegata ed etichette di nome DNS per gli endpoint pubblici.

Azure Kubernetes Service (AKS) è un control plane Kubernetes gestito con pool di nodi provisionati come Virtual Machine Scale Sets. I pool di nodi differenziano i carichi di lavoro di sistema (componenti kube-system) dai carichi di lavoro utente, supportano più dimensioni di VM e possono eseguire Linux e Windows (Windows richiede almeno un pool di sistema Linux). I pool possono essere marcati con un “taint” per controllare lo scheduling. Gli aggiornamenti sono orchestrati per singolo pool, e maxPods, zone di disponibilità e dischi del sistema operativo effimeri sono configurati alla creazione del pool. Il cluster autoscaler si integra con lo scheduling di Kubernetes per modificare il numero di nodi entro limiti min/max quando ci sono pod in attesa che non possono essere pianificati o quando i nodi sono sottoutilizzati; rispetta i Pod Disruption Budgets ed esegue lo scale-down solo quando è sicuro farlo. L’Horizontal Pod Autoscaler completa questo meccanismo scalando le repliche all’interno di un Deployment in base a metriche.

Nozioni di base di kubectl per l’amministrazione del cluster:

Connettersi con

undefined

per unire il kubeconfig e selezionare il contesto.

Ispezionare le risorse:

undefined

;

undefined

per dettagli ed eventi.

Diagnosticare e interagire:

undefined

per stdout/stderr,

undefined

per la risoluzione interattiva dei problemi.

Applicare lo stato desiderato:

undefined

; usare i namespace per definire l’ambito (scope) delle risorse;

undefined

per cambiare namespace.

I plugin di rete (Azure CNI o kubenet), l’identità (managed identity vs service principal) e l’integrazione con RBAC/Entra ID determinano l’allocazione degli IP dei pod, l’autenticazione del cluster e l’autorizzazione. Assicurarsi che l’identità del cluster disponga delle autorizzazioni per i load balancer, i dischi gestiti e i gruppi di risorse dei nodi.

Integrazione, Networking e Sicurezza

Logic Apps fornisce un motore di workflow gestito con connettori a centinaia di servizi SaaS e Azure. Un workflow è composto da un trigger che avvia l’esecuzione e da azioni che eseguono i passaggi. I trigger includono richieste HTTP, Ricorrenza, messaggi di Service Bus, eventi di Event Grid, eventi di Storage e molti eventi SaaS (ad es., quando un record viene creato in Dynamics 365). Le azioni includono costrutti di controllo (condizioni, cicli, switch), operazioni sui dati (compose, parse JSON, variabili) e operazioni dei connettori (inviare email, accodare un messaggio, chiamare un’API). L’integrazione con i servizi Azure è profonda:

Service Bus e Event Grid forniscono messaggistica ed eventing affidabili per architetture disaccoppiate.
Le Functions possono essere invocate per passaggi di codice personalizzato (sincrono via HTTP o asincrono tramite code).
La managed identity protegge l’accesso a Key Vault, Storage, SQL e altre risorse Azure senza bisogno di segreti. Logic Apps Consumption (multi-tenant) fattura per esecuzione di azione e utilizzo del connettore; Logic Apps Standard (single-tenant) viene eseguito sul runtime di Functions in un piano App Service o Premium, supporta lo sviluppo locale, l’integrazione VNet, i private endpoint e un throughput più elevato. L’Integration Service Environment (ISE) in modalità Consumption fornisce isolamento VNet per i connettori gestiti quando necessario.

App Service Environment (ASE) implementa il tier Isolated per App Service. Distribuito nella propria rete virtuale, l’ASE fornisce risorse di calcolo e storage dedicate (stamp), single-tenant, con controllo sulla rete. Un ASE esterno espone endpoint di ingresso pubblici; un ASE con bilanciatore di carico interno (ILB) pubblica solo un VIP privato per un accesso strettamente privato. Le app in un ASE utilizzano i piani tariffari Isolated/Isolated v2. Si paga sia una tariffa fissa (stamp fee) per l’ambiente sia i costi per istanza dei worker. L’ASE viene scelto quando i requisiti di conformità, isolamento di rete o scalabilità superano le capacità di un App Service multi-tenant. Con l’ASE v3, il deployment e il networking sono semplificati, ma la proposta di base rimane: un App Service dedicato, indirizzabile privatamente, con la propria VNet come perimetro.

La governance degli accessi attraverso questi servizi si basa su Azure RBAC per le azioni sulle risorse, sulle managed identity per l’autenticazione service-to-service e su Conditional Access a livello di piano di identità. Per il controllo in ingresso su App Service, combinare Private Endpoints o ILB ASE con restrizioni di accesso e front-end abilitati per WAF (ad es., Application Gateway o Azure Front Door) secondo necessità. Per il controllo in uscita, usare l’integrazione VNet con NSG, tabelle di routing e private endpoint per i servizi dati.

Operazioni di Distribuzione e Scalabilità

I rilasci affidabili su App Service utilizzano gli slot di distribuzione per convalidare l’integrità e riscaldare le cache prima dello scambio (swap). Contrassegnare la configurazione che differisce per ambiente come “impostazioni dello slot” in modo che non venga trasferita durante lo scambio (ad es. stringhe di connessione, feature flag). Utilizzare lo scambio con anteprima per eseguire probe di integrità o endpoint di warm-up specifici dell’applicazione; se lo stato non è integro, annullare lo scambio. Durante un’analisi canary, abilitare l’instradamento del traffico per dirigere una piccola percentuale sticky a uno slot di staging e aumentarla in modo incrementale. Le impostazioni dell’app specifiche dello slot possono attivare e disattivare le funzionalità beta in sicurezza.

La scalabilità automatica (Autoscale) per gli App Service Plan viene configurata sulla risorsa del piano utilizzando profili (min/max/default basati sul tempo) e regole (soglie metriche con step di scalabilità e periodo di cool-down). Combinare la CPU con metriche personalizzate (ad es. lunghezza della coda) per una scalabilità più precisa. Per le Functions, il piano a Consumo (Consumption) scala automaticamente; monitorare la concorrenza e configurare host.json per comportamenti specifici per trigger (ad es. dimensioni dei batch e prefetch per Service Bus). Il piano Premium scala istanze pre-riscaldate e istanze di burst; allineare il numero minimo di istanze con gli obiettivi di latenza.

Nei container, i criteri di riavvio di ACI dovrebbero riflettere l’intento: i processi batch ottengono Never o OnFailure per evitare loop infiniti; i servizi usano Always. Utilizzare variabili d’ambiente per la configurazione e Azure Key Vault per i segreti, iniettandoli tramite identità gestita (Managed Identity) e codice di avvio o montando i segreti come volumi dove appropriato. In AKS, abilitare il cluster autoscaler con limiti min/max ragionevoli per ogni pool di nodi e configurare gli HPA per i Deployment critici. Prevedere un margine (headroom) e impostare i Pod Disruption Budget per salvaguardare la disponibilità durante gli aggiornamenti e lo scale-in. Convalidare gli aggiornamenti in un pool di nodi canary prima di distribuire su larga scala gli aggiornamenti del cluster o del pool.

Scenario Pratico

Fabrikam, Inc. gestisce un portale clienti e servizi di elaborazione in background. Deve modernizzare l’infrastruttura verso il PaaS, imporre l’accesso tramite rete privata agli archivi dati, supportare distribuzioni blue-green ed eseguire un ETL containerizzato notturno senza gestire VM.

Ospitare il portale su App Service Premium con slot di distribuzione

Creare un App Service Plan in Premium v3 per prestazioni più elevate e più slot, e distribuire la Web App con uno slot di staging.
Configurare le impostazioni dello slot per i valori specifici dell’ambiente e abilitare lo scambio con anteprima e i controlli di integrità.
Motivo: Il piano Premium offre scalabilità automatica, più slot, supporto per Private Endpoint e uno SLA adatto al traffico di produzione. Gli slot forniscono rilasci blue-green sicuri e instradamento canary.

Imporre l’ingresso privato e l’uscita controllata

Abilitare un Private Endpoint per la Web App e impostare restrizioni di accesso per negare la rete pubblica.
Configurare l’integrazione VNet a livello di area (Regional VNet Integration) verso una subnet delegata per l’accesso in uscita agli archivi dati privati e on-premise tramite ExpressRoute.
Motivo: Il Private Endpoint più le restrizioni garantiscono un accesso esclusivamente privato; l’integrazione VNet instrada il traffico in uscita attraverso il perimetro della VNet per una policy firewall coerente.

Implementare l’elaborazione in background con Azure Functions Premium

Distribuire una Function App su un piano Premium con un’identità gestita assegnata dal sistema, utilizzando trigger di Service Bus e Storage per carichi di lavoro basati su code.
Impostare un numero minimo di istanze pre-riscaldate per eliminare gli avvii a freddo e integrare con la stessa VNet.
Motivo: Azure Functions Premium soddisfa i requisiti di bassa latenza e VNet, preservando al contempo la scalabilità serverless per carichi di lavoro con picchi improvvisi (bursty).

Orchestrare flussi di lavoro cross-service con Logic Apps Standard

Costruire flussi di lavoro per coordinare l’onboarding dei clienti: attivazione su un messaggio di Service Bus, chiamata alla Function App, scrittura su Storage e notifica tramite il connettore di Microsoft 365.
Utilizzare l’identità gestita per l’accesso a Key Vault e Storage e distribuire nello stesso App Service Plan per sfruttare l’integrazione VNet e gli endpoint privati.
Motivo: Logic Apps fornisce un’orchestrazione visiva e resiliente e connettori nativi; il piano Standard offre l’integrazione VNet e prestazioni single-tenant.

Eseguire l’ETL notturno in Azure Container Instances

Definire un gruppo di contenitori con il container ETL, montare una condivisione di Azure Files per i dati intermedi, impostare variabili d’ambiente sicure e usare restartPolicy: Never.
Collegare il gruppo alla subnet delegata della VNet per l’accesso privato ai database.
Motivo: ACI fornisce capacità di calcolo orientata ai processi (job-oriented) con fatturazione al secondo, senza l’overhead di un cluster, e si integra con la VNet per la località dei dati e la sicurezza.

Prepararsi per i microservizi containerizzati con AKS

Creare un cluster AKS con un pool di nodi di sistema Linux di piccole dimensioni e un pool di nodi utente dimensionato per il carico previsto, abilitare il cluster autoscaler (con limiti min/max) e integrare con Entra ID e Azure CNI per IP a livello di pod.
Usare kubectl per distribuire un microservizio canary e impostare un HPA basato su CPU e metriche personalizzate.
Motivo: AKS fornisce un’orchestrazione di livello enterprise quando i servizi si moltiplicano; l’autoscaler e l’HPA allineano la capacità con la domanda e kubectl offre un controllo operativo standard.

← Archiviazione di Azure · Tutti i domini · Database di Azure e Servizi dati →

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