Microsoft AZ-204: Azure API Management — 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 API Management (APIM) fornisce una facciata unificata su diversi servizi di backend, combinando un gateway ad alte prestazioni con un motore di criteri configurabile, l’onboarding degli sviluppatori e un piano di gestione completo. Consente di applicare in modo coerente controlli di sicurezza, throttling, trasformazione, osservabilità e ciclo di vita su backend REST, SOAP e GraphQL. APIM è sia un gateway di runtime per il traffico sia un sistema guidato dalla configurazione che si gestisce tramite il portale di Azure, ARM/Bicep/CLI o CI/CD. Comprendere la pipeline delle richieste, le funzionalità dei criteri, il controllo delle versioni/revisioni, il modello di sottoscrizione e le caratteristiche dei livelli è fondamentale per creare API robuste e sicure su larga scala.

Architettura, Livelli e Componenti Principali

Il gateway è il piano dati. Termina le connessioni dei client, applica i criteri in un ordine deterministico, instrada le richieste ai backend e restituisce le risposte. Supporta il caching integrato, la convalida di JWT, il Mutual TLS e la trasformazione dei contenuti a velocità di linea. I gateway possono essere ospitati da Microsoft per regione o self-hosted (containerizzati) per essere eseguiti più vicino ai carichi di lavoro on-premise o edge, pur rimanendo gestiti centralmente. Il gateway espone la traccia e le metriche e si integra con Application Insights per la telemetria distribuita.

Il portale per sviluppatori è l’esperienza rivolta al consumatore per l’individuazione, la documentazione e la gestione delle sottoscrizioni. Esegue il rendering della documentazione OpenAPI/GraphQL, fornisce console interattive “try it”, gestisce i flussi OAuth 2.0 nel browser e supporta branding personalizzato e provider di identità. Qui gli sviluppatori gestiscono autonomamente le sottoscrizioni ai prodotti e la rotazione delle chiavi.

Il piano di gestione è la superficie di configurazione e governance. Memorizza API, operazioni, criteri, prodotti, utenti/gruppi, backend, certificati e diagnostica. È accessibile tramite il portale di Azure, ARM/Bicep/CLI/PowerShell, l’API REST di gestione e la sincronizzazione della configurazione basata su Git. Questo piano orchestra le distribuzioni, il controllo delle versioni, le revisioni e l’RBAC.

I livelli di APIM determinano la scalabilità, le funzionalità e le capacità di rete:

Consumption è serverless e fatturato per chiamata. Si adatta automaticamente, è ideale per scenari con picchi di traffico o a basso throughput e supporta la maggior parte dei criteri principali. Non include il caching delle risposte integrato e manca di funzionalità di rete avanzate e multi-regione.
Developer è per ambienti non di produzione. Offre quasi tutte le funzionalità senza SLA e senza il throughput su scala di produzione.
Basic e Standard sono livelli di produzione dedicati e a singola regione con throughput prevedibile, unità di scalabilità orizzontale e caching delle risposte integrato. Sono adatti a molti carichi di lavoro aziendali che non richiedono funzionalità multi-regione o di rete avanzate.
Premium aggiunge la distribuzione multi-regione, funzionalità di rete avanzate (inclusa l’integrazione VNet), una scalabilità superiore, le zone di disponibilità nelle regioni supportate e la licenza per i gateway self-hosted. Scegliere Premium per distribuzioni globali, mission-critical e networking privato.

Criteri e Pipeline delle Richieste

I criteri (policy) di APIM sono dichiarazioni che vengono eseguite in un ordine rigoroso attraverso quattro sezioni: in ingresso (inbound), backend, in uscita (outbound) e in caso di errore (on-error).

I criteri in ingresso (inbound) vengono eseguiti prima che la richiesta sia inoltrata al backend. I compiti tipici includono richiedere o convalidare le chiavi di sottoscrizione, convalidare i JWT (imponendo issuer, audience, firma), controllare gli IP dei client, applicare limiti di velocità e quote, normalizzare gli header, riscrivere gli URI e trasformare il payload. È possibile instradare condizionalmente a backend diversi e impostare variabili per le fasi successive.

