Microsoft AZ-204: Azure Functions e Calcolo Serverless — 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 Functions è un servizio di calcolo serverless ottimizzato per carichi di lavoro event-driven e di breve durata. Astrae l’infrastruttura in modo che tu possa concentrarti sul codice che risponde a eventi provenienti da endpoint HTTP, code, blob, feed di modifiche dei dati e servizi di streaming. Si seleziona un piano di hosting che governa la scalabilità, i prezzi e il comportamento dei cold start; si associa il codice a trigger e origini dati con binding dichiarativi; e opzionalmente si compongono flussi di lavoro affidabili e di lunga durata utilizzando Durable Functions. Configurazione robusta, deployment ripetibile e osservabilità approfondita con Application Insights completano la piattaforma per sistemi di livello production.

Piani di hosting, scalabilità e cold start

La selezione di un piano di hosting determina le caratteristiche di esecuzione e i costi.

Piano a consumo (Consumption):
- Scalabilità e prezzi: Si paga per esecuzione e per consumo di risorse. La piattaforma scala orizzontalmente (scale out) in modo automatico in base agli eventi. Il numero di istanze si riduce a zero quando inattivo.
- Limiti di esecuzione: Il timeout della funzione è configurabile fino a 10 minuti per le funzioni non HTTP; le funzioni HTTP hanno timeout pratici più brevi a causa della connettività del client.
- Cold start: I cold start si verificano dopo periodi di inattività o durante lo scale-out, quando nuove istanze vengono inizializzate. Il tempo di avvio dipende dal linguaggio, dalle dipendenze e dalle dimensioni dell’app.
- Networking/Funzionalità: Supporta il networking pubblico per impostazione predefinita. Set di funzionalità limitato rispetto al piano Premium (ad esempio, nessuna integrazione VNET). Gli slot di distribuzione non sono disponibili.
Piano Premium:
- Scalabilità e prezzi: Scala in base agli eventi ma mantiene istanze “preriscaldate” (pre-warmed) per eliminare i cold start. La fatturazione avviene per core-secondo e memoria allocata per le istanze attive e preriscaldate.
- Limiti di esecuzione: Durata di esecuzione praticamente illimitata (soggetta ai vincoli del client HTTP). Consigliato per carichi di lavoro sensibili alla latenza o più pesanti.
- Mitigazione dei cold start: Le istanze preriscaldate mantengono il runtime attivo (“hot”). È possibile controllare il numero di istanze preriscaldate per piano, garantendo una latenza prevedibile durante i picchi di carico (burst).
- Networking/Funzionalità: Supporto per integrazione VNET, endpoint privati, dimensioni delle istanze maggiori e slot di distribuzione.
Piano dedicato (App Service):
- Scalabilità e prezzi: Viene eseguito su istanze App Service pre-allocate (provisioned) con regole di scalabilità manuale o automatica. Si paga per il piano App Service sottostante, indipendentemente dall’utilizzo.
- Limiti di esecuzione: Nessun timeout imposto dalla piattaforma per l’esecuzione in background. Ideale quando si dispone già di capacità App Service inutilizzata o si necessita di prestazioni costanti.
- Mitigazione dei cold start: Abilitare l’opzione Always On per mantenere l’app caricata. Non avviene la scalabilità a zero; le istanze rimangono attive (“warm”).

Scegliere il piano a consumo (Consumption) per carichi di lavoro sporadici e ottimizzati per i costi, il piano Premium per esigenze di bassa latenza e VNET, e il piano dedicato (Dedicated) quando si consolida con la capacità App Service esistente o si richiede il pieno controllo. Per una latenza ultra-bassa, il piano Premium con istanze preriscaldate o il piano dedicato con Always On riducono i cold start. È possibile minimizzare ulteriormente l’impatto dei cold start riducendo le dipendenze, utilizzando l’opzione run-from-package e inizializzando i client in modo differito (lazy).

Trigger e Binding

