Microsoft AZ-104: Archiviazione di Azure — 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

Azure Storage è alla base dei servizi di dati in Azure, offrendo storage a oggetti e file durevole e ad alta disponibilità, con sicurezza granulare e networking flessibile. La sua padronanza richiede la comprensione dei tipi di account e della ridondanza, del ciclo di vita e della protezione dei dati per i blob, delle opzioni di condivisione file e sincronizzazione, dell’autenticazione forte e dell’accesso controllato alla rete, e degli strumenti operativi per il trasferimento massivo e l’amministrazione.

Tipi di account di archiviazione e durabilità

Gli account General-purpose v2 (GPv2) sono la scelta predefinita e consigliata per la maggior parte degli scenari. Supportano blob (incluso lo spazio dei nomi gerarchico di Data Lake Storage Gen2 se abilitato), file, code e tabelle, su livelli di prestazioni standard basati su HDD e premium basati su SSD (premium per block blob, page blob o condivisioni di file a seconda del sottotipo). Gli account BlobStorage sono account legacy, solo per blob e con funzionalità limitate; persistono principalmente per la compatibilità con le versioni precedenti. Gli account FileStorage sono account premium specializzati per Azure Files, che forniscono IOPS e throughput predefiniti e prevedibili con bassa latenza, e supportano sia SMB che NFS 4.1.

Le scelte di ridondanza bilanciano durabilità, disponibilità e costi:

LRS archivia tre copie sincrone in un singolo datacenter, adatto per la resilienza all’interno di una zona ma non per guasti di zona o regionali.
ZRS archivia tre copie sincrone in zone di disponibilità distinte all’interno di una regione, proteggendo da un’interruzione di zona e mantenendo la disponibilità in lettura/scrittura.
GRS archivia tre copie sincrone localmente (LRS) più tre copie asincrone in una regione secondaria abbinata. La regione secondaria non è leggibile fino a un failover.
RA-GRS è GRS con accesso in lettura all’endpoint secondario, consentendo ai carichi di lavoro prevalentemente di lettura di continuare durante un’interruzione del primario. Questa è l’opzione corretta quando i dati devono essere sempre leggibili dal secondario.
GZRS combina ZRS nella regione primaria con la replica asincrona in una regione secondaria (LRS). Offre sia la tolleranza ai guasti di zona sia il disaster recovery regionale.
RA-GZRS aggiunge l’accesso in lettura al secondario per GZRS.

Scegliere RA-GRS o RA-GZRS quando sono richieste letture tra regioni, GRS/GZRS per il DR tra regioni senza accesso in lettura, ZRS per la resilienza a livello di zona con la latenza di scrittura più bassa, e LRS per una durabilità ottimizzata in termini di costi senza copertura di zona/regione.

Gestione dei dati blob, livelli e protezione

I livelli di accesso ai blob ottimizzano i costi allineando i prezzi dello storage ai modelli di accesso. Il livello Hot offre la latenza di accesso e transazione per GB più bassa, consigliato per i dati a cui si accede di frequente. Il livello Cool riduce i costi di archiviazione con costi di accesso e di eliminazione anticipata più elevati; da utilizzare per dati letti di rado (con un orizzonte di almeno 30 giorni). Il livello Archive è offline e ha il costo per GB più basso, con una latenza di riattivazione (rehydration) di ore e costi di conservazione minimi; è ideale per la conformità o il backup a lungo termine. I livelli possono essere impostati per singolo blob; un livello di accesso predefinito può essere applicato a livello di account o di contenitore per i nuovi oggetti.

Le policy di gestione del ciclo di vita automatizzano la suddivisione in livelli (tiering) e la conservazione (retention). Le regole vengono valutate giornalmente e possono filtrare per prefisso, tipo di blob, data dell’ultima modifica e tag di indice del blob. Le azioni includono lo spostamento da hot a cool, da cool ad archive, la riattivazione (in condizioni limitate) e l’eliminazione di blob di base, snapshot o versioni dopo un’età specificata. Le policy basate sull’ora dell’ultimo accesso possono affinare ulteriormente le transizioni. Regole ben progettate trasformano i costi derivanti dalla supervisione manuale in una governance basata su policy, garantendo al contempo il rispetto delle finestre di conservazione per la conformità.

