Microsoft AZ-900: Suporte, Ciclo de Vida do Serviço e Marketplace — Guia de estudos

By Laurynas Brazys · 23 July 2026 · #microsoft #az-900 #certification #exam-prep #study-guide

Faz parte do Microsoft Azure AZ-900 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Microsoft, ou faça testes cronometrados no ExamRoll.io.

Operações confiáveis no Azure dependem da escolha do modelo de suporte correto, da compreensão dos sinais de integridade do serviço, do design alinhado aos contratos de nível de serviço (SLAs) publicados e da aquisição responsável de soluções de terceiros por meio do marketplace comercial. Este domínio foca em como a Microsoft oferece suporte a workloads de nuvem ao longo de seu ciclo de vida e como os clientes operacionalizam esse suporte com gerenciamento de chamados, aumentos de cota, alertas de integridade e tratamento de incidentes. Igualmente importante é a governança em torno de mudanças contínuas. Os serviços do Azure seguem um ciclo de vida moderno com atualizações frequentes e seguras e aviso prévio para alterações interruptivas. O Azure Marketplace estende a plataforma com soluções de parceiros validadas, permitindo a adoção rápida de componentes de segurança, rede, dados e aplicativos sob o faturamento consolidado e o controle de políticas do Azure.

Planos de suporte e gerenciamento de chamados do Azure

A Microsoft oferece vários planos de suporte do Azure alinhados à criticidade do workload e ao nível de orientação consultiva necessário. O suporte Básico está incluído em todas as assinaturas e cobre apenas o gerenciamento de faturamento e assinaturas. O suporte para Desenvolvedores visa ambientes de não produção e fornece orientação técnica durante o horário comercial para problemas de menor severidade. O suporte Padrão é o ponto de entrada para suporte técnico 24x7 e é apropriado para a maioria dos workloads de produção. O Professional Direct (ProDirect) adiciona metas de resposta mais rápidas e acesso a orientação consultiva proativa, revisões de arquitetura e webinars para acelerar as implantações. O Premier/Unified é um guarda-chuva empresarial que abrange os produtos de nuvem e on-premises da Microsoft, designando um Gerente de Conta de Sucesso do Cliente (Customer Success Account Manager) para sua organização e oferecendo serviços proativos como revisões de serviço, workshops, planejamento de prontidão e coordenação de gerenciamento de incidentes. As solicitações de suporte são criadas no portal do Azure em Ajuda + suporte. Os tipos de chamado incluem técnico, faturamento, gerenciamento de assinatura e limites de serviço e assinatura (cotas). Os chamados técnicos exigem um plano pago (Desenvolvedor, Padrão, ProDirect ou Unified). A função interna de Colaborador de Solicitação de Suporte (Support Request Contributor) permite que os usuários abram e gerenciem chamados sem conceder permissões mais amplas de recursos, enquanto Proprietários (Owners) e Colaboradores (Contributors) também podem abrir chamados. Os chamados podem ser integrados a ferramentas de ITSM por meio de grupos de ação do Azure Monitor e do conector de ITSM para manter uma fila única de incidentes.

• Básico
  • Disponibilidade de suporte técnico: Não (apenas faturamento/assinatura)
  • Metas de resposta inicial (Sev A/B/C): N/A
  • Orientação consultiva: Apenas documentação, comunidade
  • Serviços proativos: Nenhum
  • Uso típico: Avaliações, aprendizado, contas não críticas
• Desenvolvedor
  • Disponibilidade de suporte técnico: Horário comercial (e-mail/web)
  • Metas de resposta inicial (Sev A/B/C): N/A / N/A / < 8 horas
  • Orientação consultiva: Orientação geral de “como fazer”
  • Serviços proativos: Nenhum
  • Uso típico: Dev/teste e pilotos
• Padrão
  • Disponibilidade de suporte técnico: 24x7 para Sev A; horário comercial para severidade menor
  • Metas de resposta inicial (Sev A/B/C): < 1 h / < 4 h / < 8 h
  • Orientação consultiva: Orientação de melhor esforço com os chamados
  • Serviços proativos: Nenhum
  • Uso típico: Workloads de produção com necessidades de resposta padrão
• Professional Direct
  • Disponibilidade de suporte técnico: 24x7 para Sev A
  • Metas de resposta inicial (Sev A/B/C): < 1 h / < 2 h / < 4 h
  • Orientação consultiva: Consultoria proativa, revisões de arquitetura, onboarding
  • Serviços proativos: Webinars, revisões de serviço, gerenciamento de escalonamento
  • Uso típico: Produção de missão crítica que necessita de resposta e orientação mais rápidas
