Microsoft AZ-900: Archiviazione e Database — Guida allo studio

By Laurynas Brazys · 23 July 2026 · #microsoft #az-900 #certification #exam-prep #study-guide

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

Azure fornisce una base ampia per l’archiviazione di dati non strutturati e strutturati su scala globale, con durabilità, sicurezza e controlli dei costi integrati. Comprendere la primitiva di archiviazione, il modello di ridondanza, il livello di accesso e il servizio di database corretti permette di realizzare applicazioni affidabili e performanti, dalle macchine virtuali alle piattaforme web e mobili distribuite a livello globale.

Servizi di Azure Storage e dischi gestiti

Azure Blob Storage è il fondamento per i dati non strutturati. I block blob gestiscono oggetti di grandi dimensioni con streaming e caricamento parallelo efficienti, snapshot, gestione delle versioni e tiering. I page blob sono ottimizzati per I/O di lettura/scrittura casuale in pagine da 512 byte e supportano i dischi rigidi virtuali; stanno alla base dei dischi e degli scenari che richiedono IOPS costanti a bassa latenza. Gli append blob sono pensati per scenari di accodamento con carichi di scrittura intensi, come i log delle applicazioni, dove i nuovi blocchi vengono aggiunti in modo efficiente alla fine. Azure Files offre condivisioni di file completamente gestite, accessibili tramite SMB o NFS con ACL NTFS, opzioni di integrazione con le directory e Azure File Sync per memorizzare nella cache i dati ad accesso frequente su Windows Server. Queue Storage fornisce una messaggistica applicativa leggera e durevole per disaccoppiare i componenti con una semantica di consegna “at-least-once” (almeno una volta). Table Storage offre un archivio chiave/attributo senza schema per set di dati vasti e partizionati, in cui si controllano le chiavi di partizione e di riga per ottenere scalabilità ed efficienza dei costi. I dischi gestiti (Managed disks) forniscono un’archiviazione a blocchi durevole e persistente per le Macchine Virtuali di Azure, senza dover gestire direttamente gli account di archiviazione o i page blob. È possibile scegliere tra Standard HDD per carichi di lavoro con throughput ottimizzato per i costi, Standard SSD per prestazioni bilanciate, Premium SSD e Premium SSD v2 per IOPS elevati a bassa latenza, e Ultra Disk per i carichi di lavoro transazionali più esigenti con IOPS e throughput configurabili. I dischi gestiti supportano snapshot, backup incrementali, crittografia del disco e opzioni di disponibilità allineate agli SLA delle VM.

• Blob – Block blob
  • Modello di dati o pattern di I/O: Oggetti di grandi dimensioni, I/O sequenziale
  • Funzionalità principali: Tiering, snapshot, gestione delle versioni, policy del ciclo di vita
  • Casi d’uso tipici: Immagini, video, backup, landing zone per big data
  • Limiti/note importanti: Singolo blob fino a ~190 TiB; non ottimizzato per I/O casuale
• Blob – Page blob
  • Modello di dati o pattern di I/O: I/O casuale in pagine da 512 byte
  • Funzionalità principali: Letture/scritture a bassa latenza, supporto per VHD
  • Casi d’uso tipici: Archiviazione sottostante per dischi e scenari che richiedono accesso casuale
  • Limiti/note importanti: Dimensione del page blob fino a 8 TiB; i dischi gestiti ne fanno un’astrazione
• Blob – Append blob
  • Modello di dati o pattern di I/O: Scritture in sola aggiunta (append-only)
  • Funzionalità principali: Accodamenti efficienti per i log, opzioni di immutabilità
  • Casi d’uso tipici: Telemetria e log delle applicazioni
  • Limiti/note importanti: Aggiornamento sul posto non supportato; si applicano limiti al numero di blocchi
• Azure Files
  • Modello di dati o pattern di I/O: Semantica dei file POSIX/SMB/NFS
  • Funzionalità principali: Accesso SMB/NFS, ACL NTFS, integrazione con AD DS/Azure AD DS, File Sync
  • Casi d’uso tipici: Condivisioni di file in “lift-and-shift”, configurazione di app, directory home degli utenti
  • Limiti/note importanti: Livelli Standard e Premium; condivisioni di file di grandi dimensioni fino a 100 TiB
• Queue Storage
  • Modello di dati o pattern di I/O: Coda di messaggi
  • Funzionalità principali: Consegna “at-least-once”, timeout di visibilità, gestione dei “poison message” (messaggi non elaborabili)
  • Casi d’uso tipici: Elaborazione in background, microservizi disaccoppiati
  • Limiti/note importanti: Dimensione del messaggio fino a 64 KB (usare Service Bus per pattern più grandi/avanzati)