Le funzionalità di protezione dei dati dovrebbero essere abilitate deliberatamente:

L’eliminazione temporanea (soft delete) dei blob conserva i blob eliminati o sovrascritti per una finestra di conservazione, consentendone il ripristino senza dover ricorrere a un backup. Si applica ai blob di base e può essere estesa a snapshot e versioni.
Il controllo delle versioni (versioning) mantiene una versione di sola lettura a ogni sovrascrittura o eliminazione, offrendo un ripristino point-in-time per oggetto e abilitando la concorrenza sicura per le applicazioni.
L’eliminazione temporanea (soft delete) dei contenitori protegge i contenitori dall’eliminazione accidentale conservandoli per un periodo configurato, consentendo il ripristino del contenitore e del suo contenuto.
Il ripristino point-in-time per i contenitori consente di ripristinare uno o più contenitori a un timestamp precedente entro un periodo di conservazione. Richiede il controllo delle versioni dei blob e il change feed, ed è particolarmente prezioso per il ripristino da corruzioni logiche su larga scala, ricostruendo lo stato a un punto coerente tra molti oggetti.

Gli snapshot per i block blob forniscono punti di ripristino ad hoc aggiuntivi, ma sono superati dal controllo delle versioni nella maggior parte dei progetti operativi. Assicurarsi che le policy del ciclo di vita e i requisiti di conservazione legale/immutabilità non entrino in conflitto, specialmente quando si combinano il tiering su Archive e la conservazione WORM.

Azure Files e Azure File Sync

Azure Files fornisce condivisioni di file completamente gestite con l’elasticità e la disponibilità globale native di Azure. Le condivisioni SMB supportano le funzionalità di SMB 3.x come la crittografia in transito, la disponibilità continua su condivisioni FileStorage premium in determinati scenari e il controllo degli accessi basato sull’identità. Le condivisioni NFS 4.1 sono disponibili solo su account FileStorage premium, ottimizzate per carichi di lavoro UNIX/Linux; utilizzano permessi POSIX e policy di esportazione, con accesso limitato a reti selezionate per motivi di sicurezza.

L’autenticazione basata sull’identità per SMB offre diverse opzioni:

Autenticazione con Active Directory Domain Services (AD DS), utilizzando un controller di dominio ospitato on-premise o in IaaS di Azure, che supporta ACL NTFS e Kerberos/NTLM.
Azure AD Domain Services (Azure AD DS), che fornisce un dominio gestito senza la necessità di gestire le VM dei controller di dominio.
Azure AD Kerberos per Azure Files, che abilita un’identità moderna ed esclusivamente cloud per l’accesso SMB da client Windows aggiunti ad Azure AD e da Windows Server 2022, eliminando la necessità di controller di dominio tradizionali pur conservando la semantica di Kerberos e delle ACL. Si integra con RBAC e con i permessi a livello di condivisione per allineare l’autorizzazione dello storage alla governance delle identità.

Azure File Sync estende Azure Files ai server Windows on-premise, trasformando la tua condivisione di file Azure in un hub per la sincronizzazione multi-sito con uno storage cloud centralizzato. Una risorsa Storage Sync Service orchestra la replica. Al suo interno, i gruppi di sincronizzazione collegano:

Un endpoint cloud, che fa riferimento a una condivisione di file Azure in un account di storage.
Uno o più endpoint server, ognuno dei quali mappa un percorso su un volume di un Windows Server registrato.

