Microsoft AZ-204: Azure Storage e Blob Storage — 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 Storage fornisce uno storage cloud durevole e massivamente scalabile per dati non strutturati e strutturati. Per lo sviluppo di applicazioni, è fondamentale concentrarsi sulla selezione del tipo di account di archiviazione corretto, sulla configurazione della ridondanza per soddisfare gli obiettivi di RTO/RPO, sulla scelta del tipo di blob e del livello di accesso appropriati per ottimizzare costi/prestazioni e sulla protezione dell’accesso con Azure AD e SAS. Utilizzare le policy di lifecycle per automatizzare lo spostamento dei dati tra i livelli, erogare siti web statici direttamente da Blob storage quando appropriato e applicare Azure Files e Queue Storage dove sono richieste semantiche di file o un disaccoppiamento basato su messaggi.

Tipi di account di archiviazione e fondamenti della ridondanza

General-purpose v2 (GPv2) è il tipo di account standard per la maggior parte dei carichi di lavoro. Supporta blob, file, code e tabelle, tutti i livelli di accesso, la gestione del ciclo di vita e le funzionalità più recenti. Gli account legacy di tipo BlobStorage espongono solo il servizio Blob e il tiering, ma mancano dell’ampiezza di funzionalità e delle ottimizzazioni dei costi presenti in GPv2; le nuove implementazioni dovrebbero preferire GPv2. Gli account FileStorage sono account premium, basati su SSD, dedicati ad Azure Files, che offrono IOPS e throughput costanti a bassa latenza per carichi di lavoro di file enterprise (es. condivisioni di profili, app line-of-business). Scegliere FileStorage quando si richiedono prestazioni premium per condivisioni SMB/NFS; altrimenti, GPv2 è la scelta predefinita.

Le scelte di ridondanza determinano la durabilità e la disponibilità dei dati tra i domini di errore:

LRS (Locally Redundant Storage) archivia in modo sincrono tre copie all’interno di un singolo datacenter. Costo più basso, nessuna protezione a livello di zona o regione. Utilizzare per dev/test, carichi di lavoro effimeri o quando si dispone di una replica a livello superiore.
ZRS (Zone-Redundant Storage) replica in modo sincrono tra le zone di disponibilità in una regione, proteggendo da un’interruzione di zona con alta disponibilità e RPO nullo. Scegliere per ambienti di produzione in regioni con zone che richiedono resilienza intra-regionale.
GRS (Geo-Redundant Storage) archivia tre copie sincrone nella regione primaria (come LRS) e replica in modo asincrono in una regione secondaria abbinata (con LRS lì). L’RPO tipico è inferiore a 15 minuti; la secondaria non è leggibile per impostazione predefinita. Selezionare per il disaster recovery quando non è necessario l’accesso in lettura.
RA-GRS (Read-Access Geo-Redundant Storage) aggiunge l’accesso in lettura alla secondaria tramite endpoint -secondary. Utilizzare quando si richiede tolleranza ai disastri tra regioni e carichi di lavoro prevalentemente in lettura durante incidenti nella regione primaria, o per letture basate sulla prossimità geografica dove la consistenza finale (eventual consistency) è accettabile.

Quando si necessita sia della protezione dai guasti di zona sia del DR tra regioni, considerare di abbinare ZRS localmente con un pattern di account aggiuntivo geo-replicato a livello di soluzione. Pianificare i test di failover dell’account, comprendere i cambi degli endpoint DNS e convalidare le policy di retry dell’applicazione per gestire la consistenza finale e il disallineamento dell’orologio (clock skew) durante eventi geografici.

Modello dati dei blob, livelli e gestione del ciclo di vita

I blob sono disponibili in tre tipi con semantiche distinte. I Block blob sono ottimizzati per lo streaming e la lettura casuale di oggetti di grandi dimensioni come immagini, video e backup. Gli upload vengono suddivisi in blocchi e confermati (committed), abilitando upload paralleli e tentativi di ripetizione efficienti. Gli Append blob sono ottimizzati per carichi di lavoro di sola aggiunta (append-only) come la telemetria e la cattura di log; sono consentite solo operazioni di aggiunta, il che semplifica la concorrenza. I Page blob espongono pagine allineate a 512 byte per I/O di lettura/scrittura casuale e supportano i dischi rigidi virtuali di Azure (VHD) utilizzati dai dischi delle VM di Azure; sono l’unico tipo di blob supportato per i dischi IaaS e per carichi di lavoro con I/O casuale di grandi dimensioni.