Le funzioni sono attivate da trigger e interagiscono con i dati tramite i binding. I trigger definiscono come e quando una funzione viene eseguita. I binding si connettono in modo dichiarativo a servizi esterni per l’input/output, senza la necessità di codice SDK imperativo.

Trigger comuni:

Trigger HTTP: Espone endpoint per API in stile REST o webhook. I livelli di autorizzazione includono Anonymous, Function e Admin, applicati tramite chiavi o autenticazione della piattaforma. Considerare l’idempotenza e i timeout per le attività di lunga durata; quando necessario, delegare il lavoro a una coda o a Durable Functions.
Trigger Timer: Pianificazioni basate su CRON eseguite su una singola istanza per app (per ogni timer). Utilizza espressioni NCRONTAB con configurazione del fuso orario. Ideale per attività di manutenzione, polling e pulizia.
Trigger Azure Storage Queue: Risponde ai messaggi in una coda. Supporta la gestione dei messaggi non elaborabili (poison message) con una coda -poison dopo il superamento di una soglia di tentativi di rimozione (dequeue count). Configurare la dimensione del batch, il timeout di visibilità e la concorrenza tramite host.json.
Trigger Azure Blob Storage: Reagisce agli eventi di creazione/aggiornamento dei blob utilizzando una combinazione di polling e notifiche di Event Grid. Utilizzare pattern di percorso per limitare l’ambito a specifici container e prefissi. Comprendere la consistenza finale (eventual consistency) e il comportamento dei tentativi di ripetizione (retry) per il caricamento di blob di grandi dimensioni.
Trigger Azure Event Hubs: Elabora flussi di eventi ad alto throughput con checkpointing. Configurare la concorrenza per partizione, la dimensione del batch e il prefetch per ottimizzare il throughput. Adatto per la telemetria e l’elaborazione di flussi (stream processing) con mantenimento dell’ordine per ogni partizione.
Trigger Azure Service Bus: Supporta la sottoscrizione a code o topic. Configurare i comportamenti di maxConcurrentCalls, prefetch e completamento automatico (auto-complete). Le code dei messaggi non recapitabili (dead-letter queue) raccolgono i messaggi che superano i tentativi di consegna per un’ispezione successiva.
Trigger Azure Cosmos DB: Ascolta il feed di modifiche (change feed) per inserimenti e aggiornamenti. Scala con il numero di partizioni fisiche; assicurare un provisioning di RU sufficiente. Utilizzare una collection dei lease per coordinare lo scale-out tra le istanze.

Binding:

Binding di input: Forniscono dati alla funzione, ad esempio il contenuto di un blob, un’entità di una tabella, documenti di Cosmos DB o metadati di un messaggio in coda. In .NET, gli attributi (es.

undefined

) o il file function.json definiscono il binding; in altri linguaggi, la configurazione è dichiarativa.

Binding di output: Scrivono dati senza l’uso di SDK, ad esempio accodando un messaggio, creando un blob, inviando a Event Hub/Service Bus o scrivendo su Cosmos DB. Le funzioni possono avere più binding di output o restituire un singolo output dalla firma della funzione.
Espressioni di binding: Parametrizzano i dettagli di connessione e i percorsi utilizzando segnaposto, ad esempio {queueTrigger}, {rand-guid}, e impostazioni dell’applicazione basate sull’ambiente. Le proprietà di connessione fanno riferimento ai nomi delle impostazioni dell’applicazione, abilitando la rotazione e la gestione dei segreti. Preferire connessioni basate su identità con identità gestita (managed identity) dove supportato, per evitare di incorporare segreti.
Concorrenza e batch: Controllare la concorrenza e le dimensioni dei batch in host.json per ogni estensione (queues, serviceBus, eventHub) per ottimizzare il throughput e l’utilizzo della memoria. Verificare la gestione dei messaggi non elaborabili (poison) e non recapitabili (dead-letter) per garantire che gli errori vengano correttamente gestiti.