• Table Storage
  • Modello di dati o pattern di I/O: NoSQL chiave/attributo
  • Funzionalità principali: Scala massiva, partizionamento tramite PartitionKey, basso costo
  • Casi d’uso tipici: Telemetria, cataloghi, profili utente
  • Limiti/note importanti: Nessun join o indice secondario; usare l’API Table di Cosmos DB per esigenze globali
• Managed disks
  • Modello di dati o pattern di I/O: Archiviazione a blocchi per VM
  • Funzionalità principali: SKU Standard/Premium/Ultra, snapshot, scalabilità, crittografia del disco
  • Casi d’uso tipici: Dischi OS/dati per VM, DB, app line-of-business
  • Limiti/note importanti: Fino a 32 TiB per disco; ZRS disponibile per SKU selezionate

Opzioni di ridondanza e durabilità

I modelli di ridondanza definiscono dove e quante repliche sincrone e asincrone Azure mantiene per i tuoi dati. L’archiviazione con ridondanza locale (LRS) conserva tre copie all’interno di un singolo datacenter in una regione, proteggendo dai guasti di dischi e rack al costo più basso. L’archiviazione con ridondanza di zona (ZRS) distribuisce tre copie sincrone tra zone di disponibilità separate in una regione, fornendo resilienza a un’interruzione di zona senza richiedere il failover dell’applicazione. L’archiviazione con ridondanza geografica (GRS) estende LRS replicando in modo asincrono i dati nella regione abbinata, ottenendo un totale di sei copie su due regioni; dopo che Microsoft avvia il failover dell’account, la regione secondaria diventa la nuova primaria. L’archiviazione con ridondanza geografica e accesso in lettura (RA-GRS) aggiunge un endpoint secondario attivo di sola lettura, in modo che le applicazioni possano leggere dalla regione secondaria anche prima del failover, abilitando la distribuzione globale delle letture e l’offload delle analisi. L’archiviazione con ridondanza geografica di zona (GZRS) combina ZRS nella regione primaria con la replica asincrona verso LRS nella regione abbinata, proteggendo sia dai guasti di zona che da quelli regionali; una variante con accesso in lettura (RA-GZRS) fornisce endpoint di lettura sulla secondaria. La scelta è guidata dagli obiettivi di ripristino, dalle aspettative di latenza e dal budget. All’interno di una regione, ZRS protegge dai guasti di zona mantenendo bassa la latenza di scrittura. Tra regioni diverse, GRS/RA-GRS e GZRS sono preferiti per il disaster recovery e per scenari di lettura interregionali. La coerenza dei dati verso la regione secondaria è asincrona per progettazione nelle opzioni geografiche, quindi le applicazioni dovrebbero tollerare l’eventual consistency fino al completamento di un failover.

• LRS
  • Layout di replica: 3 copie in un singolo datacenter (regione)
  • Accesso in lettura al secondario: No
  • Tolleranza a guasti regionali/di zona: Protegge da guasti hardware/rack locali
  • Carichi di lavoro comuni: Sviluppo/test, archiviazione a basso costo, dati non critici
• ZRS
  • Layout di replica: 3 copie sincrone distribuite su 3 zone di disponibilità (regione)
  • Accesso in lettura al secondario: No
  • Tolleranza a guasti regionali/di zona: Sopravvive a interruzioni di zona senza failover a livello di applicazione
  • Carichi di lavoro comuni: Contenuti web/app di produzione che necessitano di alta disponibilità regionale
• GRS
  • Layout di replica: LRS nella regione primaria + LRS asincrono nella regione abbinata (totale ~6 copie)
  • Accesso in lettura al secondario: No
  • Tolleranza a guasti regionali/di zona: DR regionale tramite failover dell’account; nessuna protezione di zona nella primaria
  • Carichi di lavoro comuni: Backup/archiviazione con una postura di DR regionale
• RA-GRS
  • Layout di replica: GRS + endpoint di lettura sulla regione secondaria
  • Accesso in lettura al secondario: Sì
  • Tolleranza a guasti regionali/di zona: Come GRS; abilita la distribuzione globale delle letture
  • Carichi di lavoro comuni: Letture di contenuti globali, analisi/reporting sul secondario
• GZRS
  • Layout di replica: ZRS nella regione primaria + LRS asincrono nella regione abbinata
  • Accesso in lettura al secondario: No (usare RA-GZRS)
  • Tolleranza a guasti regionali/di zona: Protegge da guasti di zona e disastri regionali
  • Carichi di lavoro comuni: Applicazioni mission-critical che richiedono resilienza di zona e geografica

