Microsoft AZ-104: Database di Azure e Servizi dati — 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

I servizi di database e dati di Azure comprendono motori relazionali gestiti, NoSQL distribuiti a livello globale, caching in memoria, analytics su larga scala e integrazione/orchestrazione. In qualità di amministratore, è necessario comprendere i modelli di acquisto, i livelli di servizio, la topologia di rete e di sicurezza, la semantica di backup/DR e come combinare i servizi per ottenere prestazioni, costi e resilienza ottimali. Questa sezione si concentra sulle scelte operative e sulle funzionalità della piattaforma che si configurano quotidianamente: modelli di provisioning (DTU vs vCore), pool elastici, backup e conservazione a lungo termine, replica geografica e failover, istanze gestite con integrazione VNet, distribuzione e coerenza di Cosmos DB, repliche di lettura/HA per database relazionali open-source, motori Synapse e runtime di Data Factory.

Database relazionali di Azure (SQL Database, Managed Instance, MySQL/PostgreSQL)

Azure SQL Database offre due modelli di acquisto. Il modello DTU raggruppa CPU, memoria e IOPS in Database Transaction Unit con i livelli Basic, Standard e Premium; è semplice ma poco trasparente, adatto a carichi di lavoro stabili e prevedibili e al dimensionamento di sistemi legacy. Il modello vCore espone la generazione/numero di CPU e la memoria, abbinati a controlli per lo storage e gli IOPS. vCore permette trasparenza nel dimensionamento, l’utilizzo di Azure Hybrid Benefit e sconti per la capacità riservata (Reserved Capacity). All’interno del modello vCore, i livelli di servizio corrispondono a specifici modelli di carico di lavoro e disponibilità: General Purpose utilizza storage SSD Premium remoto o Azure Premium con un’architettura di disponibilità standard; Business Critical colloca calcolo e storage su SSD locali con repliche multiple, bassa latenza e scalabilità orizzontale in lettura integrata; Hyperscale disaccoppia calcolo e storage con “page server” per una scalabilità quasi istantanea e database di dimensioni molto grandi. Per i database singoli, il livello di calcolo serverless (vCore) scala elasticamente la CPU e può attivare la sospensione automatica per ridurre i costi di inattività.

I pool elastici condividono le risorse di calcolo tra più database per assorbire carichi di lavoro con picchi (bursty) e sfasati, a un costo aggregato inferiore. I pool sono disponibili nelle varianti DTU (eDTU) e vCore. Si impostano limiti minimi/massimi per database per contenere i “noisy neighbor” e un limite massimo per il pool per controllare la spesa. La sovrascrizione (oversubscription) è accettabile quando i picchi sono brevi e non correlati. Il dimensionamento del pool si basa sul consumo medio sommato più un margine per la concorrenza; il monitoraggio delle metriche per database e per pool è fondamentale per mantenere gli SLO.

I backup sono automatici. Azure SQL mantiene backup completi, differenziali e dei log delle transazioni con ripristino point-in-time (PITR) a qualsiasi secondo entro il periodo di conservazione (tipicamente 7–35 giorni a seconda del livello e della configurazione dello storage). La conservazione a lungo termine (LTR) mantiene i backup completi settimanali per anni in uno storage RA-GRS; è possibile ripristinare un backup LTR come nuovo database su qualsiasi server nella stessa sottoscrizione e set di aree geografiche, e il ripristino tra aree geografiche è disponibile se è abilitato lo storage di backup con ridondanza geografica. I ripristini creano un nuovo database; non sovrascrivono quello esistente.

Le opzioni di replica geografica includono la replica geografica attiva per database singoli e pool (fino a quattro database secondari leggibili con replica asincrona) e i gruppi di failover automatico a livello del server logico. I gruppi di failover raggruppano più database (o un intero server) con DR geografico, un endpoint listener di lettura/scrittura, un endpoint di sola lettura per scaricare le letture, failover automatico basato sullo stato di integrità e reindirizzamento basato su DNS. Il livello Business Critical fornisce anche la scalabilità orizzontale in lettura tramite una replica locale leggibile, consentendo di scaricare immediatamente il carico di lavoro di lettura senza la complessità legata all’uso di più aree geografiche.