• Premier/Unified
  • Disponibilidade de suporte técnico: 24x7 (escopo amplo da Microsoft)
  • Metas de resposta inicial (Sev A/B/C): < 1 h / < 2 h / < 4 h
  • Orientação consultiva: CSAM designado, orientação no nível da solução
  • Serviços proativos: Workshops, avaliações, revisões de serviço, coordenação de incidentes
  • Uso típico: Portfólios empresariais que abrangem múltiplos produtos

Criando solicitações de suporte e aumentando cotas e limites

As solicitações de suporte se originam no portal do Azure em Ajuda + suporte > Criar uma solicitação de suporte. O fluxo de trabalho solicita o tipo de problema, assinatura, serviço, recurso, região e severidade. Para chamados técnicos, você seleciona um nível de impacto (severidade) que se alinha ao impacto nos negócios e às metas de resposta do seu plano. Inclua diagnósticos (timestamps, IDs de correlação, métricas e histórico de alterações) para acelerar a triagem. Para gerenciamento de faturamento e assinatura, o suporte Básico é suficiente; para problemas técnicos, é necessário um plano pago. Aumentos de cota e limite são solicitados como Limites de serviço e assinatura (cotas). As solicitações comuns incluem cotas de vCPU de computação por região (por família de VM), endereços IP públicos, núcleos para famílias especializadas de GPU ou HPC e cotas do Azure Machine Learning ou Cognitive Services. As cotas de computação são aplicadas por assinatura, por região e por família de série de VM; solicitar uma cota maior habilita solicitações de capacidade, mas não garante a disponibilidade da capacidade. Para capacidade previsível, combine aumentos de cota com reservas de capacidade sob demanda ou planeje implantações zonais quando apropriado. O acesso para abrir solicitações é controlado através do Azure RBAC. A função de Colaborador de Solicitação de Suporte (Support Request Contributor) pode criar e gerenciar chamados sem conceder direitos de modificação de recursos. Organizações maiores geralmente roteiam os fluxos de trabalho de cota por meio de aprovação interna e os rastreiam em ITSM; a API de Cota do Azure (Azure Quota API) pode automatizar o monitoramento e a abertura de solicitações em limites predefinidos. Após o envio, os chamados são encaminhados para a engenharia quando necessário, e as comunicações ocorrem através do portal, por e-mail e, opcionalmente, por telefone para severidades mais altas.

Saúde do Serviço, manutenção planejada e SLAs no gerenciamento de incidentes

O Azure oferece múltiplas perspectivas de saúde (health lenses). O Azure Status é a visão pública e global de problemas que afetam toda a plataforma. O Azure Service Health é personalizado para suas assinaturas, exibindo problemas de serviço, manutenções planejadas e avisos de saúde (health advisories) que afetam suas regiões e recursos. O Resource Health detalha o estado de recursos individuais, fornecendo eventos de disponibilidade recentes e suas causas raiz, como eventos da plataforma, ações iniciadas pelo usuário ou falhas de hardware subjacente. Os alertas do Service Health se integram com grupos de ação (action groups) para e-mail, SMS, voz, webhooks, conectores ITSM e Azure Functions. A manutenção planejada é comunicada através do Service Health com as janelas esperadas e detalhes do impacto. Para máquinas virtuais, o Azure Scheduled Events expõe notificações dentro do sistema operacional convidado (in-guest), através do serviço de metadados da instância, sobre ações futuras como reinicializações, permitindo que as aplicações façam o esvaziamento de conexões (drain), criem pontos de verificação (checkpoint) ou executem failover. O Maintenance Control está disponível para Azure Dedicated Hosts e certos tamanhos de VM isoladas, permitindo que os administradores adiem a manutenção da plataforma dentro de uma janela de adiamento definida para se alinhar com os processos de controle de mudanças. Os SLAs definem as metas mensais de tempo de atividade (uptime) ou de sucesso de transações para cada serviço. Ao arquitetar soluções com múltiplos serviços, a disponibilidade combinada é multiplicativa entre as dependências. Níveis de disponibilidade mais altos geralmente exigem implantações com redundância de zona ou com múltiplas instâncias. Por exemplo, executar máquinas virtuais em duas ou mais zonas de disponibilidade em uma região alcança um SLA maior do que uma única VM ou um conjunto de disponibilidade (availability set). Se um SLA não for cumprido, créditos de serviço estão disponíveis mediante solicitação; envie a solicitação pelo portal com as evidências (timestamps, recursos afetados) dentro do prazo exigido e acompanhe o incidente e as análises pós-incidente no Service Health.