Livelli di accesso e gestione del ciclo di vita

I livelli di accesso ai blob allineano il costo di archiviazione ai modelli di accesso. Il livello Hot è ottimizzato per l’accesso frequente, con i costi di transazione di lettura e scrittura più bassi a fronte di un prezzo di archiviazione per GB più elevato. Il livello Cool riduce il prezzo di archiviazione per GB e aumenta i costi di transazione e di eliminazione anticipata, rendendolo adatto a set di dati a cui si accede di rado, come report mensili o backup a breve termine. Il livello Archive offre il costo di archiviazione più basso ma richiede la reidratazione prima dell’accesso, con le tariffe di accesso e di eliminazione anticipata più elevate; è progettato per scenari di conservazione a lungo termine e di conformità. Le policy di gestione del ciclo di vita automatizzano il tiering e la conservazione a livello di contenitore o di account. Le regole possono spostare i blob tra i livelli Hot, Cool e Archive in base all’ora dell’ultima modifica, all’ora dell’ultimo accesso o ai tag di indice del blob; e possono eliminare versioni, snapshot o blob di base dopo un periodo di tempo definito. Le policy aiutano a ridurre il costo totale di proprietà spostando i dati “freddi” dall’archiviazione Hot e ritirando i dati obsoleti senza intervento manuale. La gestione del ciclo di vita è disponibile per gli account di archiviazione general-purpose v2 e Blob storage e opera su block blob e append blob; non è applicabile all’archiviazione premium block blob. La reidratazione dall’archivio supporta opzioni a priorità standard e alta, scambiando il costo con la velocità. Pianificare finestre di recupero misurate in ore per la reidratazione standard e da minuti a ore per quella ad alta priorità su oggetti più piccoli. Per la conformità, abbinare il livello Archive a policy di immutabilità (conservazione basata sul tempo o blocco a fini giudiziari) per applicare garanzie WORM (write-once, read-many) a livello di contenitore o di blob.

• Hot
  • Costo di archiviazione: Più alto
  • Costo di accesso/transazione: Più basso
  • Conservazione minima: Nessuna
  • Latenza di recupero: Millisecondi (online)
  • Dati tipici: Contenuti attivi, dati letti/scritti di frequente
• Cool
  • Costo di archiviazione: Inferiore a Hot
  • Costo di accesso/transazione: Superiore a Hot; si applica una tariffa per l’eliminazione anticipata
  • Conservazione minima: 30 giorni
  • Latenza di recupero: Millisecondi (online)
  • Dati tipici: Dati ad accesso infrequente, backup a breve termine
• Archive
  • Costo di archiviazione: Più basso
  • Costo di accesso/transazione: Più alto; si applica una tariffa per l’eliminazione anticipata
  • Conservazione minima: 180 giorni
  • Latenza di recupero: Ore (richiede reidratazione)
  • Dati tipici: Conservazione a lungo termine, archivi di conformità, backup ad accesso raro

Sicurezza, crittografia e controllo degli accessi

La crittografia at-rest è abilitata per impostazione predefinita tramite la Storage Service Encryption (SSE). Di default, le chiavi gestite da Microsoft proteggono i dati in modo trasparente. Per un controllo più rigoroso e la separazione dei compiti, è possibile configurare chiavi gestite dal cliente (CMK) per ogni account di archiviazione, utilizzando chiavi in Azure Key Vault o un Managed HSM, supportando flussi di lavoro di rotazione e revoca delle chiavi. Per i carichi di lavoro sensibili, le opzioni di doppia crittografia e confidential computing riducono ulteriormente i rischi di esposizione dei dati. In transito, imporre l’uso di HTTPS con TLS per tutte le operazioni sul piano dati. Il controllo degli accessi comprende l’autorizzazione basata sull’identità e i token con ambito limitato. Azure RBAC si integra con Microsoft Entra ID per concedere l’accesso con privilegi minimi al piano dati, come i ruoli Storage Blob Data Reader/Contributor, a utenti, gruppi e identità gestite. RBAC elimina i segreti condivisi e supporta l’accesso condizionale, Privileged Identity Management e l’auditing. Le Shared Access Signatures (SAS) delegano un accesso limitato nel tempo e nelle autorizzazioni a client che potrebbero non avere un’identità; le SAS possono essere firmate con le chiavi dell’account o con la delega utente utilizzando le credenziali di Microsoft Entra per evitare di esporre le chiavi dell’account. Combinare RBAC per l’accesso tra servizi e amministrativo con le SAS per i flussi di accesso temporaneo dei client. Proteggere le chiavi dell’account e ruotarle regolarmente; preferire le SAS con delega utente quando possibile. L’isolamento di rete con Private Endpoints o endpoint di servizio, le regole del firewall e le policy di archiviazione immutabile completano una strategia di difesa approfondita (defense-in-depth) per gli account di archiviazione.