Azure SQL Managed Instance (MI) offre una compatibilità quasi al 100% con il motore di SQL Server, includendo SQL Agent, query tra database, CLR, linked server, Service Broker e backup/ripristino nativo di file .bak da Azure Blob Storage. MI è integrata in una VNet (VNet-injected): viene distribuita in una subnet dedicata e delegata con IP privati e controlli tramite NSG/UDR; è necessario pianificare in anticipo le dimensioni della subnet e lo spazio di indirizzamento, poiché il ridimensionamento successivo delle subnet è complesso. I percorsi di migrazione includono Azure Database Migration Service (con passaggi, o cutover, online/offline), backup/ripristino nativo su URL in MI e la replica transazionale da SQL Server on-premise a MI. Scegliere MI quando si richiede una parità di funzionalità esposte o feature a livello di istanza che i database singoli non offrono.

Azure Database for MySQL e Azure Database for PostgreSQL (Flexible Server) forniscono motori OSS gestiti con controllo sulle finestre di manutenzione, funzionalità di arresto/avvio per risparmiare sui costi, risorse di calcolo di tipo burstable e per uso generico, crescita automatica dello storage e integrazione VNet. Flexible Server offre alta disponibilità con replica sincrona; è possibile scegliere un’HA con ridondanza di zona (zone-redundant) tra diverse Zone di disponibilità per un isolamento dai guasti più robusto, oppure un’HA nella stessa zona per una latenza di scrittura inferiore. Le repliche di lettura sono disponibili per operazioni di lettura in modalità scale-out e possono essere provisionate all’interno della stessa area geografica o tra aree diverse; utilizzano la replica asincrona e sono ideali per analytics, reporting o microservizi con carichi di lettura intensi. È possibile promuovere una replica per eseguire un failover o per un’espansione a livello di area geografica, tenendo conto del potenziale ritardo di replica.

Dati Distribuiti e Caching (Cosmos DB e Azure Cache for Redis)

Azure Cosmos DB è un database multi-modello distribuito a livello globale che offre API per Core (SQL), MongoDB, Cassandra, Gremlin (grafo) e Table. La scelta dell’API determina la compatibilità dei driver client e la semantica del modello di dati; a livello operativo, si gestisce il throughput (RU provisionate o autoscale) e le partizioni, indipendentemente dall’API. I dati sono partizionati orizzontalmente tramite una chiave di partizione che deve presentare alta cardinalità e una distribuzione uniforme degli accessi per evitare partizioni “hot” (hot partition); evitare chiavi a incremento monotono e considerare chiavi di partizione gerarchiche in presenza di pattern di accesso composti. Le query cross-partizione sono supportate ma consumano più RU; quando possibile, co-locare i dati correlati tramite la chiave di partizione.

I livelli di coerenza sono regolabili per account, database o richiesta: Strong (Forte) garantisce la linearizzabilità; Bounded Staleness (Obsolescenza Limitata) limita l’obsolescenza per tempo o versione; Session (Sessione), l’impostazione predefinita, fornisce letture delle proprie scritture (read-your-writes) per una sessione; Consistent Prefix (Prefisso Coerente) garantisce l’ordine senza una coerenza completa; Eventual (Finale) massimizza la disponibilità e le prestazioni. Per le scritture multi-regione, scegliere una policy di risoluzione dei conflitti appropriata (LastWriterWins o personalizzata tramite stored procedure) e definire le priorità di failover. La distribuzione globale permette di aggiungere regioni con un clic; il servizio gestisce la replica, il failover e il routing ottimizzato per la latenza con SLA su throughput, latenza, disponibilità e coerenza.

Azure Cache for Redis offre una latenza inferiore al millisecondo, basata su Redis. I livelli (tier) progrediscono in termini di funzionalità: Basic (nodo singolo, per sviluppo/test), Standard (coppia di nodi replicati primario/replica con SLA), Premium (dimensioni maggiori, clustering, persistenza, VNet injection, geo-replica e moduli Redis come Bloom), Enterprise ed Enterprise Flash (basati su Redis Enterprise con clustering avanzato, geo-replica attiva per scritture multi-primario e cache più grandi supportate da Flash). Le policy di rimozione (eviction) definiscono il comportamento in caso di pressione sulla memoria: noeviction (errori in scrittura), allkeys-lru/lfu/random (considera tutte le chiavi) e volatile-lru/lfu/ttl/random (considera solo le chiavi con TTL). Per il caching delle sessioni, utilizzare il livello Premium o superiore per la persistenza se non ci si può permettere la perdita di sessioni, abilitare i TTL sulle chiavi per limitarne la crescita e considerare il clustering per il throughput e la scalabilità. Posizionare la cache nella stessa regione e virtual network dei server applicativi per minimizzare la latenza; utilizzare Managed Identity o chiavi di accesso e imporre l’isolamento di rete tramite Private Link o VNet injection.

