Microsoft AZ-305: Archiviazione dei dati e soluzioni di database — Guida allo studio

By Laurynas Brazys · 11 August 2026 · #microsoft #az-305 #certification #exam-prep #study-guide

Fa parte della Microsoft Azure Solutions Architect Expert AZ-305 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Panoramica

La progettazione dell’archiviazione dati su Azure richiede di bilanciare coerenza, latenza, disponibilità, complessità operativa e costi tra molteplici opzioni di database e storage. La piattaforma spazia da database relazionali completamente gestiti, NoSQL distribuiti a livello globale, object storage con governance del ciclo di vita dei dati, data lake analitici ad alta velocità di trasmissione e cache in-memory. La vostra architettura dovrebbe partire dalle caratteristiche del carico di lavoro — transazionale o analitico, portata globale o locale, rigidità dello schema, pattern di lettura/scrittura, dimensioni e velocità — e selezionare il servizio e la configurazione che corrispondono a tali vincoli, soddisfacendo al contempo i requisiti di sicurezza, resilienza e governance.

Servizi di Dati Relazionali su Azure

Azure SQL Database offre due modelli di acquisto. Il modello DTU combina CPU, memoria e I/O in un’unità mista attraverso i livelli Basic, Standard e Premium; è semplice ma opaco per la pianificazione della capacità. Il modello vCore separa calcolo, memoria e archiviazione, con scelte hardware, scalabilità prevedibile e leve di costo come Azure Hybrid Benefit e la capacità riservata. Nel modello vCore, i principali livelli di servizio sono General Purpose (calcolo disaccoppiato e archiviazione remota, costo bilanciato), Business Critical (SSD locale con repliche Always On per I/O a bassa latenza e failover rapido) e Hyperscale (architettura log-structured con page server e archiviazione distribuita per scalabilità multi-terabyte e operazioni veloci basate su snapshot). La modalità Serverless per il livello General Purpose scala automaticamente il calcolo tra un minimo e un massimo configurati e può mettersi in pausa automaticamente quando è inattivo; si paga al secondo di calcolo e per l’archiviazione. Questo è particolarmente adatto per carichi di lavoro intermittenti o di sviluppo, ma comporta un avvio a freddo (cold-start) e il riscaldamento della cache alla ripresa.

I pool elastici (Elastic pools) consentono a più database di condividere un budget di calcolo e un margine di I/O, appianando i picchi e riducendo i costi per molti database piccoli con carico variabile. I pool esistono sia nel modello DTU che in quello vCore; il corretto dimensionamento richiede la comprensione della concorrenza aggregata e dei limiti di burst per singolo database per evitare effetti di “vicino rumoroso” (noisy-neighbor).

I pattern di resilienza di Azure SQL includono la replica geografica attiva (active geo-replication) e i gruppi di failover automatico (auto-failover groups). La replica geografica attiva mantiene in modo asincrono fino a quattro database secondari leggibili in qualsiasi regione di Azure, con il failover avviato per singolo database. I gruppi di failover automatico gestiscono più database come un’unità su server logici associati, forniscono endpoint listener di lettura/scrittura e di sola lettura, e gestiscono il failover pianificato o non pianificato con periodi di tolleranza configurabili — ideali per SaaS multi-tenant. La ridondanza di zona (Zone redundancy) è disponibile nei livelli Business Critical (e Hyperscale) per estendersi su più Zone di Disponibilità all’interno di una regione, migliorando la tolleranza ai guasti intra-regione.

Azure SQL Managed Instance (MI) mira a una compatibilità quasi del 100% con SQL Server (SQL Agent, query cross-database, Linked Servers, CLR, Service Broker). Viene eseguita all’interno della vostra rete virtuale su una subnet dedicata e delegata (Microsoft.Sql/managedInstances). Le istanze utilizzano solo IP privati; configurate i gruppi di sicurezza di rete (network security groups) e le tabelle di routing per consentire il traffico di gestione verso i piani di controllo di Azure e il traffico dati verso le vostre applicazioni. Integratevi con Azure Private DNS (o DNS personalizzato) in modo che i client risolvano il FQDN privato dell’istanza gestita. Per la connettività ibrida e la migrazione, assicurate la visibilità tramite VPN site-to-site o ExpressRoute. I percorsi di migrazione includono backup/ripristino nativo su Azure Blob Storage (WITH COPY_ONLY, WITH MOVE), migrazioni online o offline utilizzando Azure Database Migration Service (DMS), e la replica transazionale o il log shipping dove appropriato. Il livello Business Critical di MI aggiunge archiviazione a bassa latenza e alta disponibilità; il livello General Purpose offre archiviazione conveniente con dischi remoti.