La sezione backend configura e modifica la chiamata al servizio a monte. Utilizzala per selezionare un’entità di backend, allegare le credenziali del client (autenticazione Basic, certificati client o token acquisiti tramite identità gestita per i backend protetti da Azure AD), impostare timeout, abilitare i tentativi e applicare il circuit breaking. Il TLS reciproco (Mutual TLS) verso il backend viene configurato qui, associando un certificato client che il gateway presenterà.

I criteri in uscita (outbound) vengono eseguiti dopo aver ricevuto la risposta dal backend. Comunemente eseguono trasformazioni della risposta (ad es. da JSON a XML o viceversa), riscrittura degli header, modellazione dei dati, mascheramento dei dettagli interni e caching della risposta. Questo è anche il punto in cui applicare conversioni di negoziazione del contenuto o normalizzare i codici di stato.

I criteri in caso di errore (on-error) vengono eseguiti se si verifica un’eccezione in una qualsiasi delle sezioni precedenti, inclusa la chiamata al backend. Utilizza questa sezione per mappare gli errori del backend su formati di errore API standardizzati, impostare codici di stato appropriati, redigere i messaggi sensibili, aggiungere ID di correlazione o fornire risposte di fallback.

Pattern di criteri comuni:

Il rate limiting (limitazione della velocità) controlla i picchi di throughput e protegge i backend. rate-limit-by-key applica un throttling per identità utilizzando una chiave come la chiave di sottoscrizione, un claim JWT o l’IP. Per finestre temporali più lunghe, si combina con quota-by-key per limitare l’utilizzo giornaliero o mensile.
Il filtraggio IP (IP filtering) blocca o consente il traffico in base all’IP del client o a intervalli CIDR utilizzando ip-filter, spesso posizionato all’inizio della sezione inbound per minimizzare costi ed esposizione.
La convalida JWT con validate-jwt impone i parametri di OpenID Connect. Configurare l’URL di configurazione OpenID o l’issuer, definire le audience/gli scope accettati, selezionare i claim richiesti e regolare il disallineamento dell’orologio (clock skew) e i controlli sulla durata del token. Negare l’accesso anonimo richiedendo un token valido per tutte le operazioni in cui le chiamate anonime non sono consentite.
La trasformazione include rewrite-uri, set-header, set-query-parameter, set-body e find-and-replace. Usare xml-to-json o json-to-xml per colmare le discrepanze di formato tra client e backend senza modificare il codice.
Il caching sfrutta cache-lookup e cache-store per memorizzare nella cache intere risposte basandosi su chiavi che possono includere percorso, query, header e claim JWT. Usare cache-lookup-value/cache-store-value per il caching chiave/valore all’interno dei criteri, come ad esempio per memorizzare i token nella cache. Si noti che il caching delle risposte integrato non è disponibile nel livello Consumption.

Sicurezza, identità e sottoscrizioni

È necessario gestire sia la sicurezza front-end dal client al gateway, sia la sicurezza back-end dal gateway al servizio.

Per la sicurezza front-end, il modello dominante è OAuth 2.0 con Azure AD. I client acquisiscono i token da Azure AD e li presentano al gateway. APIM applica i requisiti dei token utilizzando validate-jwt che fa riferimento ai metadati OpenID Connect di Azure AD (l’endpoint well-known del tenant). Le policy possono imporre controlli sull’audience (audience check) per garantire che il token sia destinato all’API corretta, sui claim di scope per assicurare che i chiamanti abbiano le autorizzazioni appropriate, e su claim opzionali come i ruoli dell’applicazione (app roles). Per eliminare le chiamate anonime, validate-jwt dovrebbe essere applicato a tutte le operazioni. Il portale per sviluppatori può essere configurato con Azure AD per semplificare l’acquisizione dei token durante i test.