Analisi e Integrazione (Synapse Analytics e Data Factory)

Azure Synapse Analytics unifica data warehousing, big data e integrazione dei dati. Il pool SQL dedicato (in precedenza SQL DW) è un motore MPP con distribuzioni hash/round-robin, tabelle replicate e caching dei set di risultati. È possibile scalare il calcolo (scale up/down) per rispettare le finestre SLA e metterlo in pausa per pagare solo lo storage. L’isolamento dei carichi di lavoro (workload) può essere ottenuto con i gruppi di carico di lavoro e le impostazioni di importanza per proteggere le query critiche. Il pool SQL serverless fornisce T-SQL on-demand sui dati in Azure Data Lake Storage Gen2 senza provisioning; si paga per TB scansionato e si possono esternalizzare gli schemi usando viste per i livelli semantici. I pool Spark portano Apache Spark in Synapse con autoscale e cluster on-demand, abilitando notebook, Delta Lake e machine learning con sicurezza e data lineage integrati; è possibile condividere i dati del lakehouse tra i motori Spark e SQL.

Azure Data Factory (ADF) orchestra lo spostamento e la trasformazione dei dati. Le pipeline coordinano attività come Copy, Data Flow (flussi di mapping basati su Spark) e calcolo esterno (Databricks, Synapse, Functions). I Dataset definiscono la forma e la posizione dei dati, mentre i Linked Service incapsulano i dettagli di connessione (autenticazione, endpoint) a origini e destinazioni. Gli Integration Runtime (IR) forniscono il piano di calcolo e di rete: Azure IR per lo spostamento e la trasformazione cloud-native, Self-hosted IR per origini on-premise o in reti private tramite HTTPS in uscita, e Azure-SSIS IR per il lift-and-shift di pacchetti SSIS. I Trigger (a pianificazione, a finestra temporale scorrevole, basati su eventi) consentono un’orchestrazione ripetibile; è possibile abilitare la rete virtuale gestita e gli endpoint privati per la protezione dall’esfiltrazione dei dati e per una connettività conforme. La parametrizzazione e l’integrazione con Key Vault supportano pattern riutilizzabili e sicuri per la promozione tra ambienti (sviluppo/test/produzione).

Continuità operativa, funzionalità geografiche e pool elastici

Le strategie di backup e ripristino variano a seconda del servizio ma condividono temi chiave: automatizzare, testare regolarmente i ripristini e separare il PITR (errori operativi) dal LTR (compliance). In Azure SQL, utilizzare il PITR per eliminazioni accidentali o distribuzioni errate; archiviare i backup completi settimanali LTR in RA-GRS per la conservazione normativa e i ripristini di disaster recovery tra aree geografiche. Per MySQL/PostgreSQL Flexible Server, abilitare i backup automatici con archiviazione con ridondanza geografica dove supportato, impostare la conservazione secondo i criteri e convalidare i ripristini point-in-time su server alternativi. Gli account Cosmos DB con più aree geografiche abilitano il failover automatico; combinarli con scritture multi-regione quando l’RPO deve essere zero e l’applicazione può risolvere i conflitti in modo deterministico.

La replica geografica e i gruppi di failover automatico in Azure SQL forniscono DR e offload di lettura. Utilizzare la replica geografica attiva per un singolo database/pool quando si desidera gestire esplicitamente i secondari; utilizzare i gruppi di failover automatico per raggruppare molti database e ottenere listener basati su DNS oltre al failover automatico. Laddove le letture a bassa latenza sono importanti ma il DR non è l’obiettivo, utilizzare lo scale-out di lettura di Business Critical o le repliche denominate di Hyperscale per tenere le analisi e il reporting lontani dal primario. Monitorare il ritardo di replica e i segnali sullo stato del failover, ed eseguire test di failover per convalidare RTO/RPO.

I pool elastici sono leve di ottimizzazione dei costi per SaaS multi-tenant e flotte di piccoli database. Nei pool basati su DTU, allocare eDTU con limiti per database; nei pool vCore, allocare vCore, memoria e throughput di I/O con un numero massimo di vCore per database e governance dell’I/O. Dimensionare correttamente misurando l’utilizzo al 95° percentile per database e allineando la capacità del pool ai modelli di concorrenza; aumentare i limiti per database per i tenant con SLO più elevati e considerare la suddivisione dei pool per classe di carico di lavoro (ad es., tenant pesanti vs leggeri). Utilizzare avvisi sui limiti del pool e per database per rilevare la saturazione in anticipo. Quando una manciata di database raggiunge costantemente i limiti massimi, spostarli su risorse di calcolo dedicate o su un pool separato per mantenere la prevedibilità.

