Microsoft AZ-204: Azure App Service e App Web — 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 App Service è una piattaforma di hosting basata su HTTP completamente gestita per app web, API REST e servizi di backend, che supporta carichi di lavoro basati su codice e container su Windows e Linux. Fornisce funzionalità di primo livello per la scalabilità, i flussi di lavoro di distribuzione, l’autenticazione, l’isolamento di rete, l’elaborazione in background e la configurazione sicura. La sua padronanza implica la comprensione dei piani di App Service e della scalabilità, degli slot di distribuzione e della gestione del traffico, dei percorsi di integrazione CI/CD, di Easy Auth, dei domini personalizzati e TLS, dei WebJobs, dell’App Service Environment (ASE) e dei pattern di configurazione sicura con Key Vault.

Piani, scalabilità e slot di distribuzione

Un piano di App Service definisce le risorse di calcolo che ospitano le tue app. Tutte le app in un piano condividono lo stesso pool di VM e la stessa configurazione di scalabilità.

Livelli di prezzo:
- Free (F1)/Shared (D1): Solo per sviluppo e test. Nessun SLA. Nessun TLS personalizzato. Nessuno slot di distribuzione.
- Basic (B1–B3): VM dedicate, scalabilità orizzontale manuale. Nessuna scalabilità automatica. Funzionalità limitate.
- Standard (S1–S3): Aggiunge la scalabilità automatica e gli slot di distribuzione. Baseline per la produzione.
- Premium v2/v3 (P1v2/P1v3+): Risorse di calcolo più recenti, storage più veloce, funzionalità di rete avanzate, ridondanza di zona (sugli SKU supportati) e scalabilità superiore. Ideale per la produzione aziendale e per throughput elevati.
- Isolated (I1v2+) in ASE: Dedicato alla rete virtuale di un cliente con isolamento di rete e scalabilità massiva.
Scalabilità verticale (scale up) vs scalabilità orizzontale (scale out):
- La scalabilità verticale sposta il piano su uno SKU superiore per ottenere più CPU, memoria, dischi più veloci o funzionalità avanzate (ad es., Premium v3 per prestazioni e funzionalità migliori).
- La scalabilità orizzontale aumenta il numero di istanze per distribuire il carico orizzontalmente. I livelli Standard e superiori supportano la scalabilità automatica con regole basate su metriche come CPU, memoria (Linux), lunghezza della coda HTTP, richieste, metriche personalizzate o pianificazioni. Il livello Basic supporta solo la scalabilità orizzontale manuale. La scalabilità si applica a tutte le app all’interno di un piano.
Slot di distribuzione e scambi di slot:
- I livelli Standard e superiori supportano più slot (ad esempio, staging e produzione). Gli slot vengono eseguiti sullo stesso piano, ognuno con il proprio nome host e la propria configurazione.
- Lo scambio (swap) sposta il contenuto e lo stato di runtime da uno slot di origine a uno di destinazione con un downtime quasi nullo, riscaldando la destinazione prima del passaggio del traffico. Utilizzare applicationInitialization (Windows) o i controlli di integrità (health check) per garantire che l’app sia pronta prima dello scambio. Lo scambio con anteprima (swap with preview) consente la convalida prima di finalizzare l’operazione.
- Contrassegnare le voci di configurazione come impostazioni dello slot (slot settings) per mantenerle “appiccicate” (sticky) allo slot durante gli scambi (ad es., stringhe di connessione al database, segreti ed endpoint di diagnostica). Le impostazioni non contrassegnate si spostano con il codice durante lo scambio.
Instradamento del traffico con gli slot:
- Instradare una percentuale del traffico live verso uno slot non di produzione per il canary testing (test in produzione). I cookie “fissano” (pin) gli utenti a uno slot dopo l’assegnazione per preservare la coerenza della sessione.

Distribuzione e CI/CD: GitHub, Azure DevOps e registri di container

Il Deployment Center integra i flussi CI/CD più comuni:

GitHub Actions:
- App Service può generare uno scaffold di un flusso di lavoro utilizzando la build Oryx o la distribuzione di container. Al push su un ramo, le Actions eseguono la build e la distribuzione sullo slot selezionato. Supporto per build a matrice (matrix build), ambienti e segreti. Per i container Linux, il flusso di lavoro può creare e inviare l’immagine ad ACR o Docker Hub, quindi attivare una distribuzione della web app.
Azure DevOps:
- Le pipeline (YAML o classiche) gestiscono le fasi di build e rilascio, le approvazioni, i controlli sull’ambiente e il gating multi-fase. Utilizzare task come: Azure Web App, Azure Web App for Container o AzureCLI per distribuzioni basate su ARM/Bicep. I gruppi di variabili e i segreti supportati da Key Vault centralizzano la configurazione.
Registri di container:
- App Service for Containers preleva le immagini da ACR, Docker Hub o da registri privati. Configurare la distribuzione continua tramite webhook di ACR verso l’app; il push di una nuova immagine attiva un pull e un riavvio. Fissare l’immagine tramite tag o digest. Per la sicurezza in produzione, utilizzare i digest delle immagini e gli slot canary prima della promozione.
Meccanismi di distribuzione aggiuntivi:
- Kudu supporta il push basato su Git, Zip Deploy e Run From Package per build riproducibili. Il file .deployment e gli script personalizzati possono coordinare i passaggi di build prima che il sito inizi a servire il traffico. Per un’igiene di rilascio di livello enterprise, combinare gli slot con la CI/CD per convalidare i controlli di integrità e il riscaldamento prima dello scambio.

Sicurezza, identità, domini e TLS

L’autenticazione/autorizzazione di App Service (Easy Auth) delega la gestione dell’identità alla piattaforma senza richiedere middleware nel proprio codice.

Provider:
- Microsoft Entra ID (piattaforma di identità Microsoft), Google, Facebook, GitHub e Twitter, oltre a qualsiasi provider compatibile con OpenID Connect, incluso Entra ID B2C. Configurare ID client/segreti, l’emittente (issuer) e i destinatari (audience)/ambiti (scope) consentiti per i token. Scegliere l’azione di accesso (consentire l’accesso anonimo o richiedere l’autenticazione).
Archivio di token e header:
- Abilitare l’archivio di token (token store) per memorizzare nella cache i token di accesso/aggiornamento ottenuti durante il flusso di accesso, recuperabili tramite /.auth/me e aggiornabili tramite /.auth/refresh. App Service inserisce i claim dell’utente negli header della richiesta (ad esempio, X-MS-CLIENT-PRINCIPAL in Base64) in modo che l’app possa derivare l’identità senza dipendenze da SDK. Utilizzare l’endpoint di logout della piattaforma per cancellare le sessioni.
Domini personalizzati:
- Mappare record CNAME (consigliato) o A/ALIAS al nome host predefinito dell’app. Verificare la proprietà del dominio con record TXT, se richiesto. Associare (bind) il nome host personalizzato in App Service.
Certificati SSL/TLS:
- Imporre “Solo HTTPS” (HTTPS Only) e impostare la versione minima di TLS. Associare i certificati tramite SNI (più certificati per IP) o SSL basato su IP (IP dedicato). Caricare certificati privati (PFX) per un controllo dei certificati di livello produzione. L’App Service Managed Certificate fornisce un certificato gratuito, a rinnovo automatico e convalidato a livello di dominio per nomi host non-wildcard; non può essere esportato e richiede un livello supportato. Utilizzare l’integrazione con Key Vault per gestire e rinnovare automaticamente i certificati privati su larga scala.
Certificati client (mTLS):
- Opzionalmente, richiedere i certificati client in ingresso e passarli all’app per la convalida. Combinare con Web Application Firewall e reverse proxy (ad esempio, Application Gateway) per un TLS end-to-end.

