Microsoft AZ-104: Sottoscrizioni di Azure, Governance e Gestione dei costi — 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

Le sottoscrizioni, la governance e la gestione dei costi di Azure definiscono come strutturare, proteggere, standardizzare e pagare per le risorse cloud su larga scala. Un progetto solido inizia con una gerarchia organizzativa (gruppi di gestione e sottoscrizioni), applica l’accesso con privilegi minimi (RBAC), impone standard e conformità (Policy, Blueprints, blocchi e tag) e ottimizza continuamente la spesa (Cost Management e Advisor). Azure Resource Manager (ARM) è alla base delle operazioni di distribuzione, raggruppamento e ciclo di vita, in modo che standard e controlli vengano applicati in modo coerente dal gruppo di gestione radice fino alle singole risorse.

Struttura Organizzativa e Controllo degli Accessi

I gruppi di gestione (Management Group) sono il costrutto di livello più alto per organizzare una o più sottoscrizioni sotto un unico gruppo di gestione radice. È possibile annidare i gruppi di gestione fino a sei livelli di profondità (esclusa la radice) per rispecchiare i confini organizzativi o di ambiente (ad esempio, Corp > Prod/NonProd > Business Unit). Sia le assegnazioni di ruolo RBAC che le assegnazioni di Azure Policy applicate a un gruppo di gestione vengono ereditate da tutti i gruppi di gestione, sottoscrizioni, gruppi di risorse e risorse figlio, a meno che non vengano esplicitamente sovrascritte a un ambito inferiore. Questa ereditarietà è fondamentale per applicare gli standard in modo coerente; ad esempio, una policy “Nega archiviazione pubblica” a livello del gruppo di gestione Production si applica a ogni sottoscrizione di produzione senza la necessità di una configurazione per singola sottoscrizione.

Le sottoscrizioni (Subscription) sono confini di isolamento per la fatturazione e la distribuzione. I tipi comuni includono Pay-As-You-Go, Enterprise Agreement (EA), Microsoft Customer Agreement (MCA), CSP e offerte basate su crediti come le sottoscrizioni Visual Studio. Le sottoscrizioni separano la spesa, le quote e gli ambiti RBAC e sono l’unità atomica per addebiti e budget. Lo spostamento di risorse tra sottoscrizioni è spesso necessario durante le transizioni del ciclo di vita (ad esempio, da un tenant di sviluppo a uno di produzione, riorganizzazioni). Il supporto per lo spostamento delle risorse è specifico per provider e risorsa; le risorse basate su ARM come VM, dischi gestiti, account di archiviazione, reti virtuali e persino i vault di Recovery Services possono essere tipicamente spostate, con alcune limitazioni. I prerequisiti includono la presenza sia dell’origine che della destinazione nello stesso tenant di Azure Active Directory (gli spostamenti tra tenant diversi sono limitati), provider di risorse registrati in entrambe le sottoscrizioni, regioni/SKU compatibili e nessun blocco (lock) o policy che ne impedisca lo spostamento. Aspettarsi un’indisponibilità transitoria per alcune risorse durante lo spostamento; pianificare finestre di manutenzione per i servizi stateful. Le risorse classiche (ASM) non possono essere spostate. Verificare sempre il supporto utilizzando l’operazione “Move” nel portale o la documentazione del provider di risorse.

Azure RBAC fornisce un accesso granulare con privilegi minimi utilizzando assegnazioni di ruolo a un ambito specifico. L’ambito può essere un gruppo di gestione, una sottoscrizione, un gruppo di risorse o una singola risorsa; le assegnazioni vengono ereditate verso il basso. I ruoli predefiniti principali sono:

Owner: accesso completo a tutte le risorse, incluse le assegnazioni di ruolo.
Contributor: pieni poteri di creazione/aggiornamento/eliminazione sulle risorse, ma senza il permesso di assegnare ruoli.
Reader: accesso in sola lettura. I ruoli personalizzati (Custom role) consentono di specificare le Actions e DataActions consentite, escludendo NotActions e NotDataActions, e sono definiti a livello dell’ambito di assegnazione previsto o a un livello superiore. Le assegnazioni di negazione (Deny assignment), create da determinati servizi come Blueprints o tramite blocchi, hanno la precedenza sulle assegnazioni di autorizzazione (allow), impedendo un’escalation accidentale dei privilegi.