Progettare trigger e binding per garantire idempotenza, backpressure e isolamento degli errori. Per le origini con consegna “at-least-once” (almeno una volta) come code, Event Hubs e Service Bus, scrivere funzioni che siano idempotenti e resilienti ai tentativi di ripetizione.

Durable Functions: Pattern di Orchestrazione Affidabili

Durable Functions estende Azure Functions con un’orchestrazione stateful e affidabile per workflow di lunga durata, utilizzando un framework di task durevoli.

Tipi di funzione:

Funzioni orchestrator: Descrivono la logica del workflow nel codice utilizzando costrutti deterministici. Gli orchestrator rieseguono lo stato in base agli eventi e devono evitare API non deterministiche (DateTime.Now, numeri casuali, chiamate di rete) senza gli appositi helper. Utilizzare le API del client di orchestrazione Durable per avviare, interrogare e gestire le istanze.
Funzioni activity: Eseguono unità di lavoro discrete come chiamare API esterne, eseguire operazioni CPU-bound o task di I/O. Le activity sono rieseguibili (retryable) e scalabili in modo indipendente.
Funzioni entity: Forniscono entità durevoli e indirizzabili con uno stato piccolo e consistente e operazioni associate (es. contatori, stato di un dispositivo). Le entità elaborano operazioni serializzate con consistenza single-threaded.

Pattern:

Concatenazione di funzioni (Function chaining): Esegue le activity in una sequenza definita (A → B → C), passando i risultati alla successiva. Utile per pipeline con dipendenze.
Fan-out/fan-in: Avvia più activity in parallelo e ne aggrega i risultati. Gli orchestrator coordinano il tutto con una semantica simile a Task.WhenAll. Utilizzare questo pattern per l’elaborazione parallela di task indipendenti.
Interazione umana (eventi esterni): Attende un input esterno (es. un’approvazione) utilizzando WaitForExternalEvent con timeout e logiche di escalation. Combinare con timer durevoli per implementare SLA e logiche di compensazione.
API HTTP asincrone: Avvia le orchestrazioni e restituisce un 202 Accepted con URL di stato/query. I client effettuano il polling degli endpoint di stato esposti dal binding del client Durable per ottenere il risultato finale o lo stato.
Monitor: Checkpoint ricorrenti eseguiti secondo una pianificazione, ad esempio effettuando il polling di un endpoint finché una condizione non è soddisfatta, utilizzando timer durevoli per evitare di impegnare risorse di calcolo.
Aggregatore/Entità (Aggregator/Entity): Memorizza un piccolo stato accanto alla logica utilizzando le funzioni entity per un coordinamento granulare senza un workflow completo.

Durable Functions garantisce l’esecuzione “at-least-once” (almeno una volta) delle activity e l’avanzamento “exactly-once” (esattamente una volta) dello stato dell’orchestrator. Lo stato viene persistito su storage (l’impostazione predefinita è Azure Storage); assicurarsi che l’account di storage soddisfi i requisiti di throughput e affidabilità. Utilizzare policy di retry personalizzate per gli errori transitori e sollevare eventi per l’interazione esterna. Per processi molto lunghi, le orchestrazioni durevoli possono essere eseguite per giorni o mesi grazie alla durabilità integrata.

Configurazione, Deployment e Osservabilità

La configurazione della Function App è stratificata e sensibile all’ambiente (environment-aware).

host.json: Controlla il comportamento del runtime e delle estensioni. Configura il logging (campionamento, livelli di log), functionTimeout, le impostazioni delle estensioni (dimensioni dei batch, concorrenza, prefetch) e la versione dello schema JSON. Mantenere host.json nel controllo di versione.
local.settings.json: Impostazioni di sviluppo locale, incluse stringhe di connessione e impostazioni dell’app. Non viene distribuito su Azure. Trattare i segreti in modo appropriato; escluderlo dai repository pubblici e utilizzare i user-secrets o l’iniezione di variabili d’ambiente per lo sviluppo locale.
Impostazioni dell’applicazione (Application settings): Memorizzate nella configurazione della Function App (App Service). Le impostazioni critiche includono AzureWebJobsStorage (per l’account di storage utilizzato da trigger, log e checkpoint), stringhe di connessione specifiche per le estensioni e qualsiasi configurazione personalizzata. Contrassegnare i segreti come impostazioni di slot (slot settings) per evitarne lo scambio (swap). Utilizzare i riferimenti a Key Vault con managed identity per evitare di memorizzare i segreti in testo semplice.