Per i certificati client e il mutual TLS (mTLS), APIM può richiedere certificati client in ingresso dai chiamanti, convalidando emittente (issuer), soggetto (subject) e scadenza, e opzionalmente lo stato CRL/OCSP tramite validate-client-certificate. Questa soluzione è adatta per integrazioni B2B e ad alta affidabilità (high-assurance). Per l’mTLS tra gateway e backend, si carica un certificato client su APIM, lo si associa a un’entità di backend o a set-backend-service, e APIM lo presenterà durante l’handshake TLS per autenticarsi presso il backend. Questo approccio è spesso richiesto da App Service protetti o da servizi personalizzati che impongono l’autenticazione tramite certificato.

Per i backend protetti da Azure AD, si utilizza authentication-managed-identity nella sezione di backend per acquisire un token di accesso con l’identità gestita (managed identity) di APIM, assegnata dal sistema o dall’utente. La policy inserisce l’header Authorization per la chiamata al backend. Ciò evita di archiviare segreti e soddisfa i moderni requisiti zero-trust.

Le sottoscrizioni (subscriptions) forniscono un modello di accesso e monetizzazione a grana grossa (coarse-grained). I prodotti (products) sono insiemi di API regolati da termini, approvazione e limiti di utilizzo. Gli sviluppatori sottoscrivono i prodotti per ottenere le chiavi di sottoscrizione (primaria e secondaria) utilizzate tramite l’header Ocp-Apim-Subscription-Key o un parametro di query. Le chiavi possono essere ruotate senza tempi di inattività (downtime) grazie alla doppia chiave. L’ambito (scope) della sottoscrizione determina dove si applicano le chiavi: a tutte le API, a una singola API o a un prodotto specifico. L’accesso basato sulla sottoscrizione è complementare a OAuth 2.0; possono essere richiesti entrambi, consentendo di avere throttling e contabilità separati mentre l’autenticazione si basa sui token. I prodotti possono imporre quote e limiti di velocità (rate limit) per sottoscrizione, indipendentemente dalle policy per operazione, fornendo così protezione e governance a più livelli (layered).

Backend, Resilienza, Versioning e Revisioni

I backend in APIM sono entità riutilizzabili di prima classe che incapsulano l’URL di base, il protocollo, le credenziali, le impostazioni TLS, i template degli header e la configurazione del proxy di un servizio di destinazione. Associare API e operazioni ai backend disaccoppia il routing dalle policy e centralizza i dettagli di connessione. Utilizzare set-backend-service tramite l’ID del backend nelle policy per instradare le richieste senza codificare gli URL in modo statico, semplificando la promozione tra gli ambienti di dev, test e prod.

La resilienza è garantita tramite tentativi (retry) e circuit breaking. I tentativi con backoff esponenziale possono mitigare errori transitori; dovrebbero essere limitati a operazioni idempotenti e circoscritti da timeout ragionevoli per prevenire l’amplificazione. Una policy di circuit breaker si apre quando il tasso di errore, gli errori consecutivi o la latenza superano le soglie configurate all’interno di una finestra di campionamento, cortocircuitando le richieste per una durata di interruzione definita. Durante lo stato aperto, la policy può restituire immediatamente una risposta di fallback o instradare a un backend di standby. Nello stato semi-aperto, un numero limitato di richieste di prova sonda lo stato del backend prima di chiudere il circuito. Questo protegge i backend, migliora l’esperienza del client e stabilizza i sistemi in caso di guasto parziale.

Il bilanciamento del carico e il routing possono essere implementati a livello di policy. Il routing condizionale con choose può dirigere il traffico per segmento di utenza, area geografica, contenuto della richiesta o segnali di stato (health). Il routing ponderato può essere ottenuto tramite espressioni di policy che selezionano in modo pseudo-casuale un backend in base ai pesi desiderati, abilitando canary release e implementazioni graduali. I backend active-active distribuiti tra più regioni possono essere gestiti con un deployment multi-regionale di APIM di livello Premium, combinato con un routing condizionale verso la regione integra più vicina; in alternativa, è possibile integrare Azure Front Door per il bilanciamento del carico globale di livello 7, mentre APIM gestisce l’autenticazione e la trasformazione.