Elaborazione in background e ambienti isolati

WebJobs e ASE rispondono a scenari di elaborazione in background e isolamento di rete.

WebJobs:
- I WebJobs continui (Continuous WebJobs) vengono eseguiti perennemente su ogni istanza dell’app web, adatti per l’elaborazione di code o loop di eventi. Richiedono l’impostazione Always On (piani Standard e superiori) per mantenerli in esecuzione. La scalabilità segue il numero di istanze del piano dell’app; applicare un comportamento singleton nel codice se si desidera un solo worker attivo.
- I WebJobs attivati (Triggered WebJobs) vengono eseguiti on-demand o secondo una pianificazione (CRON tramite settings.job). Ideali per processi batch, ETL o manutenzione periodica.
- Il WebJobs SDK fornisce trigger e binding per Azure Storage Queues, code/topic di Service Bus, Blob e Timer con metodi di funzione dichiarativi e checkpointing automatico. Un WebJob attivato da una coda reagisce immediatamente ai nuovi messaggi, scala con le istanze dell’app e utilizza la gestione delle “poison queue” per l’isolamento dei guasti. Log e dashboard sono accessibili in Kudu.
App Service Environment (ASE):
- ASEv3 ospita i piani di App Service all’interno della tua VNet con SKU Isolated v2, fornendo risorse di calcolo dedicate, isolamento del data plane e IP privati. Scegliere un External ASE per l’ingresso pubblico (public ingress) o un Internal Load Balancer (ILB) ASE per mantenere tutto il traffico in entrata privato all’interno della VNet. Integrare con DNS privati, firewall e NVA/WAF secondo necessità.
- ASE consente un controllo granulare del traffico in uscita (egress), l’ispezione della rete e l’allineamento alla conformità. Supporta l’hosting su larga scala con confini di rete prevedibili ed è fatturato separatamente dalle istanze del piano.

Configurazione, stringhe di connessione e riferimenti a Key Vault

La configurazione dell’app viene iniettata a runtime e può essere specifica per lo slot di distribuzione.