• Máquinas Virtuais (instância única)
  • Requisito principal para o SLA: Premium SSD ou Ultra Disk para o SO e dados
  • SLA publicado (típico): 99,9%
  • Observações: Aplica-se a tamanhos e armazenamentos elegíveis; sem conjunto de disponibilidade/zona
• Máquinas Virtuais em um Conjunto de Disponibilidade (Availability Set)
  • Requisito principal para o SLA: Duas ou mais instâncias distribuídas entre domínios de falha/atualização
  • SLA publicado (típico): 99,95%
  • Observações: Reduz o risco de um único rack e de domínio de atualização
• Máquinas Virtuais entre Zonas de Disponibilidade
  • Requisito principal para o SLA: Duas ou mais instâncias distribuídas entre zonas em uma região
  • SLA publicado (típico): 99,99%
  • Observações: Melhor resiliência regional sem failover entre regiões
• Azure SQL Database (banco de dados único)
  • Requisito principal para o SLA: Implantação padrão (Standard)
  • SLA publicado (típico): 99,99%
  • Observações: A redundância de zona pode melhorar a resiliência a falhas zonais
• App Service (múltiplas instâncias)
  • Requisito principal para o SLA: Duas ou mais instâncias
  • SLA publicado (típico): 99,95%
  • Observações: Requer os tiers Basic ou superiores com múltiplas instâncias

Política de Ciclo de Vida Moderno e o Azure Marketplace

Os serviços do Azure seguem a Política de Ciclo de Vida Moderno (Modern Lifecycle Policy), que enfatiza atualizações contínuas de serviço e a responsabilidade do cliente de se manter atualizado. Alterações que quebram a compatibilidade (breaking changes) e exigem ação do cliente são comunicadas com antecedência — geralmente pelo menos 12 meses para serviços online — por meio de anúncios formais de descontinuação (deprecation), avisos no Service Health e atualizações na documentação. Cronogramas de desativação (retirement), versionamento de APIs e caminhos de migração são fornecidos para que as cargas de trabalho (workloads) possam ser corrigidas dentro de janelas de mudança que se alinham à governança corporativa. Este modelo de entrega contínua utiliza práticas de implantação seguras com lançamentos em fases (staged rollouts) e mitigação automática. Prontidão operacional significa acompanhar os avisos de serviço, validar novas versões de runtime ou SDK em pré-produção e usar feature flags ou padrões blue-green para atualizações de aplicações. Atualizações de segurança e conformidade chegam sem ciclos de instalação separados, reduzindo as janelas de exposição e, ao mesmo tempo, colocando ênfase na observabilidade e na disciplina de lançamento. O Azure Marketplace estende a plataforma com soluções de terceiros: imagens de máquina virtual, aplicações gerenciadas (managed applications), aplicações Kubernetes e ofertas de SaaS. As ofertas são cobradas através da sua assinatura do Azure com opções como medição pay-as-you-go, planos anuais/por período e bring-your-own-license (BYOL). As empresas podem criar um marketplace privado para permitir apenas publicadores ou ofertas aprovadas, aplicar o Azure Policy para restringir a pegada (footprint) da implantação (regiões, SKUs, rede) e negociar preços personalizados por meio de ofertas privadas (private offers). Network virtual appliances (NVAs, por exemplo, firewalls, load balancers), plataformas de dados, análise de segurança e pilhas de observabilidade são padrões comuns; o suporte do publicador é o canal principal para essas soluções, com o faturamento consolidado no Azure.

• Imagem de máquina virtual (NVA ou servidor)
  • Modelo de implantação: Template ARM/VM em sua VNet
  • Modelo de faturamento: PAYG ou BYOL
  • Casos de uso de exemplo: Firewalls, WAFs, IDS/IPS, aplicações empacotadas
  • Observações operacionais: Você gerencia o ciclo de vida, o escalonamento e a aplicação de patches da VM
• Aplicação Gerenciada (Managed Application)
  • Modelo de implantação: Implantado em sua assinatura, gerenciado pelo publicador
  • Modelo de faturamento: PAYG mais taxa de gerenciamento
  • Casos de uso de exemplo: Soluções prontas para uso (turnkey) com operações gerenciadas
  • Observações operacionais: O publicador atualiza os componentes principais; você gerencia os dados/configuração
