Microsoft AZ-900: Monitoraggio, Automazione e Gestione — 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.

L’eccellenza operativa in Azure dipende da piattaforme osservabili, automazione ripetibile e governance unificata per ambienti cloud e ibridi. Azure Monitor fornisce la spina dorsale della telemetria per metriche, log, tracce e insight end-to-end delle applicazioni. Gli strumenti di gestione, che vanno dal portale di Azure alla CLI e a PowerShell, consentono ai team di agire su tali insight su larga scala. I servizi di automazione, insieme ad Azure Arc e Azure Lighthouse, estendono il controllo a server e cluster ovunque si trovino e semplificano le operazioni cross-tenant per i service provider e l’IT centrale.

Azure Monitor: metriche, log, avvisi e insight applicativi

Azure Monitor raccoglie due tipi di segnali principali: metriche e log. Le metriche sono serie temporali numeriche leggere, ottimizzate per scenari quasi in tempo reale come dashboard e autoscale, e vengono generalmente conservate per 93 giorni. I log sono record ricchi e con schema flessibile, archiviati in aree di lavoro Log Analytics e interrogati con Kusto Query Language (KQL). Con l’agente di Azure Monitor e le Data Collection Rules (DCR), i dati provenienti da VM, server abilitati per Arc e dalla diagnostica della piattaforma possono essere instradati verso una o più aree di lavoro in diverse region per l’analisi centralizzata e la conservazione a lungo termine. La conservazione per i log standard è configurabile, comunemente da 30 a 730 giorni, con opzioni di archiviazione a basso costo e reidratazione disponibili per indagini storiche. Application Insights, basato su Azure Monitor, strumenta le applicazioni per il tracciamento distribuito, il monitoraggio delle dipendenze, i test di disponibilità e il rilevamento automatico delle anomalie. Supporta OpenTelemetry per un’acquisizione vendor-neutral, consentendo agli sviluppatori di correlare le chiamate di client, server e database in un’unica mappa delle transazioni. Live Metrics fornisce telemetria del server secondo per secondo senza campionamento, mentre il campionamento adattivo riduce i costi di acquisizione senza perdere la tracciabilità end-to-end per i fallimenti critici. Il sistema di avvisi copre gli ambiti di risorsa, sottoscrizione e tenant. Gli avvisi sulle metriche valutano soglie di serie temporali con una granularità di un minuto e possono regolarsi automaticamente tramite soglie dinamiche. Gli avvisi sui log eseguono query KQL pianificate per rilevare pattern complessi tra risorse e region, mentre gli avvisi del log attività si attivano su eventi del piano di controllo come create, update o delete. I gruppi di azioni disaccoppiano il rilevamento dalla risposta, attivando notifiche (email, SMS, push, voce) e automazioni (webhook/secure webhook, Logic Apps, Functions, runbook di Automation, connettori ITSM). Le regole di soppressione e le regole di elaborazione degli avvisi aiutano a ridurre il rumore silenziando o instradando gli avvisi durante le finestre di manutenzione pianificata. Dashboard e Workbook presentano la telemetria in modo diverso. Le dashboard di Azure sono canvas multi-servizio basati su riquadri, ideali per viste operative rapide e per aggiungere grafici di metriche. I Workbook sono analitici, parametrizzati e collaborativi, e uniscono metriche, log e visualizzazioni con un’interattività basata su query. I Workbook eccellono per i runbook operativi, l’analisi post-incidente e le revisioni dei servizi, dove gli operatori possono eseguire pivot tra le dimensioni ed effettuare il drill-down nei dati grezzi senza abbandonare il contesto.

Segnali di Service Health e resilienza delle risorse