Opzioni di deployment:

Zip Deploy: Carica un file ZIP degli artefatti compilati nell’app. Veloce e semplice per la CI/CD. Utilizzare az functionapp deployment source config-zip o l’API zipdeploy. Scrive i file nella directory dei contenuti.
Run-From-Package: Imposta WEBSITE_RUN_FROM_PACKAGE su un URL del pacchetto (o 1 per l’ultima versione). Il runtime monta il pacchetto in modalità di sola lettura, migliorando il cold start ed eliminando i problemi di blocco dei file (file lock) durante il deployment. Archiviare il pacchetto in Blob Storage con una SAS URL per rollback riproducibili.
Slot di distribuzione (Deployment slots): Gli slot di stage e di produzione consentono swap a zero downtime con warmup. Gli slot sono supportati nei piani Premium e Dedicated. Configurare impostazioni specifiche per lo slot (flag ‘slot setting’) per segreti ed endpoint per prevenire la fuga di informazioni tra ambienti (cross-environment leakage). Utilizzare il warmup preSwap per convalidare estensioni e binding prima che il traffico venga spostato.

Monitoraggio con Application Insights:

Log di invocazione (Invocation logs): Ogni invocazione di funzione emette telemetria strutturata che include Richieste (Requests), Tracce (Traces), Eccezioni (Exceptions) e Dipendenze (Dependencies). Utilizzare ILogger (o un equivalente) per i log strutturati. Gli ID di operazione e correlazione collegano l’attività e le dipendenze tra i vari servizi.
Live Metrics: Vista in tempo reale di throughput, fallimenti e latenza senza campionamento. Utile per osservare i deployment, lo scaling e i percorsi critici (hot path). Filtrare per nome della funzione per isolare i problemi.
Fallimenti e affidabilità (Failures and reliability): Ispezionare le Eccezioni (Exceptions), le Richieste fallite (failed Requests) e i fallimenti delle dipendenze. Configurare alert sulla percentuale di fallimento (failure rate), sulle anomalie di FunctionExecutionCount o sulla crescita della coda DLQ/poison. Per i trigger di Storage Queue, monitorare la coda -poison; per Service Bus/Event Hubs, monitorare lo stato della coda dead-letter e dei checkpoint. Ottimizzare le policy di retry e di backoff in host.json per ridurre l’impatto degli errori transitori.
Tracciamento distribuito (Distributed tracing): Abilitare gli header di tracciamento W3C per propagare la correlazione tramite HTTP e messaggistica. Per le Durable Functions, il framework collega la telemetria dell’orchestrazione e delle attività, facilitando la diagnostica end-to-end. Regolare il campionamento per bilanciare costi e fedeltà dei dati.

Gestire le funzioni con l’automazione del deployment (GitHub Actions/Azure Pipelines), health probe per gli endpoint HTTP e un’ottimizzazione consapevole dell’autoscaling. Mantenere i pacchetti snelli, mettere in cache i client (es. HttpClient, client di Service Bus) come singleton statici e convalidare che le impostazioni di connessione dei binding si risolvano all’avvio per prevenire fallimenti a runtime.

Scenario Pratico

Contoso Retail lancia un servizio di promozioni che applica sconti in tempo reale quando i clienti aggiungono articoli al carrello. Il backend deve rispondere a un traffico ad alta variabilità con bassa latenza, chiamare un’API di pricing di terze parti e aggiornare un documento del carrello in Cosmos DB. Il team Operations desidera deployment a zero downtime e una visibilità approfondita sui fallimenti.