Governance, conformità e guardrail per le risorse

Azure Policy valuta lo stato delle risorse al momento della creazione/aggiornamento e durante le scansioni di conformità periodiche. Una definizione di policy esprime una regola (con parametri opzionali) e un effetto. Le definizioni correlate vengono raggruppate in iniziative per semplificare l’assegnazione su larga scala. Le assegnazioni collegano una definizione o un’iniziativa a un ambito (gruppo di gestione, sottoscrizione, gruppo di risorse o risorsa) con valori per i parametri e, per determinati effetti, un’identità gestita per la remediation. Effetti chiave da padroneggiare:

Deny: blocca le operazioni di creazione/aggiornamento non conformi al momento della richiesta.
Audit: consente l’operazione ma registra la non conformità per il reporting.
DeployIfNotExists: se una risorsa o un’impostazione correlata è mancante, attiva la distribuzione di un template per rendere la destinazione conforme (ad esempio, distribuire un’impostazione di diagnostica o un’assegnazione di policy). Altri effetti importanti includono Append (aggiunge campi come i tag in scrittura) e Modify (applica patch alle proprietà). Le policy possono imporre località consentite, vincoli sugli SKU, tag obbligatori, impostazioni di diagnostica e standard di crittografia. Ad esempio, limitare le località di Azure SQL Server garantisce che le distribuzioni avvengano solo in aree o gruppi di risorse approvati.

Azure Blueprints impacchetta la governance-as-code combinando artefatti — assegnazioni di policy, assegnazioni di ruolo, template ARM e dichiarazioni di gruppi di risorse — in un blueprint versionato. Assegna i blueprint a sottoscrizioni o gruppi di gestione per creare ambienti in modo coerente. L’assegnazione di un blueprint può applicare blocchi a livello di artefatto con modalità come DoNotDelete o ReadOnly per proteggere le risorse distribuite dal drift (deviazione). Usa i Blueprints per eseguire il bootstrap di nuove sottoscrizioni con controlli obbligatori e infrastruttura di base.

I blocchi delle risorse (resource lock) forniscono un’ultima linea di difesa contro le modifiche accidentali. Applica CanNotDelete per impedire l’eliminazione consentendo gli aggiornamenti; applica ReadOnly per bloccare le operazioni di scrittura ed eliminazione. I blocchi vengono ereditati dagli ambiti superiori, quindi un blocco ReadOnly su un gruppo di risorse influisce su tutte le risorse contenute (ad esempio, l’arresto/avvio di una VM fallisce perché tali operazioni eseguono scritture). I blocchi sovrascrivono le autorizzazioni RBAC: anche gli Owner non possono eliminare una risorsa bloccata senza prima rimuovere il blocco.

I tag sono coppie chiave-valore applicate a gruppi di risorse e risorse per categorizzare i carichi di lavoro (dipartimento, ambiente, centro di costo). L’ereditarietà dei tag non è automatica; per garantire i tag su ogni risorsa, utilizzare Azure Policy (Append/Modify) per imporli o ereditarli dal gruppo di risorse al momento della creazione/aggiornamento. I tag guidano il reporting dei costi basato sui tag in Cost Management, in modo che i dipartimenti vengano addebitati accuratamente. Per associare singole risorse come le macchine virtuali ai dipartimenti, applica i tag direttamente a ciascuna VM.

Gestione e ottimizzazione dei costi

Azure Cost Management + Billing fornisce budget, analisi dei costi, esportazioni e avvisi. I budget sono definiti a un ambito (sottoscrizione o gruppo di risorse) e possono filtrare per gruppo di risorse, servizio o tag. Configura soglie (es. 50%, 80%, 100%) per inviare avvisi tramite gruppi di azioni e, facoltativamente, attivare automazioni (Logic App, Function) per ridurre le risorse o spegnere carichi di lavoro non critici; i budget stessi non impongono un limite di spesa. L’analisi dei costi consente di analizzare i dati per tempo, risorsa, meter, gruppo di risorse, sottoscrizione e tag per comprendere i fattori trainanti e le tendenze; pianificare esportazioni verso lo storage per l’ingestione in strumenti di BI. I limiti di spesa sono disponibili per le offerte basate su credito (ad esempio, free trial, Visual Studio) e, una volta raggiunti, mettono la sottoscrizione in uno stato disabilitato per prevenire ulteriori addebiti. I limiti di spesa non sono supportati su offerte Pay-As-You-Go o sulla maggior parte delle offerte EA/MCA; utilizzare invece budget e automazione.

