Microsoft AZ-900: Supporto, Ciclo di Vita del Servizio e Marketplace — 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.

Le operazioni affidabili su Azure dipendono dalla scelta del modello di supporto corretto, dalla comprensione dei segnali sullo stato dei servizi, dalla progettazione in base ai service-level agreement (SLA) pubblicati e dall’approvvigionamento responsabile di soluzioni di terze parti tramite il marketplace commerciale. Questo dominio si concentra su come Microsoft supporta i carichi di lavoro cloud durante il loro intero ciclo di vita e su come i clienti rendono operativo tale supporto con la gestione dei casi, gli aumenti di quota, gli avvisi sullo stato dei servizi e la gestione degli incidenti. Altrettanto importante è la governance relativa al cambiamento continuo. I servizi Azure seguono un ciclo di vita moderno con aggiornamenti frequenti e sicuri e preavviso per le modifiche che potrebbero causare interruzioni (breaking changes). L’Azure Marketplace estende la piattaforma con soluzioni di partner convalidate, consentendo una rapida adozione di componenti di sicurezza, rete, dati e applicazioni sotto il controllo centralizzato della fatturazione e delle policy di Azure.

Piani di supporto Azure e gestione dei casi

Microsoft offre diversi piani di supporto Azure allineati alla criticità del carico di lavoro e al livello di consulenza richiesto. Il supporto Basic è incluso in ogni sottoscrizione e copre solo la gestione della fatturazione e della sottoscrizione. Il supporto Developer è rivolto ad ambienti non di produzione e fornisce guida tecnica durante l’orario lavorativo per problemi di gravità inferiore. Il supporto Standard è il punto di partenza per il supporto tecnico 24x7 ed è appropriato per la maggior parte dei carichi di lavoro di produzione. Il Professional Direct (ProDirect) aggiunge tempi di risposta più rapidi e l’accesso a consulenza proattiva, revisioni dell’architettura e seminari web per accelerare le implementazioni. Il Premier/Unified è un’offerta enterprise che copre i prodotti Microsoft cloud e on-premise, associando la vostra organizzazione a un Customer Success Account Manager e a servizi proattivi come revisioni del servizio, workshop, pianificazione della preparazione (readiness) e coordinamento della gestione degli incidenti. Le richieste di supporto vengono create nel portale di Azure in Help + support. I tipi di caso includono tecnico, fatturazione, gestione della sottoscrizione e limiti di servizio e sottoscrizione (quote). I casi tecnici richiedono un piano a pagamento (Developer, Standard, ProDirect o Unified). Il ruolo predefinito Support Request Contributor consente agli utenti di aprire e gestire i casi senza concedere autorizzazioni più ampie sulle risorse, mentre anche i ruoli Owner e Contributor possono aprire casi. I casi possono essere integrati con strumenti ITSM tramite i gruppi di azioni di Azure Monitor e il connettore ITSM per mantenere una singola coda di incidenti.

• Basic
  • Disponibilità supporto tecnico: No (solo fatturazione/sottoscrizione)
  • Tempi di risposta iniziale (Sev A/B/C): N/D
  • Consulenza: Solo documentazione, community
  • Servizi proattivi: Nessuno
  • Uso tipico: Versioni di prova, apprendimento, account non critici
• Developer
  • Disponibilità supporto tecnico: Orario lavorativo (email/web)
  • Tempi di risposta iniziale (Sev A/B/C): N/D / N/D / < 8 ore
  • Consulenza: Guida generale su procedure (how-to)
  • Servizi proattivi: Nessuno
  • Uso tipico: Sviluppo/test e progetti pilota
• Standard
  • Disponibilità supporto tecnico: 24x7 per Sev A; orario lavorativo per gravità inferiori
  • Tempi di risposta iniziale (Sev A/B/C): < 1 ora / < 4 ore / < 8 ore
  • Consulenza: Guida best-effort con i casi
  • Servizi proattivi: Nessuno
  • Uso tipico: Carichi di lavoro di produzione con esigenze di risposta standard
• Professional Direct
  • Disponibilità supporto tecnico: 24x7 per Sev A
  • Tempi di risposta iniziale (Sev A/B/C): < 1 ora / < 2 ore / < 4 ore
  • Consulenza: Consulenza proattiva, revisioni dell’architettura, onboarding
  • Servizi proattivi: Webinar, revisioni del servizio, gestione delle escalation
  • Uso tipico: Produzione business-critical che necessita di risposte e guida più rapide