I livelli di accesso ai blob (access tiers) controllano costi e prestazioni. Hot è ottimizzato per l’accesso frequente con la latenza di lettura/scrittura più bassa e il costo di archiviazione più alto. Cool è rivolto a dati a cui si accede di rado, conservati per almeno 30 giorni, con un costo di archiviazione inferiore ma costi di transazione/lettura più alti e addebiti per la conservazione minima. Archive è il livello a più basso costo per la conservazione a lungo termine; gli oggetti sono offline e devono essere ripristinati (rehydrated) al livello hot o cool prima di poter essere letti. La riattivazione (rehydration) può essere richiesta con priorità standard o alta, scambiando il costo per la velocità. È possibile impostare un livello di accesso predefinito a livello di account (hot o cool) e sovrascriverlo per singolo blob; il livello archive è impostabile solo per singolo blob.

Le policy di gestione del ciclo di vita (lifecycle management) automatizzano lo spostamento e la conservazione dei dati per controllare i costi e soddisfare la governance. A livello di account, si definiscono regole che:

Spostano blob o versioni/snapshot di blob al livello cool o archive dopo N giorni dall’ultima modifica
Eliminano blob, snapshot o versioni dopo determinate soglie di tempo
Filtrano per prefisso del contenitore e per tag di indice del blob per indirizzare specifici set di dati (ad esempio, tag env=prod e policy=retention-7y) Combinare le regole del ciclo di vita con il versioning e la cancellazione temporanea (soft delete) per proteggersi da eliminazioni accidentali, pur applicando la conservazione dei dati. Ricordare che il livello archive ha periodi di conservazione minimi e costi per l’eliminazione anticipata; progettare le policy per minimizzare le riattivazioni non necessarie.

Per il tracciamento delle modifiche e l’elaborazione a valle, abilitare il change feed dell’account di archiviazione per consumare un log ordinato e immutabile delle operazioni di creazione, aggiornamento, eliminazione e copia dei blob. Questo supporta la conformità e i processori asincroni che necessitano di semantiche exactly-once o at-least-once con checkpointing.

L’hosting di siti web statici in Blob storage espone uno speciale contenitore $web servito tramite un endpoint web dedicato. Configurare i documenti di indice e di errore e pubblicare direttamente gli asset statici. L’endpoint del sito web statico fornisce accesso anonimo in lettura al contenuto del sito, indipendentemente dall’impostazione di accesso pubblico del blob; l’accesso tramite l’endpoint del blob può rimanere disabilitato. Per domini personalizzati e accelerazione globale, anteporre all’endpoint Azure Front Door o Azure CDN. I private endpoint non sono supportati per l’endpoint del sito web statico; utilizzare un servizio edge per proteggere e accelerare la distribuzione dove è richiesto l’accesso privato.

Sicurezza, identità e accesso controllato ai dati

Azure Storage crittografa i dati a riposo (at rest) per impostazione predefinita con AES a 256 bit utilizzando chiavi gestite da Microsoft. Per un controllo più rigoroso, abilitare le chiavi gestite dal cliente (CMK) archiviate in Azure Key Vault o Managed HSM per governare la rotazione delle chiavi e la separazione dei compiti; concedere all’identità gestita dell’account di archiviazione le autorizzazioni di wrap/unwrap. Per i carichi di lavoro altamente regolamentati, abilitare la crittografia dell’infrastruttura per applicare un secondo livello di crittografia indipendente. Associare la crittografia lato server alla crittografia lato client se è richiesto un controllo crittografico end-to-end.