La disponibilità e la manutenzione della piattaforma richiedono un monitoraggio dedicato che vada oltre le metriche delle risorse. Azure Service Health fornisce una visibilità personalizzata su problemi di servizio, manutenzione pianificata e avvisi sullo stato di integrità che interessano le specifiche region e i servizi di una sottoscrizione. Integra la pagina pubblica dello stato di Azure fornendo impatto a livello di sottoscrizione, tempistiche e analisi delle cause principali (root-cause analysis), quando disponibili. È possibile configurare avvisi di integrità per notificare i team operativi tramite gruppi di azioni nel momento in cui un incidente di servizio regionale impatta i workload distribuiti. Resource Health si concentra sullo stato delle singole risorse come macchine virtuali, servizi app o database. Distingue tra interruzioni causate dalla piattaforma ed eventi avviati dall’utente, fornendo stati di integrità attuali e storici. L’integrazione degli avvisi di Service Health e Resource Health con la gestione degli incidenti garantisce che i team vengano notificati quando la piattaforma è la causa principale, riducendo il tempo speso per la risoluzione di problemi su componenti applicativi che in realtà sono sani. La combinazione di questi segnali con gli avvisi di Azure Monitor produce una visibilità full-stack: performance applicative, utilizzo dell’infrastruttura e disponibilità della piattaforma in un unico quadro operativo.

Strumenti di gestione per il controllo operativo

Le attività operative spaziano dalla risoluzione interattiva dei problemi, all’automazione tramite script e al triage da dispositivi mobili. Il portale di Azure offre un’esperienza completa e basata sui ruoli per configurare servizi, visualizzare metriche e avviare Cloud Shell direttamente nel contesto. L’app mobile di Azure supporta controlli dello stato di integrità in mobilità, la conferma degli avvisi e azioni rapide come il riavvio di una VM. Per la ripetibilità e l’integrazione con CI/CD, Azure CLI e Azure PowerShell forniscono automazione multipiattaforma con un’autenticazione coerente tramite Microsoft Entra ID e il supporto per flussi sia interattivi che non interattivi. Cloud Shell fornisce un terminale sicuro basato su browser con Bash e PowerShell, precaricato con Azure CLI, i moduli Az di PowerShell e strumenti comuni come Git e Terraform. Le sessioni vengono eseguite in un container gestito da Microsoft; una condivisione di Azure Files rende persistenti i profili utente e gli script. Questo elimina le discrepanze negli strumenti locali e semplifica le operazioni just-in-time eseguite dal portale, senza dover gestire ambienti di runtime. Per l’automazione a lunga esecuzione o ad alta produttività, ospita la CLI/PowerShell in pipeline o runner containerizzati e autenticati con identità gestite o credenziali federate per evitare la proliferazione di segreti (secret sprawl).

• Portale di Azure
  • Interfaccia: UI Web
  • Ideale per: Configurazione, visualizzazione, attività ad-hoc
  • Punti di forza: UX ricca, copertura approfondita dei servizi, Cloud Shell integrata
  • Limiti: Manuale, meno adatto per scripting su larga scala
• App mobile di Azure
  • Interfaccia: iOS/Android
  • Ideale per: Triage e azioni rapide
  • Punti di forza: Conferma degli avvisi, azioni di base sulle risorse, accesso in mobilità
  • Limiti: Profondità di configurazione limitata
• Cloud Shell
  • Interfaccia: Shell nel browser
  • Ideale per: Comandi ad-hoc senza configurazione locale
  • Punti di forza: Strumenti preinstallati, home persistente tramite Azure Files, contesto sicuro
  • Limiti: Container effimero; non adatto per processi batch a lunga esecuzione
• Azure CLI (az)
  • Interfaccia: Riga di comando
  • Ideale per: Scripting multipiattaforma e pipeline
  • Punti di forza: Sintassi coerente, output JSON, estensibilità
  • Limiti: Curva di apprendimento per grafi di risorse complessi
• Azure PowerShell (Az)
  • Interfaccia: Moduli PowerShell
  • Ideale per: Automazione su Windows/Linux/macOS; operazioni object-centric
  • Punti di forza: Ampia copertura di cmdlet, oggetti passabili in pipeline
  • Limiti: Footprint più pesante; richiede la gestione del ciclo di vita dei moduli

Automazione: runbook, gestione degli aggiornamenti e pianificazione delle VM ottimizzata per i costi