App settings:
- Coppie chiave-valore disponibili per l’app come variabili d’ambiente. Contrassegnarle come impostazioni di slot (slot settings) per mantenere valori distinti per ogni slot. Sfruttare il percorso di Health check per rimuovere le istanze non integre dalla rotazione durante i rollout. Le modifiche attivano il riavvio dell’app, a meno che non siano configurati pattern di ricaricamento dinamico nel proprio framework.
Connection strings:
- Gestite separatamente ed esposte come variabili d’ambiente; le app .NET ricevono anche una configurazione specifica per il provider. I tipi includono SQLAzure, SQLServer, MySQL, PostgreSQL e Custom. Contrassegnarle come impostazioni di slot (slot settings) dove appropriato per evitare lo scambio di segreti durante lo swap.
Riferimenti a Key Vault:
- Fare riferimento ai segreti direttamente in App Settings e Connection Strings usando la sintassi speciale @Microsoft.KeyVault(SecretUri=https://<vault>.vault.azure.net/secrets/<name>/<version>) o URI senza versione per recepire automaticamente le rotazioni. Assegnare un’identità gestita, assegnata dal sistema o dall’utente, all’app, quindi concederle i permessi “Get secret” (tramite RBAC o access policy) sul vault. La piattaforma risolve e aggiorna i valori senza esporre i segreti nella configurazione di App Service. Per utilizzare i certificati TLS da Key Vault, importarli come certificati o utilizzare i riferimenti ai certificati supportati dalla piattaforma.

Approfondimento sugli slot di distribuzione e l’eccellenza operativa

Utilizzare uno slot di staging come destinazione della CI/CD. Dopo la distribuzione:

Eseguire ping di warm-up e health check per inizializzare JIT, cache e connessioni al database.
Convalidare le differenze di configurazione utilizzando le impostazioni dello slot per isolare i segreti e gli endpoint di produzione.
Eseguire lo scambio con anteprima (swap with preview) per testare lo slot di staging sull’hostname di produzione prima di finalizzare. Se si verificano errori, annullare lo scambio per un rollback istantaneo.
Per la distribuzione progressiva, utilizzare il routing del traffico per dirigere una piccola percentuale verso lo slot canary e monitorare le metriche e i log di App Insights. Aumentare gradualmente, quindi completare lo scambio quando gli SLO sono rispettati.

Scenario di un problema pratico

Starbucks sta lanciando una nuova piattaforma di ordinazione web che deve gestire picchi di traffico durante le promozioni, integrarsi con i login social, proteggere le API interne ed elaborare in modo affidabile i flussi di lavoro degli ordini in background.

Scegliere un piano App Service Premium v3 con due slot di distribuzione (staging, produzione)

Perché: Premium v3 fornisce CPU e SSD più veloci per caricamenti di pagina a bassa latenza e un throughput più elevato, oltre a slot e autoscale. Gli slot consentono scambi a zero downtime e rollback rapidi in caso di picchi di traffico promozionale.

Implementare la CI/CD con GitHub Actions per distribuire sullo slot di staging

Perché: GitHub Actions offre un’automazione nativa del repository. La distribuzione in staging consente il warm-up e la convalida prima che il traffico dei clienti venga interessato. Il flusso di lavoro utilizza Oryx per la build e la distribuzione al push sul ramo main, garantendo build coerenti.

Abilitare Easy Auth con i provider Microsoft Entra ID e Google; abilitare il Token Store

Perché: Easy Auth si fa carico dei flussi OAuth/OIDC, riducendo la superficie di codice di sicurezza personalizzato. La presenza di più provider supporta le preferenze di accesso dei consumatori. Il Token Store semplifica le chiamate API downstream (ad esempio, al microservizio del profilo fedeltà) utilizzando i token memorizzati nella cache ed esposti tramite gli endpoint /.auth.

Configurare domini personalizzati e TLS

Perché: Associare order.starbucks.com tramite CNAME, imporre HTTPS Only e impostare TLS 1.2 come versione minima per la conformità. Utilizzare un App Service Managed Certificate per lo slot di staging per ridurre il sovraccarico di gestione e caricare un PFX dalla CA aziendale per la produzione per soddisfare le policy del brand e dei certificati.

Utilizzare il WebJobs SDK con un trigger di Azure Storage Queue per l’evasione degli ordini

Perché: Un WebJob continuo elabora i messaggi man mano che arrivano, disaccoppiando il checkout dall’evasione e livellando i picchi. Con Always On e lo scale-out basato sul piano, il throughput aumenta automaticamente con l’aggiunta di istanze. La gestione della poison queue isola i messaggi problematici senza interrompere la pipeline.

Proteggere i segreti in uscita con riferimenti a Key Vault e un’identità gestita assegnata dal sistema

Perché: I segreti non risiedono mai nella configurazione di App Service. L’identità ha un accesso a Key Vault con privilegi minimi e gli URI dei segreti senza versione consentono una rotazione senza interruzioni.

Proteggere le API interne con il networking

Perché: Posizionare i microservizi interni dietro un endpoint privato; la web app pubblica li chiama tramite VNet Integration (Premium v3) verso un backend protetto. Se in futuro fosse necessario un isolamento più rigoroso, migrare il livello web in un ILB ASE per rendere privato tutto il traffico in ingresso, mantenendo al contempo le funzionalità di App Service.

Strategia di rilascio con canarying e scambio

Perché: Indirizzare il 5% del traffico verso lo staging per una convalida in tempo reale durante una promozione. Monitorare la latenza, i budget di errore e la conversione al checkout tramite Application Insights. Se i risultati sono positivi, eseguire uno scambio con anteprima (swap with preview); in caso contrario, annullare e investigare, preservando l’esperienza del cliente.

Tutti i domini · Azure Functions e Calcolo Serverless →

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