L’autorizzazione di Azure AD integra il piano dati con l’RBAC per i servizi Blob e Queue e per l’API REST di Files. Concedere ruoli con privilegi minimi, come Storage Blob Data Reader o Storage Blob Data Contributor, a identità gestite, utenti o gruppi. Nel codice, utilizzare DefaultAzureCredential per acquisire token OAuth 2.0 ed evitare di incorporare le chiavi. Per l’accesso SMB ad Azure Files, abilitare l’autenticazione basata sull’identità utilizzando Active Directory: associare l’account di archiviazione ad AD DS on-premise (tramite Azure AD Kerberos per le identità ibride) o ad Azure AD DS, e utilizzare le ACL NTFS e l’RBAC (ad es. Storage File Data SMB Share Contributor) per l’autorizzazione a livello di condivisione. Assicurarsi di utilizzare SMB 3.x con crittografia in transito (over the wire) e considerare l’uso di Private Endpoint, VPN o ExpressRoute per attraversare reti che bloccano la porta 445.

Le Shared Access Signature (SAS) delegano un accesso con ambito e durata limitati senza esporre le chiavi dell’account. Una SAS di servizio concede l’accesso a un servizio e una risorsa specifici (ad es. un singolo blob o contenitore) con autorizzazioni precise e orari di inizio/scadenza. Una SAS di account opera a livello di account, estendendosi a più servizi (blob, file, code, tabelle) e API di servizio come list o create. La SAS di delega utente è specifica per Blob storage ed è firmata con una chiave di delega utente ottenuta tramite Azure AD per un’entità (principal) con l’RBAC appropriato; elimina la dipendenza dalle chiavi e centralizza il controllo degli accessi in Azure AD. Applicare vincoli che includono intervalli IP, protocolli consentiti (solo HTTPS) e durate brevi. I criteri di accesso archiviati centralizzano i vincoli delle SAS e ne consentono la revoca aggiornando o eliminando il criterio; si applicano alle SAS di servizio e alle SAS di account. La SAS di delega utente non utilizza i criteri di accesso archiviati; la revoca avviene facendo scadere la chiave di delega utente o rimuovendo le assegnazioni di ruolo di Azure AD. Preferire sempre le SAS rispetto alle chiavi dell’account e preferire le SAS di delega utente quando l’applicazione può acquisire token di Azure AD.

Concetti essenziali di Azure Files e Queue Storage

Azure Files offre condivisioni SMB completamente gestite e un’opzione NFS per scenari POSIX. Utilizzare le condivisioni SMB per migrazioni lift-and-shift e per la compatibilità delle applicazioni. Gli account Premium FileStorage offrono prestazioni prevedibili a bassa latenza, mentre le condivisioni standard sono economiche per dati di file di uso generale. Gestire condivisioni e file tramite client SMB o l’API REST/SDK. Azure File Sync abilita servizi di file ibridi memorizzando nella cache una condivisione cloud su Windows Server, fornendo prestazioni locali e tiering dei dati freddi verso il cloud, sincronizzazione multi-sito e backup/DR offsite senza i tradizionali cicli di aggiornamento dei NAS. Combinare l’identità basata su Azure AD con le ACL NTFS per applicare il principio del privilegio minimo e utilizzare i Private Endpoints per contenere il rischio di esfiltrazione dei dati.

Azure Queue Storage abilita flussi di lavoro applicativi disaccoppiati e resilienti. Ogni messaggio può avere una dimensione massima di 64 KB (i payload più grandi dovrebbero fare riferimento a URI di blob). La durata (time-to-live, TTL) del messaggio ne determina la scadenza automatica; specificare un valore positivo da secondi fino a sette giorni, oppure -1 per nessuna scadenza. Quando un worker recupera un messaggio, questo diventa invisibile per la durata del suo visibility timeout. Se l’elaborazione fallisce e il messaggio non viene eliminato prima del timeout, riappare per un altro consumer. Ottimizzare il visibility timeout affinché superi il tempo di elaborazione nel caso peggiore e utilizzare gestori idempotenti con backoff esponenziale per ridurre la contesa. Tracciare il dequeue count per rilevare i poison message; quando supera una soglia, spostare il messaggio in una poison queue dedicata per la quarantena e l’analisi. I trigger di coda di Azure Functions implementano questo pattern automaticamente con una coda -poison. Per esigenze di throughput più elevato o FIFO con garanzie di ordinamento, considerare le code di Service Bus; altrimenti, Azure Queue Storage è una soluzione leggera ed economica.