Scenario pratico del problema

Starbucks deve modernizzare la sua piattaforma di fidelizzazione globale per gestire il traffico di picco durante le promozioni, ridurre il carico operativo e supportare l’analisi senza interrompere le operazioni dei negozi in tutto il mondo.

Partizionare l’archivio dati operativo:

Scegliere Azure Cosmos DB (Core SQL API) per le interazioni con i clienti e gli eventi relativi ai premi per ottenere una distribuzione globale con bassa latenza. Configurare scritture multi-regione nelle aree geografiche vicine alle principali popolazioni di clienti e impostare la coerenza di Sessione per bilanciare la lettura delle proprie scritture (read-your-writes) con le prestazioni. Selezionare una chiave di partizione ad alta cardinalità come customerId o una chiave gerarchica composita (customerId, eventMonth) per distribuire il throughput e supportare i modelli di query comuni.

Implementare dati transazionali per account e catalogo:

Distribuire Azure SQL Managed Instance per i saldi dei conti, i riscatti di premi e gli SKU/catalogo perché è necessaria una compatibilità quasi del 100% con SQL Server per le stored procedure esistenti e la logica cross-database. Posizionare l’MI in una subnet dedicata e delegata con NSG e tabelle di routing come richiesto dall’iniezione in VNet, abilitando l’accesso privato dalle subnet delle applicazioni e da ExpressRoute.

Fornire scalabilità di lettura globale e DR per i carichi di lavoro relazionali:

Per i nuovi microservizi che utilizzano Azure SQL Database, usare vCore Business Critical per bassa latenza e scale-out di lettura. Creare un gruppo di failover automatico verso una regione abbinata con endpoint listener di sola lettura per letture localizzate e failover automatico per raggiungere gli obiettivi di DR.

Aggiungere la gestione delle sessioni a bassa latenza:

Distribuire Azure Cache for Redis Premium con clustering e persistenza dei dati per i token di sessione web e mobile. Impostare una politica di eviction allkeys-lfu per mantenere residenti le sessioni ad accesso frequente. Integrare la cache nella stessa VNet e regione del livello applicativo per minimizzare la latenza.

Orchestrare lo spostamento dei dati e costruire l’analisi:

Utilizzare Azure Data Factory per copiare i dati operativi (change feed di Cosmos DB e SQL MI) in Azure Data Lake Storage Gen2. Impiegare un IR VNet gestito con endpoint privati per prevenire l’esfiltrazione dei dati. Parametrizzare le pipeline e utilizzare trigger a finestra temporale variabile (tumbling window) per garantire un’elaborazione ordinata.

Abilitare l’analisi aziendale con controllo elastico dei costi:

In Azure Synapse Analytics, utilizzare il pool SQL serverless per l’esplorazione ad hoc sui dati parquet e un pool SQL dedicato per modelli BI curati e ad alta concorrenza con prestazioni prevedibili. Creare pool Spark per il feature engineering sul comportamento di fidelizzazione e scrivere tabelle Delta nel lake per l’interoperabilità tra Spark e SQL.

Governance, backup e conservazione:

Configurare le priorità di failover automatico di Cosmos DB e monitorare i conflitti utilizzando LastWriterWins con un campo timestamp. Per Azure SQL Database e MI, verificare le finestre PITR e abilitare LTR per soddisfare la conservazione ai fini di compliance. Per le istanze di Flexible Server che supportano servizi OSS ausiliari (ad es., telemetria dei negozi regionali in PostgreSQL), abilitare l’HA con ridondanza di zona e configurare repliche di lettura per il reporting.

Perché questi servizi: La distribuzione globale e la coerenza regolabile di Cosmos DB rispondono alle interazioni sensibili alla latenza in tutto il mondo; MI preserva le complesse funzionalità di SQL Server fornendo al contempo operazioni gestite; i database Business Critical forniscono scalabilità di lettura locale senza la latenza tra aree geografiche; Redis garantisce un accesso alle sessioni nell’ordine dei sottomillisecondi durante i picchi di traffico; ADF fornisce uno spostamento sicuro e governato da reti private; Synapse mescola analisi on-demand e provisioned per insight scalabili e convenienti. Questa composizione soddisfa gli SLO di performance durante le promozioni, riduce il lavoro di amministrazione attraverso PaaS gestito e impone chiari confini di RTO/RPO e compliance.

← Azure App Service e Compute PaaS · Tutti i domini · Azure Monitor →

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