Azure Database for PostgreSQL e MySQL Flexible Server forniscono un controllo granulare sulle finestre di manutenzione, la possibilità di arrestare/avviare per risparmiare sui costi e l’isolamento di rete tramite l’integrazione VNet. Le opzioni di alta disponibilità includono uno standby sincrono nella stessa zona per il failover più rapido e l’HA con ridondanza di zona per resistere a guasti di zona (replica sincrona con failover automatico). Le repliche di lettura (nella stessa regione e, per molte versioni, tra regioni diverse) scaricano i carichi di lavoro di lettura e supportano analisi quasi in tempo reale; sono asincrone e non adatte per letture strettamente coerenti. Selezionate i livelli di calcolo e archiviazione in base agli obiettivi di IOPS/latenza e pianificate la gestione del failover delle connessioni nelle librerie client.

Store non relazionali e distribuiti a livello globale

Azure Cosmos DB è un database multimodello, distribuito a livello globale e completamente gestito, con replica globale chiavi in mano e letture e scritture con latenza nell’ordine di millisecondi a una cifra al 99° percentile. Scegliere l’API in base all’adattamento all’ecosistema e al modello di dati: API Core (SQL) per documenti e query di tipo SQL con un ricco supporto SDK; API MongoDB per la compatibilità con il wire-protocol di Mongo; API Cassandra per carichi di lavoro a colonne estese (wide-column); API Gremlin per l’attraversamento di grafi; e API Table per scenari chiave/attributo. Il throughput viene fornito in unità di richiesta (RU), utilizzando modalità fisse o di scalabilità automatica (autoscale); progettare le partizioni e l’indicizzazione per minimizzare il consumo di RU.

Il partizionamento è fondamentale. Selezionare una chiave di partizione ad alta cardinalità che distribuisca uniformemente lo storage e il traffico, eviti partizioni “calde” (hot partition) e si allinei ai modelli di accesso (ad esempio, tenantId o userId per scritture multi-tenant, o una chiave composita sintetica per bilanciare le letture). Le partizioni logiche hanno vincoli di dimensione e throughput; modellare i dati in modo da mantenere distribuiti i working set “caldi”. Non è possibile modificare la chiave di partizione di un contenitore dopo la sua creazione; le migrazioni richiedono nuovi contenitori e lo spostamento dei dati.

La coerenza di Cosmos si articola in cinque livelli configurabili: Strong (linearizzabile, RU/latenza più elevati), Bounded Staleness (ritardo prevedibile o finestra di versione), Session (letture incentrate sul client “reads-your-writes”, l’impostazione predefinita più diffusa), Consistent Prefix (nessuna lettura fuori sequenza) ed Eventual (massima disponibilità e prestazioni con potenziali anomalie). Scegliere le impostazioni predefinite per account e sovrascriverle per richiesta quando necessario. Le scritture multi-regione abilitano un vero multi-master per scritture globali a bassa latenza e maggiore disponibilità; gestire la risoluzione dei conflitti tramite Last-Writer-Wins (su una proprietà designata), policy personalizzate o logica applicativa con stored procedure e conflict feed.

Quando si sceglie il data store giusto, abbinare i requisiti alle capacità. Integrità relazionale rigorosa, join complessi e garanzie transazionali favoriscono Azure SQL Database o Managed Instance. Scalabilità globale massiva, schema flessibile e accesso geografico a bassa latenza favoriscono Cosmos DB. I problemi a grafo (social, raccomandazioni, topologia di rete) si mappano sull’API Gremlin di Cosmos DB o sulle funzionalità per grafi di Azure SQL quando la collocazione relazionale è vantaggiosa. Telemetria di serie temporali ad alta ingestione, esplorazione ad hoc e analisi quasi in tempo reale si allineano con Azure Data Explorer. Blob non strutturati, media e payload binari di grandi dimensioni appartengono ad Azure Blob Storage o ADLS Gen2, con i metadati in un database complementare.