Scenario pratico

National Geographic deve pubblicare un microsito di fotografia ad alto traffico con elaborazione di immagini serverless, storage ottimizzato per i costi e accesso ibrido per uno strumento editoriale on-premise. Richiedono inoltre link di condivisione sicuri e a tempo limitato per le agenzie partner e una gestione robusta dei messaggi per l’elaborazione in background.

Creare un account di storage GPv2 con RA-GRS

Perché: GPv2 sblocca i servizi Blob, Files e Queue con funzionalità di lifecycle e tiering. RA-GRS fornisce tolleranza ai disastri tra regioni e accesso in lettura agli endpoint secondari per la continuità degli asset a prevalenza di lettura durante incidenti regionali.

Abilitare l’hosting di siti web statici e distribuire gli asset del sito nel contenitore $web

Perché: I siti web statici su Blob eliminano la gestione dei server web, offrono letture a bassa latenza dal tier Hot e scalano a livello globale. Successivamente, abbinare con Azure Front Door per domini personalizzati, WAF e caching perimetrale (edge caching).

Archiviare le immagini RAW originali come block blob; la telemetria write-once come append blob

Perché: I block blob supportano upload di grandi dimensioni in parallelo e la distribuzione efficiente di derivati ottimizzati per il web. Gli append blob semplificano le scritture di log concorrenti da pipeline di elaborazione senza conflitti.

Definire policy di lifecycle per spostare gli originali nel tier Cool dopo 30 giorni e in Archive dopo 180 giorni; eliminare le versioni più vecchie di un anno

Perché: Il tiering automatizzato riduce i costi di storage in base ai pattern di accesso, mantenendo al contempo le copie per la conformità. La pulizia di versioni e snapshot controlla l’aumento incontrollato dei dati (bloat) senza intervento manuale.

Proteggere l’accesso ai dati con Azure AD e SAS di delega utente per i partner

Perché: Assegnare il ruolo Storage Blob Data Reader a una managed identity nel servizio di condivisione, ottenere chiavi di delega utente e generare token SAS di breve durata, solo HTTPS, con restrizioni IP. Questo evita di distribuire le chiavi dell’account e lega l’autorizzazione ad Azure AD.

Abilitare chiavi gestite dal cliente (CMK) con Key Vault e la crittografia dell’infrastruttura

Perché: Le CMK soddisfano requisiti di conformità e rotazione più stringenti, mentre la doppia crittografia fornisce una difesa approfondita (defense in depth) per i media sensibili.

Integrare Azure Queue Storage per l’elaborazione di immagini in background con un trigger di coda di Azure Functions; impostare il visibility timeout in modo che superi il tempo massimo di elaborazione e configurare la gestione dei poison message

Perché: Le code disaccoppiano il percorso di upload dal calcolo (compute). Il visibility timeout previene il lavoro duplicato e il runtime di Functions instrada automaticamente gli elementi falliti a una coda -poison per l’indagine.

Pubblicare gli strumenti editoriali tramite Azure Files utilizzando un account Premium FileStorage e Azure File Sync su un Windows Server on-premise

Perché: Gli editor ottengono un accesso SMB a bassa latenza con ACL NTFS e autenticazione basata sull’identità tramite AD, mentre Azure File Sync fornisce caching locale e tiering nel cloud. Il tier premium garantisce prestazioni costanti per i carichi di lavoro interattivi.

Esporre il sito web statico tramite Azure Front Door e abilitare il caching e l’HTTPS personalizzato

Perché: I POP perimetrali (Edge POP) riducono la latenza a livello globale, i domini personalizzati soddisfano i requisiti di branding e il WAF aggiunge sicurezza senza modificare il backend di storage.

Abilitare il change feed dell’account di storage e archiviarlo in uno store di conformità

Perché: Un log immutabile e ordinato delle modifiche ai blob supporta analisi a valle, auditing e riesecuzione (replay) per pipeline di contenuti riproducibili.

← Azure Functions e Calcolo Serverless · Tutti i domini · Azure Cosmos DB →

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