Scegliere il piano di hosting e strutturare l’app

Utilizzare un piano Azure Functions Premium con due istanze pre-riscaldate (pre-warmed) e integrazione VNET. Il piano Premium elimina i cold start per le interazioni con il carrello sensibili alla latenza e protegge il traffico in uscita verso l’API di terze parti tramite un NAT o un firewall nella VNET.
Creare una singola Function App con una funzione attivata da HTTP (HTTP-triggered) per l’endpoint del carrello e un orchestratore Durable Functions per coordinare il recupero degli sconti e l’aggiornamento del carrello.

Implementare l’orchestrazione Durable per affidabilità e parallelismo

Funzione orchestratore (Orchestrator function): Concatenare i passaggi per convalidare l’input, eseguire un fan-out per recuperare in parallelo gli sconti per ogni articolo del carrello tramite funzioni di attività (activity functions), quindi eseguire un fan-in per aggregare il prezzo migliore. L’orchestrazione Durable garantisce un flusso di controllo deterministico e resilienza ai riavvii.
Funzioni di attività (Activity functions): Un’attività chiama l’API di terze parti con policy di retry; un’altra aggiorna il carrello in Cosmos DB tramite un output binding. Le attività incapsulano l’I/O esterno e possono essere ritentate indipendentemente senza duplicare la logica dell’orchestratore.

Configurare trigger e binding per semplicità

Trigger HTTP con autenticazione di tipo Function per accettare richieste firmate dal frontend web. Restituire un 202 con un URL di stato per i carrelli che richiedono un’elaborazione lunga (long-running), o un 200 per i percorsi veloci.
Output binding per Cosmos DB sull’attività per eseguire l’upsert del documento del carrello. Le espressioni di binding utilizzano il cartId dal payload HTTP per puntare alla chiave di partizione corretta.
Utilizzare managed identity e connessioni basate su identità per i riferimenti a Cosmos DB e Key Vault, rimuovendo i segreti dalle impostazioni dell’app.

Ottimizzare configurazione e deployment

host.json imposta functionTimeout su illimitato (Premium) e configura timeout HTTP compatibili con service mesh. I livelli di logging sono impostati su Information per la produzione e il campionamento (Samples) è impostato al 20% per controllare i costi.
Utilizzare run-from-package con i pacchetti archiviati in un container Blob versionato. Eseguire il deploy tramite CI con az functionapp deployment e fare lo swap da uno slot di staging a quello di produzione per rilasci a zero downtime. Contrassegnare le stringhe di connessione e gli endpoint API come impostazioni di slot (slot settings) per evitare la fuga di informazioni tra ambienti.

Monitorare e gestire

Abilitare Application Insights e Live Metrics per monitorare il throughput e la latenza durante i rilasci. Configurare alert su errori HTTP 5xx, sulla percentuale di fallimento delle dipendenze verso l’API di pricing e sugli aumenti delle orchestrazioni fallite delle Durable Function.
Utilizzare il tracciamento distribuito per correlare la richiesta HTTP con l’orchestrazione Durable e le dipendenze delle attività, accelerando l’analisi della causa radice (root-cause analysis) per problemi intermittenti con le terze parti.

Perché queste scelte:

Il piano Premium con istanze pre-riscaldate garantisce una latenza costantemente bassa e supporta l’integrazione VNET per un’uscita sicura (secure egress).
Le Durable Functions forniscono un concatenamento affidabile e funzionalità di fan-out/fan-in con gestione automatica dello stato e dei retry per le chiamate API esterne.
I binding riducono il codice boilerplate e impongono un accesso ai dati dichiarativo e coerente per Cosmos DB.
Run-from-package e gli slot consentono deployment ripetibili e atomici senza problemi di blocco dei file o downtime.
Application Insights offre osservabilità in tempo reale, correlazione e alerting in linea con gli SLA operativi.

← Azure App Service e App Web · Tutti i domini · Azure Storage e Blob Storage →

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