• Aplicação Kubernetes (add-on do AKS)
  • Modelo de implantação: Helm/ARM em seu cluster AKS
  • Modelo de faturamento: PAYG ou BYOL
  • Casos de uso de exemplo: Ingress controllers, service meshes, operators
  • Observações operacionais: Você gerencia o AKS; o publicador mantém as imagens de contêiner da aplicação
• SaaS
  • Modelo de implantação: Executa no tenant do publicador; integra-se com o seu tenant
  • Modelo de faturamento: Assinatura/consumo
  • Casos de uso de exemplo: APIs, plataformas de análise, SaaS de segurança
  • Observações operacionais: Tempo de agregação de valor (time-to-value) mais rápido; infraestrutura mínima para gerenciar

Problema Prático: Coastal Outfitters: Operacionalizando soluções de suporte, integridade e marketplace para um pico sazonal de e‑commerce

Cenário: A Coastal Outfitters opera um site de e-commerce hospedado no Azure com tráfego constante na maior parte do mês e um pico de quatro dias no final do mês. A arquitetura usa o Azure Application Gateway, duas camadas web baseadas em VM e um banco de dados gerenciado. A segurança exige um firewall de última geração, e as operações devem garantir 99,99% de disponibilidade para a camada web durante os períodos de pico, além de receber orientação proativa durante a implementação.

Desafio: Escolher o plano de suporte correto para orientação proativa de arquitetura, implantar um firewall do marketplace sob governança, aumentar as cotas de computação regionais antes do pico e implementar alertas de integridade e fluxos de trabalho de incidentes que se alinhem às metas de 99,99% de disponibilidade.

Abordagem Recomendada:

1. Fazer o upgrade da assinatura para o plano de suporte Professional Direct para garantir resposta crítica 24x7 e orientação consultiva proativa para a implementação em produção.
2. Atribuir a função interna Support Request Contributor ao grupo do NOC para que possam abrir e gerenciar tíquetes sem permissões amplas de recursos.
3. Implantar um firewall de última geração da Palo Alto Networks ou Fortinet a partir do Azure Marketplace em uma VNet de hub dedicada; utilizar um marketplace privado para que apenas ofertas privadas aprovadas e negociadas sejam visíveis para os proprietários da assinatura.
4. Alocar duas ou mais VMs da web em zonas de disponibilidade separadas atrás do Application Gateway para atender ao SLA de 99,99% para VMs; armazenar o SO/dados em Premium SSDs.
5. Abrir uma solicitação de Limites de serviço e assinatura (cotas) duas semanas antes do pico para aumentar as cotas de vCPU por região para as famílias de VM necessárias; adicionar reservas de capacidade para a camada web para garantir a capacidade de pico (burst).
6. Configurar alertas do Azure Service Health para problemas de serviço, manutenções planejadas e avisos de integridade nas regiões do site; rotear os alertas para um grupo de ações que notifica a equipe de plantão por e-mail/SMS e abre um incidente no ServiceNow através do conector ITSM.
7. Habilitar o tratamento de Azure Scheduled Events nas VMs da web para drenar conexões de forma gradual durante a manutenção do host; validar o comportamento de failover em homologação (staging) usando trocas blue-green.
8. Documentar o fluxo de trabalho de solicitação de crédito de SLA no runbook, incluindo a captura de evidências (timestamps, IDs de recursos, métricas), e garantir que as solicitações sejam enviadas pelo portal dentro do prazo permitido se as metas de disponibilidade não forem atingidas.

Justificativa do Azure: O plano Professional Direct combina resposta rápida com benefícios de consultoria proativa sem a sobrecarga de um contrato Unified para toda a empresa, alinhando-se a uma única carga de trabalho crítica de produção. VMs zonais elevam o nível de disponibilidade para 99,99% com uma contagem mínima de instâncias, enquanto os Premium SSDs atendem aos requisitos de armazenamento para instâncias únicas. Um marketplace privado com curadoria e ofertas privadas negociadas mantêm os dispositivos de segurança (security appliances) em conformidade e com custos controlados, e o suporte do fornecedor (publisher) continua sendo a primeira linha para problemas de NVA. Aumentos antecipados de cota e reservas de capacidade eliminam o atrito na implantação durante o pico. Alertas do Service Health, tratamento de eventos agendados e um runbook de solicitação de SLA completam o ciclo de gerenciamento de incidentes com responsabilidades claras e caminhos de evidência.

← Monitoramento · Todos os domínios

Pratique estas questões → · Prática cronometrada no ExamRoll.io →

Navegar Microsoft →