Azure Automation fornisce un servizio gestito di runbook per orchestrare le attività operative. I runbook possono essere creati in PowerShell, Python o come flussi di lavoro grafici, e possono essere attivati in base a pianificazioni, tramite webhook o da avvisi attraverso i gruppi di azioni (action groups). Gli account “Run-as” si sono evoluti verso le identità gestite (managed identities), che eliminano la gestione di certificati e segreti supportando al contempo un accesso granulare con privilegi minimi (least-privilege). Gli Hybrid Runbook Worker estendono l’automazione a reti private o a location edge, eseguendo i runbook su risorse on-premise o isolate pur rimanendo gestiti da Azure. La governance delle patch è gestita tramite Azure Update Manager, che unifica gli aggiornamenti del sistema operativo per Windows e Linux su tutte le VM di Azure e i server abilitati per Arc (Arc-enabled servers). Le configurazioni di manutenzione definiscono pianificazioni, comportamento al riavvio, script pre/post-esecuzione e ambiti dinamici utilizzando tag o query salvate. Il reporting di conformità evidenzia gli aggiornamenti mancanti e il successo delle distribuzioni, mentre le integrazioni con Azure Policy impongono le configurazioni di base. Update Manager sostituisce la soluzione legacy di Update Management in Azure Automation, fornendo scalabilità, granularità e supporto nativo per Arc migliorati. Per minimizzare la spesa di calcolo per i carichi di lavoro non attivi 24x7, Azure offre molteplici opzioni per arrestare e avviare le macchine virtuali secondo una pianificazione. La soluzione Start/Stop VMs v2 orchestra il targeting basato su tag, pianificazioni per orari di ufficio per fuso orario, rilevamento dell’inattività e notifiche opzionali, utilizzando Azure Automation e Azure Monitor come motori sottostanti. Anche le singole VM supportano policy di arresto automatico, e i Virtual Machine Scale Sets possono utilizzare regole di scalabilità automatica (autoscale) basate su metriche. La combinazione della scalabilità basata su metriche con l’arresto/avvio pianificato produce risparmi prevedibili senza sacrificare i livelli di servizio durante le finestre di domanda.

Operazioni ibride e cross-tenant: Azure Arc, Azure Lighthouse e Kusto cross-workspace

Azure Arc proietta le risorse non-Azure (server, cluster Kubernetes, istanze di SQL Server) in Azure Resource Manager in modo che possano essere taggate, associate a policy, monitorate e aggiornate come le risorse native. L’agente di Azure Monitor e le Data Collection Rules inviano la telemetria dalle macchine abilitate per Arc a una o più aree di lavoro Log Analytics, consentendo un’osservabilità centralizzata indipendentemente dalla loro posizione. Per Kubernetes, Arc integra GitOps con Flux per la gestione dichiarativa dei cluster e supporta estensioni per distribuire agenti per Defender for Cloud, lo scraping di Prometheus e l’applicazione delle policy. Azure Lighthouse abilita la gestione sicura e su larga scala delle risorse tra tenant di Microsoft Entra ID, ideale per i fornitori di servizi o i team di piattaforma centralizzati che supportano più unità di business. Le deleghe concedono un accesso minimo indispensabile (just-enough-access) tramite Azure RBAC a livello di sottoscrizione, gruppo di risorse o singola risorsa, mentre tutte le azioni vengono registrate nel tenant del cliente. Gli operatori possono interrogare i log, distribuire policy ed eseguire automazioni tra i tenant da un unico contesto, riducendo l’attrito durante l’accesso ed eliminando la proliferazione di credenziali cross-tenant. Kusto Query Language supporta l’analisi cross-resource e cross-region interrogando più aree di lavoro e risorse di Application Insights in una singola istruzione. I pattern comuni includono l’unione tra aree di lavoro e le join per correlare le tracce delle applicazioni con i log dell’infrastruttura. Esempio:

undefined

. Un altro esempio correla le richieste e le eccezioni tra due app:

undefined

. Con il routing multi-destinazione basato su DCR, i log provenienti da Arc e dalle risorse Azure possono essere inviati ad aree di lavoro regionali pur rimanendo interrogabili in modo aggregato, garantendo sia la residenza dei dati sia l’analisi globale.

Problema pratico: GlobalRetail Co. costruisce un centro nevralgico operativo per un ambiente ibrido