Storage a oggetti e analitico

Azure Blob Storage è la base per i dati non strutturati. I livelli di accesso (access tier) allineano i costi di archiviazione ai modelli di accesso: Hot per l’accesso frequente, Cool per l’accesso non frequente con una conservazione minima di 30 giorni, e Archive per l’archiviazione a freddo a lungo termine con una conservazione minima di 180 giorni e tempi di riattivazione (rehydration) di ore. Gli account Premium per block blob su SSD offrono carichi di lavoro a bassa latenza e ad alto numero di transazioni, come le pipeline di ingestione. Le policy di gestione del ciclo di vita (lifecycle management) automatizzano le transizioni e le eliminazioni basate su regole (data dell’ultima modifica, tag di indice del blob o prefissi), riducendo i costi senza intervento manuale.

La replica di oggetti (object replication) per i block blob esegue il mirroring asincrono degli oggetti e delle loro versioni tra account di archiviazione (nella stessa regione o in regioni diverse). Richiede il versioning dei blob (blob versioning) sull’origine e sulla destinazione ed è guidata da policy per ogni coppia di contenitori, supportando la conformità e la distribuzione multi-regione pur mantenendo l’indipendenza dalle scelte di ridondanza a livello di account. L’immutabilità (WORM) è applicabile a livello di contenitore o di blob tramite conservazione basata sul tempo (time-based retention) e blocchi a fini giudiziari (legal hold), con opzioni come allowProtectedAppendWrites per i log di sola aggiunta (append-only). L’immutabilità a livello di versione (version-level immutability) protegge gli stati passati da manomissioni e ransomware.

Azure Data Lake Storage Gen2 aggiunge uno spazio dei nomi gerarchico a Blob storage, fornendo directory reali, rinomine atomiche e operazioni sui file ottimizzate. ACL granulari di tipo POSIX controllano l’accesso a livello di directory e file, con ACL di accesso e predefinite (Access e Default ACL), e vengono valutate insieme ad Azure RBAC. Autenticarsi con Azure AD e OAuth2 per il principio del privilegio minimo (least privilege) e la verificabilità (auditability). L’integrazione con gli strumenti di analisi è nativa: Azure Synapse Analytics e Azure Databricks accedono ad ADLS Gen2 tramite il driver ABFS con un throughput scalabile, mentre servizi come Azure Data Factory, Azure Purview e Azure Machine Learning si integrano per l’orchestrazione, la governance e l’addestramento dei modelli. Progettare strutture di cartelle e l’ereditarietà delle ACL per isolare i domini e supportare la governance multi-team, e sfruttare funzionalità come il change feed e il soft delete per il tracciamento (lineage) e il ripristino.

Caching e accelerazione delle prestazioni

Azure Cache for Redis fornisce accesso ai dati con latenza inferiore al millisecondo, funzionalità pub/sub e blocco distribuito (distributed locking). I livelli (tier) corrispondono a esigenze di disponibilità e scalabilità. Basic è a nodo singolo per dev/test. Standard aggiunge una configurazione a due nodi primario/replica con failover automatico. Premium introduce il clustering su più shard, la persistenza (snapshot RDB e AOF), il supporto VNet e la geo-replica in una topologia attivo-passivo. Enterprise ed Enterprise Flash (Redis Enterprise) aggiungono la geo-replica Attivo-Attivo utilizzando CRDT per scritture multi-regione, footprint di memoria più grandi, prestazioni multi-threaded e supporto per i moduli; Flash aumenta la DRAM con NVMe per cache massive a un costo inferiore. Scegliere la policy di rimozione (eviction policy) in base al TTL delle chiavi e al carico di lavoro: allkeys-lru/allkeys-random quando non tutte le chiavi hanno un TTL; volatile-lru/volatile-ttl quando solo le chiavi in scadenza devono essere rimosse; e noeviction quando i fallimenti di scrittura sono preferibili alla rimozione. La persistenza riduce la perdita di dati in caso di failover al costo di un overhead di I/O e latenza; abilitarla solo quando necessario e regolare gli intervalli degli snapshot.