• Azure RBAC (Microsoft Entra ID)
  • Ambito: Ruoli basati sull’identità sul piano dati e sul piano di gestione dell’archiviazione
  • Ideale per: Amministratori, servizi e app con identità gestite
  • Proprietà chiave: Privilegio minimo, accesso condizionale, auditabilità, assenza di segreti condivisi
  • Considerazioni sul rischio: Richiede l’integrazione dell’identità; la revoca avviene tramite modifiche ai ruoli
• Shared Access Signature (SAS)
  • Ambito: Token con scadenza temporale e autorizzazioni limitate su risorse specifiche
  • Ideale per: Delegare accesso limitato a client/partner
  • Proprietà chiave: Autorizzazioni granulari, vincoli di IP/tempo; le SAS con delega utente evitano le chiavi dell’account
  • Considerazioni sul rischio: La fuga del token garantisce l’accesso fino alla scadenza; proteggere la distribuzione e impostare durate brevi

PaaS relazionale e NoSQL distribuito a livello globale

Azure SQL Database offre un motore relazionale gestito con patching automatico, alta disponibilità integrata, backup e scalabilità. È possibile distribuire database singoli o pool elastici per consolidare carichi di lavoro variabili. Il servizio mantiene più repliche all’interno di una regione e supporta la ridondanza di zona; la Transparent Data Encryption (TDE) è attiva per impostazione predefinita. I backup automatici consentono il ripristino point-in-time, tipicamente per 7-35 giorni, con una conservazione a lungo termine opzionale fino a diversi anni in archiviazione Azure. Per la resilienza multi-regione e le letture a bassa latenza, utilizzare la replica geografica attiva (fino a quattro repliche secondarie leggibili) o i gruppi di failover automatico per un DR coordinato su larga scala. Azure SQL Managed Instance offre una compatibilità quasi del 100% con il motore di SQL Server per funzionalità a livello di istanza come SQL Agent, query tra database, Service Broker e CLR, consentendo una modernizzazione diretta dall’on-premise senza refactoring. Condivide la stessa architettura HA gestita, il patching online, i backup automatici, la TDE predefinita e supporta i gruppi di failover automatico tra regioni. L’isolamento di rete con endpoint privati e la scalabilità di calcolo/archiviazione per database o per istanza forniscono profili di prestazione prevedibili. Azure Cosmos DB fornisce un database NoSQL multi-modello completamente gestito con distribuzione globale chiavi in mano e scritture multi-regione. Garantisce latenze nell’ordine di millisecondi a una cifra al 99° percentile all’interno di una regione e offre cinque livelli di coerenza regolabili per bilanciare prestazioni e correttezza tra le regioni. È possibile effettuare il provisioning del throughput in RU/s o utilizzare l’autoscaling, aggiungere o rimuovere regioni senza tempi di inattività e configurare il failover automatico. Le API includono Core (SQL), MongoDB, Cassandra, Gremlin e Table, semplificando la migrazione e l’integrazione tra diversi stack applicativi.

• Azure SQL Database
  • Modello: PaaS relazionale (DB singolo/pool elastico)
  • Compatibilità: Ultime funzionalità SQL; compatibilità a livello di app
  • HA/DR: Repliche integrate, ridondanza di zona; replica geografica attiva; gruppi di failover automatico
  • Backup/TDE: PITR automatico 7–35 giorni; LTR fino a anni; TDE attiva di default
  • Opzioni geografiche: Repliche secondarie leggibili tra regioni; gruppi di failover coordinati
  • Ideale per: App SaaS/multi-tenant, nuovi carichi di lavoro relazionali cloud-native
• Azure SQL Managed Instance
  • Modello: PaaS relazionale (istanza)
  • Compatibilità: Elevata parità di funzionalità con SQL Server, incl. SQL Agent, cross-DB
  • HA/DR: HA integrata; ridondanza di zona; gruppi di failover automatico
  • Backup/TDE: PITR automatico 7–35 giorni; LTR; TDE attiva di default; supporto al ripristino nativo
  • Opzioni geografiche: Multi-regione con gruppi di failover e repliche secondarie leggibili
  • Ideale per: Lift-and-shift di SQL on-premise con modifiche minime