• Premier/Unified
  • Disponibilità supporto tecnico: 24x7 (ampio ambito Microsoft)
  • Tempi di risposta iniziale (Sev A/B/C): < 1 ora / < 2 ore / < 4 ore
  • Consulenza: CSAM dedicato, guida a livello di soluzione
  • Servizi proattivi: Workshop, valutazioni, revisioni del servizio, coordinamento degli incidenti
  • Uso tipico: Portafogli enterprise che coprono più prodotti

Creazione di richieste di supporto e aumento di quote e limiti

Le richieste di supporto si creano nel portale di Azure in Help + support > Create a support request. Il flusso di lavoro richiede il tipo di problema, la sottoscrizione, il servizio, la risorsa, la regione e la gravità. Per i casi tecnici si seleziona un livello di impatto (gravità) in linea con l’impatto sul business e con i tempi di risposta del proprio piano. Includere dati diagnostici (timestamp, ID di correlazione, metriche e cronologia delle modifiche) per accelerare il triage. Per la gestione della fatturazione e della sottoscrizione, il supporto Basic è sufficiente; per problemi tecnici, è richiesto un piano a pagamento. Gli aumenti di quota e limiti vengono richiesti come Service and subscription limits (quotas). Le richieste comuni includono quote di vCPU di calcolo per regione (per famiglia di VM), indirizzi IP pubblici, core per famiglie specializzate GPU o HPC e quote di Azure Machine Learning o Cognitive Services. Le quote di calcolo sono applicate per sottoscrizione, per regione e per famiglia di serie di VM; richiedere una quota più alta abilita le richieste di capacità, ma non garantisce la disponibilità della capacità. Per una capacità prevedibile, combinare gli aumenti di quota con le prenotazioni di capacità on-demand o pianificare implementazioni zonali, ove appropriato. L’accesso per l’invio delle richieste è controllato tramite Azure RBAC. Il ruolo Support Request Contributor può creare e gestire i ticket senza concedere diritti di modifica delle risorse. Le organizzazioni più grandi spesso instradano i flussi di lavoro per le quote attraverso approvazioni interne e li tracciano in ITSM; l’API Azure Quota può automatizzare il monitoraggio e l’invio di richieste a soglie predefinite. Dopo l’invio, i casi vengono smistati (triage) al team di ingegneria quando necessario e le comunicazioni avvengono tramite il portale, email e, facoltativamente, telefono per le gravità più elevate.

Integrità del servizio, manutenzione pianificata e SLA nella gestione degli incidenti

Azure fornisce diverse prospettive sullo stato di integrità. Azure Status è la vista pubblica e globale dei problemi a livello di piattaforma. Azure Service Health è personalizzato per le tue sottoscrizioni e mostra problemi di servizio, manutenzione pianificata e avvisi di integrità che interessano le tue region e le tue risorse. Resource Health analizza in dettaglio lo stato delle singole risorse, fornendo eventi di disponibilità recenti e le cause principali, come eventi della piattaforma, azioni avviate dall’utente o guasti hardware sottostanti. Gli avvisi di Service Health si integrano con i gruppi di azioni per e-mail, SMS, chiamate vocali, webhook, connettori ITSM e Azure Functions. La manutenzione pianificata viene comunicata tramite Service Health, con le finestre temporali previste e i dettagli sull’impatto. Per le macchine virtuali, Azure Scheduled Events espone notifiche all’interno del sistema operativo guest (tramite il servizio di metadati dell’istanza) relative ad azioni imminenti come i riavvii, consentendo alle applicazioni di eseguire il drain delle connessioni, creare checkpoint o effettuare il failover. Maintenance Control è disponibile per Azure Dedicated Hosts e per alcune dimensioni di VM isolate, consentendo agli amministratori di posticipare la manutenzione della piattaforma entro una finestra di rinvio definita, per allinearla ai processi di change control. Gli SLA definiscono gli obiettivi mensili di uptime o di successo delle transazioni per ogni servizio. Quando si progetta un’architettura con soluzioni multi-servizio, la disponibilità combinata è il prodotto delle disponibilità delle singole dipendenze. I livelli di disponibilità più elevati richiedono in genere implementazioni con ridondanza di zona o multi-istanza. Ad esempio, l’esecuzione di macchine virtuali su due o più zone di disponibilità in una region consente di ottenere uno SLA più elevato rispetto a una singola VM o a un set di disponibilità. Se uno SLA non viene rispettato, sono disponibili crediti di servizio su richiesta; la richiesta va inviata tramite il portale con le prove necessarie (timestamp, risorse interessate) entro la finestra temporale richiesta, e l’incidente e le analisi post-incidente possono essere monitorati in Service Health.