Integrare Redis come cache di tipo “cache-aside” per i risultati delle query del database, lo stato di sessione e i contatori di rate-limiting. Garantire un popolamento idempotente, applicare TTL appropriati e implementare dei circuit breaker. Per le cache in cluster, partizionare le chiavi (shard key) in modo deterministico; per la modalità Enterprise Attivo-Attivo, testare la semantica di risoluzione dei conflitti.

Pattern di Sicurezza, Accesso e Resilienza

La delega dell’accesso ad Azure Storage utilizza token SAS e criteri. La Service SAS concede un accesso limitato a una risorsa specifica (contenitore, blob, condivisione file, coda o tabella). L’Account SAS si estende a più servizi nell’account ed è molto potente; proteggila con cura. La User delegation SAS (solo per il servizio Blob) deriva da Azure AD e da una chiave di delega utente, abilitando il controllo degli accessi per utente senza le chiavi dell’account: ideale per applicazioni multi-tenant e concessioni di breve durata. I criteri di accesso archiviati (su contenitori, condivisioni, code e tabelle) associano i token SAS a un criterio lato server, in modo da poter revocare o ridurre l’accesso senza dover ruotare le chiavi dell’account; una SAS senza un criterio di accesso archiviato può essere revocata solo facendo scadere il token o ruotando le chiavi.

Per la crittografia, Azure Storage utilizza di default la crittografia lato servizio. Le chiavi gestite dal cliente (CMK) archiviate in Azure Key Vault o Managed HSM forniscono un controllo centralizzato del ciclo di vita delle chiavi e auditabilità. Gli ambiti di crittografia consentono l’uso di diverse CMK all’interno dello stesso account di archiviazione per contenitore o prefisso, supportando la gestione delle chiavi per tenant. Per un controllo lato client per singolo blob, è possibile fornire chiavi fornite dal cliente (CPK) nelle richieste. Combina le CMK a livello di account o di ambito con le CPK secondo necessità per l’isolamento normativo.

La sicurezza e la resilienza di Azure SQL si basano sui livelli di piattaforma e sulle funzionalità di replica già descritte. Utilizza i gruppi di failover automatico per un failover coordinato tra aree e endpoint di listener captive, e abilita la ridondanza di zona dove disponibile per resistere a guasti di zona. Per i dati sensibili, applica il mascheramento dinamico dei dati per offuscare le PII nei risultati delle query per gli utenti non privilegiati, e considera Always Encrypted con enclave sicure per la protezione lato client delle colonne quando agli amministratori deve essere impedito di visualizzare il testo in chiaro. Monitora gli obiettivi RPO/RTO rispetto al comportamento di replica del tuo livello e testa regolarmente il failover.

Quando si pianificano architetture end-to-end, unifica l’identità (Azure AD per SQL, storage e analytics), applica il principio del privilegio minimo con RBAC e ACL, utilizza Private Link o l’integrazione VNet per mantenere i dati fuori dalla rete Internet pubblica e implementa criteri di ciclo di vita, immutabilità e replica per soddisfare gli obiettivi di conservazione e DR.

Scenario Pratico

Contoso Retail sta lanciando una piattaforma di e-commerce globale con traffico diurno volatile, rigidi controlli sulle PII, contenuti multimediali dei prodotti su scala petabyte e personalizzazione quasi in tempo reale. Richiedono letture a bassa latenza in tutto il mondo, tempi di inattività minimi e un’analisi dei dati governata.

Posizionare i database transazionali del catalogo e degli ordini su Azure SQL Database utilizzando il modello vCore:

Selezione del livello: Business Critical per gli ordini (storage a bassa latenza e failover rapido) e General Purpose serverless per il catalogo (picchi di traffico con finestre di inattività).
Perché: vCore fornisce un dimensionamento prevedibile e l’Hybrid Benefit; Business Critical soddisfa i requisiti di latenza/HA per gli ordini; serverless minimizza i costi di calcolo durante i periodi di bassa attività.