Dopo aver installato l’agente di Azure File Sync e registrato il server, aggiungi il percorso dell’endpoint server (ad esempio, D:\Shares\Projects). È possibile abilitare il tiering nel cloud per mantenere lo spazio dei nomi a livello locale, creando stub per i file usati di rado (file freddi); le policy includono obiettivi di spazio libero sul volume e la rimozione basata sull’ultimo accesso (heat-based). Il richiamo on-demand ripristina il contenuto dei file in modo trasparente al momento dell’accesso. Le strategie di seeding iniziale e di richiamo, l’integrazione con DFS-N per i referral e le esclusioni per l’antivirus per le directory di sistema di AFS sono considerazioni operative fondamentali. L’enumerazione delle modifiche e la sincronizzazione basata su journal minimizzano il carico di lavoro; il throttling e il seeding tramite trasferimento dati offline possono proteggere la larghezza di banda durante la replica iniziale.

Sicurezza, networking e accesso controllato

Le firme di accesso condiviso (SAS) concedono un accesso con ambito e durata limitati senza esporre le chiavi dell’account. Una SAS di servizio si applica a una risorsa specifica (blob, contenitore, condivisione di file, coda, tabella) con permessi definiti, orari di inizio/scadenza, intervalli IP consentiti, protocolli e nomi di oggetti preautorizzati. Una SAS di account si estende a più servizi e tipi di risorse all’interno dell’account ma non può essere associata a una policy di accesso archiviata; dovrebbe essere usata con parsimonia a causa del suo ambito più ampio. La SAS di delega utente è il modello consigliato per il servizio Blob quando si utilizza Azure AD; è firmata con una chiave di delega utente di breve durata ottenuta tramite Azure AD, producendo un token verificabile e con privilegi minimi. Le policy di accesso archiviate si collegano a contenitori o condivisioni e consentono la revoca centralizzata e l’aggiornamento di permessi/durata per più token SAS emessi, modificando o eliminando la policy.

L’autorizzazione di Azure AD si integra con Blob e Queue, e con Azure Files attraverso i modelli SMB basati su AD descritti in precedenza. Per Blob e Queue, assegna ruoli Azure RBAC come Storage Blob Data Reader, Contributor o Owner a livello di account, contenitore o gruppo di risorse. L’accesso delle applicazioni dovrebbe preferire le identità gestite e OAuth rispetto alle chiavi dell’account, riducendo il rischio di distribuzione delle chiavi e abilitando l’accesso condizionale e Privileged Identity Management su larga scala.

Il firewall dello storage applica restrizioni basate sull’origine di rete quando è impostato su Reti selezionate:

Le regole di rete virtuale concedono l’accesso a subnet specifiche che hanno endpoint di servizio Microsoft.Storage abilitati, oppure utilizzano endpoint privati per l’accesso privato per singola risorsa tramite un IP privato nella tua VNet. Gli endpoint di servizio sono più semplici da configurare e mantengono gli endpoint pubblici; gli endpoint privati forniscono l’isolamento e il controllo del traffico in uscita più robusti.
Le regole di rete IP consentono indirizzi IPv4 pubblici o intervalli CIDR per client on-premise o internet; utilizzale per un accesso amministrativo con ambito strettamente definito.
Le regole di istanza di risorsa consentono a istanze di servizi Azure attendibili (ad esempio, un’area di lavoro Synapse o una specifica Logic App) di raggiungere l’account di storage senza le ampie eccezioni “consenti servizi Microsoft attendibili”, specificando l’ID della risorsa e il tipo di servizio supportato, contribuendo a mantenere il principio del privilegio minimo.

Abilita TLS 1.2+, richiedi il trasferimento sicuro, ruota le chiavi dell’account ed esegui l’audit utilizzando le impostazioni di diagnostica di Storage Analytics e Azure Monitor. Combina le regole di rete con Azure AD RBAC e una corretta gestione delle SAS per una strategia di difesa in profondità.

← Bilanciamento del carico di Azure e Gestione del traffico · Tutti i domini · Azure App Service e Compute PaaS →

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