• Macchine virtuali (istanza singola)
  • Requisito chiave per lo SLA: Premium SSD o Ultra Disk per sistema operativo e dati
  • SLA pubblicato (tipico): 99,9%
  • Note: Si applica a dimensioni e storage idonei; nessun set/zona di disponibilità
• Macchine virtuali in un set di disponibilità
  • Requisito chiave per lo SLA: Due o più istanze distribuite tra domini di errore/aggiornamento
  • SLA pubblicato (tipico): 99,95%
  • Note: Riduce il rischio legato a un singolo rack e a un singolo dominio di aggiornamento
• Macchine virtuali distribuite tra zone di disponibilità
  • Requisito chiave per lo SLA: Due o più istanze distribuite tra zone in una singola region
  • SLA pubblicato (tipico): 99,99%
  • Note: La migliore resilienza a livello di region senza failover tra region diverse
• Azure SQL Database (database singolo)
  • Requisito chiave per lo SLA: Implementazione Standard
  • SLA pubblicato (tipico): 99,99%
  • Note: La ridondanza di zona può migliorare la resilienza ai guasti a livello di zona
• App Service (multi-istanza)
  • Requisito chiave per lo SLA: Due o più istanze
  • SLA pubblicato (tipico): 99,95%
  • Note: Richiede i livelli di servizio Basic o superiori con più istanze

Modern Lifecycle Policy e Azure Marketplace

I servizi Azure seguono la Modern Lifecycle Policy, che enfatizza gli aggiornamenti continui del servizio e la responsabilità del cliente di mantenersi aggiornato. Le breaking change che richiedono un’azione da parte del cliente vengono comunicate con un preavviso—tipicamente di almeno 12 mesi per i servizi online—tramite annunci formali di deprecazione, avvisi di Service Health e aggiornamenti della documentazione. Vengono fornite tempistiche di ritiro, versioning delle API e percorsi di migrazione, in modo che i carichi di lavoro possano essere adeguati entro finestre di modifica che si allineano alla governance aziendale. Questo modello di continuous delivery sfrutta pratiche di implementazione sicure con rollout graduali e mitigazione automatica. La prontezza operativa (operational readiness) implica il monitoraggio degli avvisi di servizio, la convalida di nuove versioni di runtime o SDK in pre-produzione e l’utilizzo di feature flag o pattern blue-green per gli aggiornamenti delle applicazioni. Gli aggiornamenti di sicurezza e conformità arrivano senza cicli di installazione separati, riducendo le finestre di esposizione e ponendo l’accento sull’osservabilità e sulla disciplina di rilascio. L’Azure Marketplace estende la piattaforma con soluzioni di terze parti: immagini di macchine virtuali, applicazioni gestite, applicazioni Kubernetes e offerte SaaS. Le offerte vengono fatturate tramite la sottoscrizione Azure con opzioni come la misurazione pay-as-you-go, piani annuali/a termine e bring-your-own-license (BYOL). Le aziende possono curare un marketplace privato per consentire solo editori o offerte approvate, applicare Azure Policy per limitare l’impronta di deployment (region, SKU, networking) e negoziare prezzi personalizzati tramite offerte private. Le appliance virtuali di rete (ad es. firewall, load balancer), le piattaforme dati, l’analisi della sicurezza e gli stack di osservabilità sono pattern comuni; il supporto dell’editore è il canale principale per queste soluzioni, con la fatturazione consolidata in Azure.

• Immagine di macchina virtuale (NVA o server)
  • Modello di deployment: Template ARM/VM nel tuo VNet
  • Modello di fatturazione: PAYG o BYOL
  • Casi d’uso di esempio: Firewall, WAF, IDS/IPS, app pacchettizzate
  • Note operative: Gestisci il ciclo di vita, il dimensionamento e il patching della VM
• Applicazione gestita
  • Modello di deployment: Distribuita nella tua sottoscrizione, gestita dall’editore
  • Modello di fatturazione: PAYG più una tariffa di gestione
  • Casi d’uso di esempio: Soluzioni “chiavi in mano” con operazioni gestite
  • Note operative: L’editore aggiorna i componenti principali; tu gestisci dati/configurazione
• App Kubernetes (add-on per AKS)
  • Modello di deployment: Helm/ARM nel tuo cluster AKS
  • Modello di fatturazione: PAYG o BYOL
  • Casi d’uso di esempio: Ingress controller, service mesh, operator
  • Note operative: Tu gestisci AKS; l’editore mantiene le immagini dei container dell’app