Azure Advisor valuta continuamente le tue risorse e produce raccomandazioni attuabili per costo, sicurezza, affidabilità, prestazioni ed eccellenza operativa. Le raccomandazioni sui costi includono il ridimensionamento/spegnimento di VM sottoutilizzate, l’acquisto di prenotazioni o piani di risparmio e l’eliminazione di IP pubblici o dischi inattivi. L’affidabilità include set/zone di disponibilità e configurazioni di backup; le prestazioni coprono ottimizzazioni di calcolo/storage; la sicurezza si integra con Defender for Cloud; l’eccellenza operativa evidenzia le configurazioni di best practice. Usa l’Advisor Score per monitorare i progressi e integra le raccomandazioni nel backlog o nella remediation automatizzata, ove appropriato.

Distribuzione e ciclo di vita con Azure Resource Manager

ARM è il control plane di Azure, che consente distribuzioni dichiarative e idempotenti e una gestione coerente. I gruppi di risorse sono contenitori logici per i cicli di vita e i confini RBAC; raggruppano risorse che condividono il ciclo di vita, le autorizzazioni e le dipendenze di localizzazione. Le assegnazioni di RBAC e policy a livello di gruppo di risorse governano tutte le risorse contenute, e i blocchi (lock) e i tag a livello di gruppo vengono ereditati, a meno che non vengano sovrascritti da policy o da operazioni a livello di risorsa.

I template ARM (e Bicep come linguaggio di livello superiore) definiscono risorse, parametri, variabili, output e dipendenze. Consentono distribuzioni ripetibili e garantiscono che gli artefatti di governance (ad es. policy, assegnazioni di ruolo) e i carichi di lavoro vengano applicati insieme. Utilizzare le specifiche dei template (template specs) per versionare e condividere i template all’interno dell’organizzazione. Le modalità di distribuzione sono importanti:

Incrementale (Incremental): crea/aggiorna le risorse nel template; non rimuove le risorse esistenti che non sono presenti nel template.
Completa (Complete): dopo la distribuzione, elimina le risorse nell’ambito di destinazione che non sono definite nel template — da usare con cautela per imporre uno stato desiderato rigoroso all’interno del gruppo di risorse. La cronologia delle distribuzioni ha come ambito il gruppo di risorse, la sottoscrizione o il gruppo di gestione. Quando più risorse vengono distribuite da un singolo template, è possibile visualizzare la distribuzione e il relativo template dal pannello (blade) Deployment dell’ambito di destinazione — comunemente il gruppo di risorse — per verificare le modifiche e risolvere i problemi.

Scenario pratico

Starbucks acquisisce una catena regionale e deve integrare tre nuove sottoscrizioni, applicando al contempo le policy di sicurezza globali, abilitando l’addebito a livello di dipartimento (chargeback) e migrando diversi servizi condivisi in una sottoscrizione consolidata “Corp-IT” senza interruzione del servizio.

Costruire la gerarchia dei gruppi di gestione

Azione: Creare una gerarchia allineata alla radice (root) Starbucks > Prod/NonProd > BusinessUnits (Retail, SupplyChain, CorpIT).
Perché: I gruppi di gestione forniscono ereditarietà gerarchica per RBAC e Policy, in modo che i controlli globali (ad es. le baseline di sicurezza) vengano applicati automaticamente a ogni nuova sottoscrizione.

Definire l’accesso di base con RBAC

Azione: A livello di BusinessUnits, assegnare il ruolo Reader al team di Audit, Owner al team della piattaforma centrale in CorpIT e Contributor agli amministratori delegati delle BU nei rispettivi ambiti. Creare un ruolo personalizzato “Tag-Editor” che consenta l’azione

undefined

Perché: Il principio del privilegio minimo (least-privilege) applicato all’ambito corretto previene l’eccesso di autorizzazioni, pur consentendo l’autonomia delle BU; un ruolo personalizzato evita di concedere l’accesso completo in scrittura per la manutenzione dei tag.