• Azure Cosmos DB
  • Modello: NoSQL, multi-modello (Core, MongoDB, Cassandra, Gremlin, Table)
  • Compatibilità: Compatibilità a livello di API per stack NoSQL popolari
  • HA/DR: Scritture multi-regione, multi-master; SLA del 99,99%
  • Backup/TDE: Opzioni di backup automatico e continuo; crittografia at-rest
  • Opzioni geografiche: Aggiunta/rimozione di regioni in tempo reale; coerenza regolabile; failover automatico
  • Ideale per: App globali a bassa latenza, IoT, cataloghi, personalizzazione

Problema pratico: Tailwind Traders: resilienza bicoastal con tier di dati sicuri e ottimizzati per i costi

Scenario: Tailwind Traders gestisce operazioni di e-commerce con carichi di lavoro primari in East US e una presenza di disaster recovery in West US. Le immagini dei prodotti e i log sono archiviati in uno storage a oggetti, mentre gli ordini e l’inventario girano su un database relazionale gestito. Durante gli incidenti a livello di region, l’azienda richiede l’accesso in lettura ai media dei prodotti dalla region secondaria per mantenere il catalogo navigabile. La data governance richiede la crittografia con chiavi gestite dal cliente (customer-managed keys) e la conservazione basata sul tempo dei log di audit.

Sfida: Progettare servizi di storage e database che forniscano accesso in lettura cross-region per i media, un ciclo di vita e una conservazione automatizzati per i log, una crittografia robusta e un accesso basato sul principio del privilegio minimo (least-privilege), e un backend relazionale gestito con alta disponibilità e disaster recovery integrati.

Approccio consigliato:

1. 1. Creare un account di storage v2 per utilizzo generico in East US con RA-GRS (o RA-GZRS se è richiesta anche la resilienza di zona) per i contenitori dei media dei prodotti.
2. 2. Abilitare solo HTTPS, configurare un private endpoint verso la VNet e integrare le chiavi gestite dal cliente (customer-managed keys) da Azure Key Vault per l’account di storage.
3. 3. Definire policy del ciclo di vita: spostare i media non utilizzati per 30 giorni nel tier Cool e in Archive dopo 180 giorni; eliminare i media archiviati dopo 5 anni.
4. 4. Per i log applicativi di tipo append-only, utilizzare un contenitore di append blob con policy di conservazione immutabili (basate sul tempo) e una regola del ciclo di vita separata per trasferire i log più vecchi nel tier Archive.
5. 5. Concedere l’accesso all’applicazione utilizzando Azure RBAC (ruolo Storage Blob Data Contributor) alle identità gestite; emettere SAS di delega utente (user-delegation SAS) a breve termine per gli upload dei partner in un contenitore di staging.
6. 6. Effettuare il provisioning di Azure SQL Database (livello Business Critical o General Purpose con ridondanza di zona) per ordini e inventario; configurare i gruppi di failover automatico (Auto-failover groups) per la replica in West US.
7. 7. Convalidare i backup automatici (PITR 7–35 giorni) e abilitare la conservazione a lungo termine (long-term retention) per i database soggetti a conformità, come richiesto.
8. 8. Implementare la Transparent Data Encryption (abilitata per impostazione predefinita) e, se necessario, utilizzare la propria chiave (bring your own key) per la risorsa SQL server.
9. 9. Aggiornare l’app di e-commerce per leggere i media dei prodotti tramite l’endpoint secondario RA quando la region primaria è degradata; continuare le scritture transazionali sull’istanza SQL primaria fino al failover.
10. 10. Eseguire esercitazioni di failover sia per lo storage (failover dell’account) sia per SQL (gruppo di failover automatico) e documentare RTO/RPO rispetto agli obiettivi di business.

Logica di Azure: RA-GRS fornisce tre repliche sincrone nella region primaria più una replica asincrona nella region abbinata ed espone un endpoint secondario di sola lettura, soddisfacendo il requisito di servire le letture del catalogo durante un’interruzione a livello di region. Le policy del ciclo di vita allineano i costi di archiviazione ai modelli di accesso tramite il tiering dei media a cui si accede di rado verso i livelli Cool e Archive e imponendo la conservazione basata sul tempo per i log con immutabilità. Le chiavi gestite dal cliente (customer-managed keys) e i private endpoint rafforzano la sicurezza e la conformità, mentre Azure RBAC e le SAS di delega utente (user-delegation SAS) applicano il principio del privilegio minimo e una delega sicura. Azure SQL Database offre HA integrata, TDE e backup automatizzati; i gruppi di failover automatico (Auto-failover groups) forniscono un failover cross-region controllato e testato per i carichi di lavoro transazionali al fine di mantenere la continuità del servizio.

← Reti · Tutti i domini · Identità →

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

Sfoglia Microsoft →