Il versioning e le revisioni governano il ciclo di vita delle API. I set di versioni (version set) definiscono come più versioni di un’API vengono esposte ai client utilizzando uno schema di versioning basato su percorso (path), stringa di query o header. Utilizzare le versioni per i breaking change; ogni versione è un’entità API separata associata allo stesso set di versioni. Le modifiche iterative che non introducono incompatibilità (non-breaking) vengono implementate come revisioni. Una revisione è uno snapshot modificabile di un’API che può essere invocato esplicitamente (tramite il suffisso della revisione) per i test, mentre una revisione precedente rimane quella di produzione corrente. Dopo la convalida, si promuove la nuova revisione a corrente senza modificare l’identificatore di versione. Questa separazione consente un rilascio progressivo e sicuro: revisioni per aggiornamenti non-breaking; versioni per breaking change, esposte tramite discovery e documentazione chiare nel portale per sviluppatori.

Infine, osservare e governare. Abilitare il tracciamento, impostare ID di correlazione ed esportare i dati diagnostici in Application Insights per una visibilità end-to-end. Gestire la configurazione tramite ARM/Bicep o l’APIM DevOps Resource Kit per ottenere deployment ripetibili e applicare RBAC sul piano di gestione per separare le responsabilità tra autori, publisher e operatori delle API.

Scenario Pratico

Starbucks deve esporre un’API pubblica unificata per le ordinazioni da mobile che aggrega microservizi distribuiti in due regioni Azure. L’API deve bloccare l’accesso anonimo, limitare (throttling) i client abusivi, proteggere i backend regionali da fallimenti a cascata e consentire un’implementazione graduale di uno schema v2 per gli ordini senza interrompere il funzionamento dei client v1.

Creare un’istanza APIM Premium in due regioni e abilitare il deployment multi-regionale. Il livello Premium viene scelto per la presenza di gateway in più regioni, le funzionalità di rete avanzate e la scalabilità di livello enterprise. I gateway regionali riducono la latenza per i client mobili e forniscono resilienza active-active.
Importare i servizi di backend come entità backend di APIM, includendo le istanze di App Service in entrambe le regioni. Le entità backend centralizzano gli URL di base, le impostazioni TLS e le credenziali, consentendo policy di routing pulite e portabilità tra ambienti.
Proteggere la comunicazione client-gateway con Azure AD OAuth 2.0 e imporre la validazione dei token utilizzando validate-jwt nella sezione inbound. Azure AD fornisce identità centralizzata, accesso condizionale e una solida validazione dei token. validate-jwt garantisce che solo i chiamanti autenticati con audience/scope corretti possano invocare l’API.
Richiedere sottoscrizioni ai prodotti ed emettere chiavi di sottoscrizione per ogni applicazione partner. Questo aggiunge un livello di governance e misurazione indipendente da OAuth e consente quote per partner, una facile rotazione delle chiavi e un onboarding self-service basato sul portale.
Configurare rate-limit-by-key e quota-by-key nella sezione inbound, utilizzando la chiave di sottoscrizione come discriminatore. Il throttling protegge i backend dai picchi di traffico e consente SLA differenziati per i partner. L’uso delle chiavi di sottoscrizione come discriminatore allinea l’applicazione delle regole con i contratti commerciali.
Implementare il filtraggio IP per bloccare intervalli IP malevoli noti e consentire gli intervalli aziendali di proprietà di Starbucks per l’amministrazione. La policy ip-filter riduce la superficie di attacco nelle prime fasi della pipeline e risparmia risorse a valle.
Configurare il TLS reciproco (mTLS) con il backend per i servizi