Imporre la governance usando Policy e Blueprints

Azione: Creare un’iniziativa (initiative) che includa policy per le località consentite, i tag obbligatori (CostCenter, Department, Environment), le impostazioni di diagnostica sui servizi chiave e il “Nega accesso pubblico” (Deny public access) sugli account di archiviazione. Impacchettarla in un Azure Blueprint con i seguenti artefatti: l’assegnazione dell’iniziativa, le assegnazioni di ruolo RBAC, i template ARM per un’area di lavoro Log Analytics condivisa e un piano DDoS, e un layout standard per i gruppi di risorse. Assegnare il blueprint a ogni nuova sottoscrizione con blocchi DoNotDelete sulle risorse di base.
Perché: I Blueprints forniscono una landing zone versionata e ripetibile con blocchi per prevenire la cancellazione accidentale; le Policy assicurano che ogni risorsa sia conforme al momento della creazione e correggono le deviazioni (drift) tramite DeployIfNotExists.

Applicare i tag e garantirne l’ereditarietà

Azione: Usare una policy di tipo Modify per ereditare i tag dai gruppi di risorse e una policy di tipo Append per aggiungere i tag mancanti al momento della creazione/aggiornamento della risorsa. Richiedere valori per CostCenter che corrispondano al sistema finanziario di Starbucks.
Perché: L’ereditarietà nativa non è automatica; le Policy assicurano che tutte le risorse abbiano i metadati necessari per la reportistica dei costi basata sui tag.

Configurare Cost Management e gli avvisi

Azione: Creare budget a livello di ogni sottoscrizione e dei gruppi di risorse critici, filtrati per tag dove appropriato, con avvisi al 50/80/100% inviati a un gruppo di azioni (action group) che attiva una Logic App per notificare i responsabili delle BU e, opzionalmente, ridurre le risorse di sviluppo/test. Configurare dashboard di analisi dei costi (Cost Analysis) per tag ed esportare i dati giornalmente su un account di archiviazione.
Perché: I budget e gli avvisi forniscono un preallarme e attivano azioni correttive quasi in tempo reale; i pivot basati sui tag consentono un addebito (chargeback) accurato.

Migrare i servizi condivisi in sicurezza tra sottoscrizioni

Azione: Convalidare il supporto allo spostamento (move) per le risorse di destinazione (VM, dischi gestiti, VNet, account di archiviazione, insiemi di credenziali di Recovery Services). Rimuovere i blocchi (lock) che impediscono l’operazione, assicurarsi che i provider di risorse siano registrati nelle sottoscrizioni di origine/destinazione, confermare la compatibilità di regione/SKU e pianificare una finestra di manutenzione. Utilizzare l’operazione di spostamento (Move) dall’ambito del gruppo di risorse per trasferire le risorse nella sottoscrizione Corp-IT; riconvalidare le impostazioni di diagnostica e le policy dopo lo spostamento.
Perché: Lo spostamento a livello di gruppo di risorse preserva le dipendenze e minimizza i tempi di inattività; i controlli preliminari evitano fallimenti dovuti a incompatibilità di policy o provider.

Proteggere le risorse critiche con i blocchi (lock)

Azione: Applicare un blocco CanNotDelete alle risorse fondamentali di rete e monitoraggio; applicare un blocco ReadOnly a un gruppo di risorse contenente una golden image.
Perché: I blocchi (lock) prevalgono su RBAC per prevenire la cancellazione o la modifica accidentale degli asset di base, pur consentendo le normali operazioni altrove.

Ottimizzare continuamente con Advisor

Azione: Rivedere settimanalmente le raccomandazioni di Advisor; accettare le raccomandazioni sui costi per ridimensionare (rightsize) le VM sottoutilizzate e acquistare prenotazioni (reservation) per i carichi di lavoro stabili; monitorare i progressi con l’Advisor Score.
Perché: Advisor rende operativa l’ottimizzazione continua per costi, sicurezza, affidabilità, prestazioni ed eccellenza operativa, mantenendo la governance anche dopo la distribuzione iniziale.

← Azure Active Directory e Gestione delle identità · Tutti i domini · Macchine virtuali di Azure e Compute →

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