Configurare un gruppo di failover automatico tra aree geografiche associate per entrambi i database e abilitare la ridondanza di zona:

Perché: Un listener di lettura/scrittura unificato semplifica il failover dell’applicazione; la ridondanza di zona protegge dai guasti di zona; le repliche tra aree soddisfano i requisiti di DR e offrono scalabilità in lettura per il reporting.

Archiviare immagini e video dei prodotti in Azure Blob Storage (general-purpose v2) con gestione del ciclo di vita e replica di oggetti:

Criterio: Hot per gli elementi attivi, Cool dopo 30 giorni, Archive dopo 180 giorni; replicare in un’area secondaria tramite la replica di oggetti.
Perché: Minimizza i costi di archiviazione nel tempo fornendo al contempo una distribuzione regionale asincrona indipendente dalla ridondanza dell’account; soddisfa i requisiti di conservazione con l’immutabilità per gli asset legali (WORM basato sul tempo).

Creare il servizio dei profili cliente e del carrello su Azure Cosmos DB (Core API) con scritture multiregione e coerenza di Sessione:

Design: Partizionare per userId per distribuire le scritture; abilitare le RU con scalabilità automatica.
Perché: Il multi-master fornisce scritture a bassa latenza per un pubblico globale e alta disponibilità; la coerenza di Sessione garantisce la lettura delle proprie scritture (read-your-writes) per utente con forti garanzie di UX e un uso efficiente delle RU.

Introdurre Azure Cache for Redis Enterprise per lo stato di sessione, il caching dei dettagli dei prodotti e il rate limiting:

Modalità: Clustering con geo-replica Active-Active per scritture multiregione.
Perché: L’accesso sotto il millisecondo e la risoluzione dei conflitti basata su CRDT mantengono sessioni e contatori coerenti tra le aree senza un singolo master di scrittura.

Inserire i log di clickstream e operativi in Azure Data Lake Storage Gen2 con spazi dei nomi gerarchici e ACL POSIX:

Integrazione: L’ingestione tramite stream scrive in cartelle curate; Databricks e Synapse leggono tramite ABFS; abilitare il feed di modifiche e l’eliminazione temporanea.
Perché: Le ACL granulari a livello di directory/file supportano la governance multi-team; lo spazio dei nomi gerarchico ottimizza le operazioni sui file; l’integrazione nativa con gli strumenti di analytics riduce il time-to-insight.

Utilizzare Azure Database for PostgreSQL Flexible Server per il microservizio di raccomandazione:

HA: Standby sincrono con ridondanza di zona; predisporre repliche di lettura per la sperimentazione di nuove funzionalità.
Perché: Il ricco ecosistema di estensioni di Postgres e le capacità JSONB si adattano al servizio; l’HA gestita mantiene basso l’RTO; le repliche scaricano le letture.

Proteggere l’accesso con User delegation SAS per il caricamento temporaneo di contenuti multimediali e CMK con ambiti di crittografia per tenant:

Perché: Elimina l’esposizione delle chiavi dell’account e consente l’isolamento crittografico e l’auditabilità per tenant.

Migrare i dati degli ordini legacy da SQL Server on-premise ad Azure SQL Managed Instance per l’elaborazione di archiviazione e le attività gestite da agent:

Passaggi: Valutare con Data Migration Assistant; eseguire la migrazione online tramite DMS; connettersi tramite ExpressRoute.
Perché: MI preserva i processi di SQL Agent e le operazioni tra database, facilitando la modernizzazione e mantenendo i carichi di lavoro di archiviazione vicini ai dati nel cloud.

Questo design soddisfa le esigenze di performance globali tramite le scritture multiregione di Cosmos DB e Redis Enterprise, applica la governance con le ACL di ADLS Gen2 e l’immutabilità di Storage, offre integrità transazionale e failover rapido con i livelli di Azure SQL e i gruppi di failover automatico, e ottimizza i costi attraverso il calcolo serverless e i criteri di ciclo di vita.

← Identità · Tutti i domini · Elaborazione e architettura delle applicazioni →

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