Scenario: GlobalRetail Co. gestisce servizi point-of-sale in 1.200 negozi, con data center regionali a Dublino e Singapore e una crescente presenza su Azure per carichi di lavoro web e di analisi. La direzione desidera una visione operativa unica, patching automatizzato e controllo dei costi per le VM di sviluppo, mentre un fornitore di servizi gestiti (MSP) esterno si occupa del supporto notturno per tutti gli ambienti.

Sfida: Unificare il monitoraggio e gli avvisi tra i server Azure e on-premise, implementare aggiornamenti automatici del sistema operativo con finestre di manutenzione, ridurre i costi delle VM in dev/test al di fuori dell’orario di lavoro e abilitare operazioni cross-tenant sicure per l’MSP senza condividere credenziali permanenti.

Approccio consigliato:

1. Distribuire Azure Arc su tutti i server on-premise Windows e Linux; abilitare l’agente di Azure Monitor tramite Data Collection Rules per inviare dati di piattaforma, syslog/Event e di performance alle aree di lavoro Log Analytics regionali.
2. Strumentare i carichi di lavoro web e API con Application Insights utilizzando OpenTelemetry; configurare test di disponibilità da più regioni e abilitare il campionamento adattivo e il rilevamento intelligente.
3. Creare avvisi in Azure Monitor basati su metriche, log e log attività per i segnali critici; centralizzare le notifiche con gruppi di azioni che attivano e-mail, messaggi su Teams tramite webhook e un connettore ITSM per aprire automaticamente gli incident.
4. Pubblicare Workbook operativi che combinano errori/latenza di App Insights, performance delle VM (InsightsMetrics) e log attività della piattaforma; aggiungere i grafici chiave a una dashboard di Azure a livello di organizzazione.
5. Implementare Azure Update Manager con configurazioni di manutenzione per regione e tipo di negozio; utilizzare pre-script per drenare il traffico e post-script per convalidare lo stato del servizio; imporre la conformità tramite assegnazioni di Azure Policy.
6. Implementare Start/Stop VMs v2 per le sottoscrizioni di dev/test utilizzando i tag environment=dev e environment=test; definire pianificazioni basate sull’orario di lavoro per fuso orario locale e abilitare l’arresto per inattività (idle-stop) per le finestre a basso utilizzo.
7. Integrare l’MSP tramite la delega di Azure Lighthouse a livello di management group con un ruolo personalizzato basato sul principio del privilegio minimo (least-privilege); richiedere l’elevazione dei privilegi just-in-time con PIM e limitare l’accesso ai runbook di emergenza (break-glass) strumentati con la registrazione delle attività.
8. Creare query KQL che uniscano le aree di lavoro di Dublino e Singapore per monitorare CPU, memoria e tassi di errore della flotta; pianificare avvisi basati su log per rilevare picchi e instradarli al gruppo di azioni dell’MSP al di fuori dell’orario di lavoro.
9. Configurare avvisi di Service Health e Resource Health per le regioni/servizi interessati; creare un’automazione per gli incident che pubblichi avvisi e link alla RCA (Root Cause Analysis) nel record dell’incident.

Logica di Azure: Azure Arc standardizza la governance e la telemetria per i server non-Azure, consentendo ad Azure Monitor di consolidare metriche e log tra le regioni. Application Insights fornisce visibilità end-to-end delle transazioni, permettendo ai team operativi di distinguere i guasti applicativi dai problemi infrastrutturali. I gruppi di azioni e l’integrazione ITSM garantiscono la creazione tempestiva e automatizzata degli incident, mentre i Workbook e le dashboard offrono un quadro operativo condiviso. Update Manager impone un’igiene di patching coerente all’interno delle finestre di manutenzione, e Start/Stop VMs v2 riduce la spesa di dev/test senza influire sulla produttività. Azure Lighthouse concede all’MSP un accesso sicuro, verificabile e con privilegi minimi tra i tenant, e il KQL cross-workspace unisce la telemetria globale per un rilevamento proattivo e una diagnosi rapida.

← Governance e Conformità · Tutti i domini · Supporto →

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

Sfoglia Microsoft →