• SaaS
  • Modello di deployment: Eseguita nel tenant dell’editore; si integra con il tuo tenant
  • Modello di fatturazione: Sottoscrizione/consumo
  • Casi d’uso di esempio: API, piattaforme di analisi, SaaS di sicurezza
  • Note operative: Time-to-value più rapido; infrastruttura minima da gestire

Problema pratico: Coastal Outfitters: Operazionalizzazione di soluzioni di supporto, integrità e marketplace per un picco stagionale di e‑commerce

Scenario: Coastal Outfitters gestisce un sito di e-commerce ospitato su Azure con un traffico stabile per la maggior parte del mese e un picco di quattro giorni a fine mese. L’architettura utilizza Azure Application Gateway, due web tier basati su VM e un database gestito. I requisiti di sicurezza prevedono un firewall di nuova generazione e il team operativo deve garantire una disponibilità del 99,99% per il web tier durante i periodi di picco, ricevendo al contempo una guida proattiva durante il rollout.

Sfida: Scegliere il piano di supporto adeguato per ottenere una consulenza architetturale proattiva, implementare un firewall dal marketplace nel rispetto della governance, aumentare le quote di calcolo regionali prima del picco e implementare avvisi sullo stato di integrità e flussi di lavoro per gli incidenti in linea con gli obiettivi di disponibilità del 99,99%.

Approccio consigliato:

1. Eseguire l’upgrade della sottoscrizione al piano di supporto Professional Direct per assicurarsi una risposta 24x7 per problemi critici e una consulenza proattiva per il rollout in produzione.
2. Assegnare il ruolo predefinito (built‑in) di Support Request Contributor al gruppo NOC, in modo che possano aprire e gestire i ticket senza disporre di autorizzazioni estese sulle risorse.
3. Implementare un firewall di nuova generazione Palo Alto Networks o Fortinet da Azure Marketplace in una VNet hub dedicata; sfruttare un marketplace privato in modo che solo le offerte private approvate e negoziate siano visibili ai proprietari della sottoscrizione.
4. Collocare due o più VM web in zone di disponibilità separate dietro l’Application Gateway per soddisfare lo SLA del 99,99% per le VM; archiviare il sistema operativo e i dati su dischi Premium SSD.
5. Inviare una richiesta di aumento dei limiti di servizio e sottoscrizione (quote) due settimane prima del picco per aumentare le quote di vCPU per regione per le famiglie di VM richieste; aggiungere prenotazioni di capacità per il web tier per garantire la capacità di burst.
6. Configurare gli avvisi di Azure Service Health per problemi di servizio, manutenzione pianificata e avvisi sullo stato di integrità nelle regioni in cui si trova il sito; instradare gli avvisi a un gruppo di azioni che notifichi il personale reperibile tramite e-mail/SMS e apra un incident in ServiceNow tramite il connettore ITSM.
7. Abilitare la gestione degli Azure Scheduled Events sulle VM web per drenare gradualmente le connessioni durante la manutenzione dell’host; convalidare il comportamento di failover in ambiente di staging utilizzando scambi blue‑green.
8. Documentare nel runbook il flusso di lavoro per la richiesta di crediti SLA, includendo l’acquisizione delle prove (timestamp, ID delle risorse, metriche), e assicurarsi che le richieste vengano inviate tramite il portale entro la finestra temporale consentita qualora gli obiettivi di disponibilità non vengano raggiunti.

Logica di Azure: Il piano Professional Direct combina una risposta rapida con i vantaggi di una consulenza proattiva senza l’onere di un contratto Unified a livello aziendale, allineandosi a un singolo carico di lavoro di produzione critico. Le VM distribuite in zone di disponibilità (Zonal VM) aumentano il livello di disponibilità al 99,99% con un numero minimo di istanze, mentre i dischi Premium SSD soddisfano i requisiti di storage per le singole istanze. Un marketplace privato curato e offerte private negoziate mantengono gli appliance di sicurezza conformi e con costi controllati, e il supporto del publisher rimane la prima linea di difesa per i problemi relativi alle NVA. L’aumento anticipato delle quote e le prenotazioni di capacità eliminano gli attriti (“friction”) nell’implementazione durante il picco. Gli avvisi di Service Health, la gestione degli eventi pianificati e un runbook per le richieste di crediti SLA completano il ciclo di gestione degli incidenti con responsabilità chiare e percorsi definiti per la raccolta delle prove.

← Monitoraggio · Tutti i domini

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

Sfoglia Microsoft →