[AZ-104] Grand Labs - Nexora Logistics S.A.

Ambiente Cumulativo de Implantação Real

---

1. O Cenário (Narrativa Central)

A Empresa: Nexora Logistics S.A.

A Nexora Logistics S.A. é uma operadora de logística multimodal com sede em São Paulo, Brasil, atuando nos segmentos de carga fracionada, armazenagem bonded e rastreamento em tempo real de frotas. A empresa conta com 3.200 colaboradores distribuídos entre Brasil, Estados Unidos e México, e opera 14 centros de distribuição, dos quais 3 são regulados pela Receita Federal como Recintos Alfandegados.

Após uma fusão com a TransRoute Inc. (empresa norte-americana), a Nexora herdou uma infraestrutura on-premises fragmentada: dois domínios Active Directory sem trust configurado, servidores físicos com Windows Server 2012 (fora de suporte), e uma política de segurança inexistente para workloads em nuvem. O board aprovou um projeto de migração e modernização total para Azure com prazo de 18 meses.

O Projeto: Nexora Cloud Foundation

Você é o Azure Administrator responsável por construir a fundação da infraestrutura Azure da Nexora, do zero, cobrindo identidade, governança, rede, storage, compute, monitoramento e recuperação de desastres. Cada decisão técnica neste laboratório reflete um requisito de negócio real da empresa.

Convenção de Nomenclatura Obrigatória

Todos os recursos devem seguir estritamente o padrão abaixo. Desvios invalidam os critérios de sucesso.

{prefixo}-{tipo}-{ambiente}-{regiao}-{sequencial}

Campo	Valores Permitidos
prefixo	nxr (Nexora)
tipo	Abreviação do tipo de recurso Azure (ex: rg, vnet, vm, sa, kv)
ambiente	prd (produção), dev (desenvolvimento), shared (compartilhado)
regiao	use (East US), brs (Brazil South)
sequencial	Número de dois dígitos: 01, 02

Exemplos válidos: nxr-rg-shared-use-01, nxr-vnet-prd-brs-01, nxr-vm-prd-use-01

---

2. Ponto de Partida (Ambiente Inicial)

Recursos Pré-existentes

Recurso	Especificação	Observação
Subscription Azure	Pay-As-You-Go ou Visual Studio Enterprise	Permissão de Owner obrigatória
Microsoft Entra ID Tenant	Tenant dedicado, domínio .onmicrosoft.com	Sem domínio personalizado verificado
Conta de cobrança	Associada à subscription acima	Sem budget configurado
Workstation local	Windows 11 ou Ubuntu 22.04	Acesso à internet liberado

Credenciais Base

Identidade	Tipo	Papel Inicial	Observação
lab-admin@<tenant>.onmicrosoft.com	Conta Microsoft Entra	Global Administrator	Usada para bootstrap do ambiente
Conta pessoal do aluno	Conta Microsoft Entra	Nenhum (a ser atribuído)	Será usada para testes de RBAC

Ferramentas Necessárias

Ferramenta	Versão Mínima	Finalidade
Azure CLI	2.60.0	Provisionamento e automação
Azure PowerShell (Az module)	11.0.0	Tarefas administrativas e scripts
Bicep CLI	0.26.0	Implantação de IaC
Azure Storage Explorer	1.34.0	Gerenciamento visual de blobs e filas
AzCopy	10.24.0	Transferência de dados em larga escala
Git	2.44.0	Controle de versão dos templates IaC
Visual Studio Code	1.88.0	Edição de Bicep e ARM Templates
Bicep extension (VS Code)	0.26.0	Validação e IntelliSense para Bicep

Diagrama de Topologia Inicial (Estado Legado)

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

---

3. As Etapas do Laboratório

---

Etapa 1: Manage Microsoft Entra Users and Groups

Contexto de Negócios: O time de RH da Nexora identificou que a fusão com a TransRoute criou três perfis de colaboradores que precisam de acesso imediato ao ambiente Azure: administradores de TI do Brasil, engenheiros de infraestrutura dos EUA e parceiros externos da transportadora Rapido Frete Ltda., que necessitam de acesso restrito ao portal de rastreamento. Antes de qualquer recurso Azure ser provisionado, a fundação de identidade precisa estar operacional, pois todos os acessos subsequentes dependerão das identidades criadas nesta etapa.

Ambiente de Execução:

Grupo de Tarefas	Ambiente	Justificativa
Criação de usuários	PowerShell (Microsoft Graph via Az module)	Automação de criação em lote
Criação de grupos	Azure CLI (az ad group)	Consistência com pipeline IaC
Atribuição de licenças	Portal Azure, blade "Microsoft Entra ID"	A interface de atribuição em lote e visualização de SKUs disponíveis por grupo tem ganho pedagógico irreplicável em CLI
Configuração de usuário externo (guest)	Azure CLI (az ad invitation)	Rastreabilidade do convite
Gerenciamento de propriedades de grupo dinâmico	Portal Azure, blade "Groups"	Construção visual da regra de membership dinâmico exige navegação pelo query builder que consolida compreensão da sintaxe

Estimativa: 45 a 60 minutos. Sem recursos de custo contínuo relevantes nesta etapa (Microsoft Entra ID P2 é necessário para grupos dinâmicos, verificar licença disponível na subscription).

Tarefas:

1. [PowerShell] Crie os seguintes usuários no tenant, com as propriedades obrigatórias: DisplayName, UserPrincipalName, MailNickname, AccountEnabled, PasswordProfile com ForceChangePasswordNextSignIn igual a true, e Department. Usuários a criar:

   UPN	DisplayName	Department	JobTitle
   ana.lima@<tenant>.onmicrosoft.com	Ana Lima	IT Operations	Azure Administrator
   carlos.mendes@<tenant>.onmicrosoft.com	Carlos Mendes	IT Operations	Network Engineer
   john.carter@<tenant>.onmicrosoft.com	John Carter	Infrastructure	Cloud Architect
   sarah.kim@<tenant>.onmicrosoft.com	Sarah Kim	Infrastructure	DevOps Engineer

   Dica de flag não óbvia: o parâmetro -PasswordProfile exige um objeto Microsoft.Open.AzureAD.Model.PasswordProfile no módulo AzureAD, ou um hashtable com as chaves password e forceChangePasswordNextSignIn no módulo Microsoft.Graph.

2. [Azure CLI] Crie dois grupos de segurança:

   Nome do Grupo	Tipo	Descrição
   nxr-grp-infra-admins	Security	Administradores de infraestrutura Azure da Nexora
   nxr-grp-net-engineers	Security	Engenheiros de rede responsáveis pela topologia Azure

   Adicione ana.lima e john.carter ao grupo nxr-grp-infra-admins. Adicione carlos.mendes e sarah.kim ao grupo nxr-grp-net-engineers. Use az ad group member add com o flag --member-id recebendo o objectId de cada usuário.

3. [Portal Azure] Atribua licenças Microsoft Entra ID P2 (ou Microsoft Entra ID P1 se P2 não estiver disponível) aos quatro usuários criados. Navegue para a blade "Licenses" dentro do Microsoft Entra ID, selecione o SKU disponível e realize a atribuição em lote. Verifique que as licenças constam como "Assigned" para cada usuário no painel "Licensed users".

4. [Azure CLI] Convide o usuário externo rapido.operacoes@rapidofrete.com.br como Microsoft Entra B2B Guest, com o parâmetro --invited-user-display-name definido como Rapido Frete Operacoes e --send-invitation-message como true. Após o convite, use az ad user show para confirmar que o userType retornado é Guest.

5. [Troubleshooting] Crie um quinto usuário, test.dynamic@<tenant>.onmicrosoft.com, com a propriedade Department definida como TestGroup. Em seguida, tente criar um grupo com --group-types DynamicMembership usando a Azure CLI com a regra de membership (user.department -eq "IT Operations"). O grupo será criado, mas o usuário ana.lima não aparecerá como membro imediatamente. Diagnostique por que a associação dinâmica não foi processada e qual propriedade de provisionamento precisa ser verificada antes de concluir que a regra está incorreta. Dica: verifique o atributo membershipRuleProcessingState do grupo via az rest com a Microsoft Graph API.

Registro de Variáveis:

Valor	Onde Encontrar	Onde será Usado
Object ID de ana.lima	az ad user show --id ana.lima@<tenant>... --query id	Etapa 2: atribuição de roles
Object ID de john.carter	Mesmo comando acima	Etapa 2: atribuição de roles
Object ID de nxr-grp-infra-admins	az ad group show --group nxr-grp-infra-admins --query id	Etapa 2: atribuição de roles a grupos
Object ID do usuário Guest (Rapido Frete)	az ad user list --filter "userType eq 'Guest'"	Etapa 2: verificação de acesso externo

# Variáveis da Etapa 1
ANA_LIMA_ID=""
JOHN_CARTER_ID=""
CARLOS_MENDES_ID=""
SARAH_KIM_ID=""
GRP_INFRA_ADMINS_ID=""
GRP_NET_ENGINEERS_ID=""
RAPIDO_GUEST_ID=""
TENANT_ID=""

Critérios de Sucesso:

1. az ad user list --filter "accountEnabled eq true" --query "[].userPrincipalName" retorna os quatro UPNs criados, todos com accountEnabled: true.
2. az ad group member list --group nxr-grp-infra-admins --query "[].userPrincipalName" retorna exatamente ana.lima e john.carter.
3. az ad user show --id rapido.operacoes@rapidofrete.com.br --query userType retorna "Guest".
4. az rest --method GET --url "https://graph.microsoft.com/v1.0/groups/<GRP_INFRA_ADMINS_ID>?$select=membershipRule,membershipRuleProcessingState" retorna membershipRuleProcessingState como "On" para o grupo dinâmico criado.
5. az ad user list --filter "department eq 'IT Operations'" --query "length(@)" retorna 2 (Ana Lima e Carlos Mendes).

Controle de Custos: Nenhum recurso Azure pago é provisionado nesta etapa. A licença Microsoft Entra ID P2, se consumida de trial, não gera custo adicional dentro do período de avaliação. Mantenha todos os usuários e grupos ativos, pois são dependências diretas das etapas 2 e 3.

---

Etapa 2: Configure Self-Service Password Reset (SSPR)

Contexto de Negócios: O helpdesk da Nexora recebe em média 140 chamados por mês exclusivamente para reset de senha, representando 23% do volume total de tickets. O CISO aprovou a habilitação de SSPR para todos os colaboradores do grupo nxr-grp-infra-admins como piloto, com requisito de múltiplos métodos de autenticação e auditoria de eventos de reset. A habilitação precisa ser restrita ao grupo piloto antes de expansão para toda a organização.

Ambiente de Execução:

Grupo de Tarefas	Ambiente	Justificativa
Habilitação de SSPR e seleção de grupo	Portal Azure, blade "Password reset"	O fluxo de habilitação scoped por grupo, configuração de métodos e políticas de registro é um fluxo de wizard cujo entendimento visual é parte do objetivo do exame
Configuração de métodos de autenticação	Portal Azure, continuação do mesmo blade	Inerente à mesma navegação
Validação de audit logs	Azure CLI (az rest com Microsoft Graph)	Verificação programática de eventos

Estimativa: 20 a 30 minutos. Sem recursos de custo contínuo nesta etapa além da licença P1/P2 já atribuída.

Tarefas:

1. [Portal Azure] Habilite o SSPR com escopo restrito ao grupo nxr-grp-infra-admins. No blade "Password reset" do Microsoft Entra ID, configure o campo "Self service password reset enabled" como "Selected" e aponte para o grupo. Certifique-se de que o grupo correto está listado antes de salvar.

2. [Portal Azure] Configure os métodos de autenticação aceitos para SSPR com as seguintes restrições: número mínimo de métodos para reset igual a 2, e habilite apenas "Mobile app notification", "Mobile app code" e "Email". Desabilite explicitamente "Security questions" e "Office phone".

3. [Portal Azure] Habilite o registro obrigatório no próximo login para os membros do grupo piloto. Defina o número de dias antes de solicitar novo registro como 180. Localize este controle dentro do blade "Registration" do menu "Password reset".

4. [Azure CLI] Consulte os audit logs do Microsoft Entra via az rest com a Microsoft Graph API para confirmar que a política de SSPR foi aplicada. O endpoint relevante é https://graph.microsoft.com/v1.0/auditLogs/directoryAudits com filtro por activityDisplayName contendo "Set self-service password reset policy".

5. [Troubleshooting] Após configurar o SSPR, tente iniciar o fluxo de reset para o usuário ana.lima acessando o portal https://aka.ms/sspr com as credenciais dela. O processo falhará na etapa de verificação com o erro "We need more information to verify your account". Diagnostique por qual motivo o reset falha mesmo com a política habilitada, identifique a propriedade que precisa ser preenchida previamente pelo usuário, e descreva qual seria o fluxo correto de onboarding para que o SSPR funcione sem intervenção do administrador.

Registro de Variáveis:

Valor	Onde Encontrar	Onde será Usado
ID da política SSPR	az rest --method GET --url "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy"	Documentação e auditoria

# Variáveis da Etapa 2
SSPR_GROUP_ID="${GRP_INFRA_ADMINS_ID}"

Critérios de Sucesso:

1. az rest --method GET --url "https://graph.microsoft.com/v1.0/policies/selfServicePasswordResetUsagePolicy" retorna "isEnabled": true e o id do grupo nxr-grp-infra-admins na lista de grupos habilitados.
2. az rest --method GET --url "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy" retorna "registrationEnforcement" com "authenticationMethodsRegistrationCampaign" ativo para o grupo piloto.
3. az rest --method GET --url "https://graph.microsoft.com/v1.0/auditLogs/directoryAudits?\$filter=activityDisplayName eq 'Set self-service password reset policy'" retorna pelo menos um evento com "result": "success".

Controle de Custos: Nenhum recurso provisionado com custo adicional. Mantenha a configuração de SSPR ativa para os testes de identidade das etapas seguintes.

---

Etapa 3: Manage Built-in Azure Roles e Assign Roles at Different Scopes

Contexto de Negócios: Com as identidades criadas e o SSPR operacional, o time de segurança da Nexora precisa implementar o modelo de controle de acesso baseado em funções (RBAC) seguindo o princípio de menor privilégio. O arquiteto definiu que os administradores de infraestrutura devem gerenciar recursos em toda a subscription, os engenheiros de rede devem ter acesso restrito apenas aos resource groups de rede, e o usuário convidado da Rapido Frete deve ter acesso de leitura apenas ao resource group de rastreamento. Esta etapa também cria os resource groups que serão usados por todas as etapas subsequentes.

Ambiente de Execução:

Grupo de Tarefas	Ambiente	Justificativa
Criação de resource groups	Azure CLI	Automação e rastreabilidade
Atribuição de roles em subscription scope	Azure CLI (az role assignment create)	Consistência com IaC
Atribuição de roles em resource group scope	Azure CLI	Menor privilégio verificável por script
Interpretação de access assignments	Portal Azure, blade "Access Control (IAM)"	A visualização de "Effective permissions" e o painel "Check access" fornecem contexto visual que valida a compreensão do modelo de herança de RBAC

Estimativa: 30 a 45 minutos. Sem recursos de custo contínuo nesta etapa.

Tarefas:

1. [Azure CLI] Crie os seguintes resource groups na subscription, aplicando a tag project=nexora-cloud-foundation e environment conforme a tabela:

   Nome	Região	Tag environment
   nxr-rg-shared-use-01	East US	shared
   nxr-rg-prd-use-01	East US	production
   nxr-rg-net-use-01	East US	production
   nxr-rg-prd-brs-01	Brazil South	production
   nxr-rg-mon-use-01	East US	shared

2. [Azure CLI] Atribua o role Contributor ao grupo nxr-grp-infra-admins no escopo da subscription completa. Use az role assignment create com o flag --assignee-object-id apontando para o Object ID do grupo (não do usuário individual) e --assignee-principal-type Group.

3. [Azure CLI] Atribua o role Network Contributor ao grupo nxr-grp-net-engineers com escopo restrito ao resource group nxr-rg-net-use-01. Atribua também o role Reader ao mesmo grupo no resource group nxr-rg-prd-use-01. Ambas as atribuições devem usar --assignee-principal-type Group.

4. [Azure CLI] Atribua o role Reader ao usuário guest rapido.operacoes@rapidofrete.com.br com escopo restrito ao resource group nxr-rg-prd-brs-01. Use o Object ID do usuário guest salvo na Etapa 1 com --assignee-principal-type User.

5. [Troubleshooting] Atribua erroneamente o role Owner ao usuário john.carter@<tenant> diretamente no escopo da subscription (em vez de usar o grupo). Em seguida, verifique via Portal Azure, blade "Access Control (IAM)" do resource group nxr-rg-prd-use-01, no botão "Check access", inserindo john.carter como identidade. O acesso aparecerá como Owner mesmo que a intenção fosse atribuir via grupo. Diagnostique como identificar via az role assignment list que existe uma atribuição direta redundante e conflitante com a política de governança de RBAC (atribuições apenas via grupo), e remova a atribuição direta usando az role assignment delete com os flags corretos.

[Portal Azure] Após concluir todas as atribuições, acesse o blade "Access Control (IAM)" da subscription e use o painel "Check access" para verificar as permissões efetivas de ana.lima. Compare com as permissões de carlos.mendes no mesmo contexto, observando a diferença de escopo entre a atribuição de Contributor via grupo e a atribuição de Network Contributor restrita ao resource group de rede.

Registro de Variáveis:

Valor	Onde Encontrar	Onde será Usado
ID da subscription	az account show --query id	Todas as etapas seguintes
Resource Group nxr-rg-prd-use-01	Criado nesta etapa	Etapas 4, 5, 7, 8, 9, 10
Resource Group nxr-rg-net-use-01	Criado nesta etapa	Etapa 9
Resource Group nxr-rg-prd-brs-01	Criado nesta etapa	Etapas 8, 13
Resource Group nxr-rg-shared-use-01	Criado nesta etapa	Etapas 4, 5, 6, 7
Resource Group nxr-rg-mon-use-01	Criado nesta etapa	Etapa 13

# Variáveis da Etapa 3
SUBSCRIPTION_ID=""
RG_PRD_USE="nxr-rg-prd-use-01"
RG_NET_USE="nxr-rg-net-use-01"
RG_PRD_BRS="nxr-rg-prd-brs-01"
RG_SHARED_USE="nxr-rg-shared-use-01"
RG_MON_USE="nxr-rg-mon-use-01"

Critérios de Sucesso:

1. az role assignment list --assignee ${GRP_INFRA_ADMINS_ID} --scope /subscriptions/${SUBSCRIPTION_ID} --query "[].roleDefinitionName" retorna ["Contributor"].
2. az role assignment list --assignee ${GRP_NET_ENGINEERS_ID} --resource-group nxr-rg-net-use-01 --query "[].roleDefinitionName" retorna ["Network Contributor"].
3. az role assignment list --assignee ${RAPIDO_GUEST_ID} --resource-group nxr-rg-prd-brs-01 --query "[].roleDefinitionName" retorna ["Reader"].
4. az role assignment list --assignee ${JOHN_CARTER_ID} --scope /subscriptions/${SUBSCRIPTION_ID} --query "length(@)" retorna 0 (após remoção da atribuição direta incorreta).
5. az group list --query "[].{name:name, location:location}" --output table retorna os 5 resource groups com as regiões corretas.

Controle de Custos: Resource groups não geram custo por si mesmos. Mantenha todos os resource groups ativos. A remoção prematura de qualquer RG bloqueia todas as etapas subsequentes.

---

Etapa 4: Implement and Manage Azure Policy

Contexto de Negócios: O compliance officer da Nexora identificou que, durante a migração da TransRoute, recursos foram criados sem tags em múltiplas subscriptions, tornando impossível a alocação de custos por centro de custo. Além disso, a política de segurança exige que VMs só possam ser provisionadas em regiões aprovadas (East US e Brazil South), e que todos os storage accounts sejam criados com HTTPS obrigatório. Estas políticas precisam ser aplicadas programaticamente antes que qualquer time técnico comece a provisionar recursos de infraestrutura.

Ambiente de Execução:

Grupo de Tarefas	Ambiente	Justificativa
Criação e atribuição de policy definitions	Azure CLI (az policy)	Automação e auditoria de atribuições
Criação de policy initiative	Azure CLI	Agrupamento de políticas via CLI
Verificação de compliance	Portal Azure, blade "Policy"	O dashboard de compliance com gráficos de conformidade por recurso, scope e initiative oferece contexto visual que CLI não replica adequadamente para diagnóstico de drift

Estimativa: 40 a 55 minutos. Sem recursos de custo contínuo nesta etapa.

Tarefas:

1. [Azure CLI] Atribua a policy built-in Require a tag on resources (Definition ID: /providers/Microsoft.Authorization/policyDefinitions/871b6d14-10aa-478d-b590-94f262ecfa99) ao escopo da subscription, com o parâmetro tagName definido como project. Defina o enforcementMode como Default. O parâmetro de modo de aplicação é passado via --enforcement-mode.

2. [Azure CLI] Crie uma policy definition customizada chamada nxr-policy-allowed-regions que restrinja o provisionamento de qualquer recurso a apenas as locations eastus e brazilsouth. Use o built-in effect Deny. A rule deve usar o campo location com notIn como operador. Salve a definição como JSON em um arquivo local antes de passá-la ao comando.

3. [Azure CLI] Atribua a policy nxr-policy-allowed-regions criada no passo anterior ao escopo da subscription com enforcementMode como Default. Use o Policy Definition ID retornado pelo comando de criação da policy.

4. [Azure CLI] Crie uma policy initiative (policy set definition) chamada nxr-initiative-baseline-security agrupando as seguintes built-in policies: Secure transfer to storage accounts should be enabled e Storage accounts should restrict network access. Atribua a initiative à subscription.

5. [Troubleshooting] Tente criar um storage account no resource group nxr-rg-prd-use-01 com location westus usando az storage account create. O comando retornará o erro RequestDisallowedByPolicy. Copie o policyDefinitionId e o policyAssignmentId presentes no corpo do erro. Em seguida, use az policy state list com o flag --resource apontando para o resource group para listar as violações e confirmar qual policy específica bloqueou a criação. Documente o complianceState retornado.

[Portal Azure] Após as atribuições, acesse o blade "Policy" na subscription e navegue para "Compliance". Verifique o estado de conformidade da initiative nxr-initiative-baseline-security e identifique recursos não conformes, se houver. Observe a latência de avaliação (pode levar até 30 minutos para novos recursos aparecerem como non-compliant).

Registro de Variáveis:

Valor	Onde Encontrar	Onde será Usado
ID da policy nxr-policy-allowed-regions	az policy definition show --name nxr-policy-allowed-regions --query id	Etapa 5: referência para locks
ID da initiative nxr-initiative-baseline-security	az policy set-definition show --name nxr-initiative-baseline-security --query id	Auditoria de compliance

# Variáveis da Etapa 4
POLICY_ALLOWED_REGIONS_ID=""
INITIATIVE_BASELINE_ID=""

Critérios de Sucesso:

1. az policy assignment list --scope /subscriptions/${SUBSCRIPTION_ID} --query "[].displayName" retorna as três atribuições criadas nesta etapa.
2. az policy definition show --name nxr-policy-allowed-regions --query "policyRule.then.effect" retorna "deny".
3. az storage account create --name nxrtestwestus --resource-group ${RG_PRD_USE} --location westus falha com erro RequestDisallowedByPolicy e o policyDefinitionId referencia nxr-policy-allowed-regions.
4. az policy state list --resource /subscriptions/${SUBSCRIPTION_ID}/resourceGroups/${RG_PRD_USE} --query "[0].complianceState" retorna "Compliant" ou "NonCompliant" (não vazio, confirmando que a avaliação ocorreu).
5. az policy set-definition show --name nxr-initiative-baseline-security --query "policyDefinitions | length(@)" retorna 2.

Controle de Custos: Azure Policy não gera custo direto. Mantenha todas as atribuições ativas para garantir compliance nas etapas de criação de recursos subsequentes.

---

Etapa 5: Configure Resource Locks, Tags, Subscriptions e Management Groups

Contexto de Negócios: O CFO da Nexora determinou que os resource groups de produção não podem ser excluídos acidentalmente por operadores com permissão de Contributor. Simultaneamente, o time de FinOps precisa que todos os recursos existentes e futuros carreguem tags de costcenter para chargeback mensal. A área jurídica também solicitou a criação de uma hierarquia de management groups para separar as subscriptions da Nexora Brasil e da TransRoute Inc., com políticas aplicadas no nível do management group pai.

Ambiente de Execução:

Grupo de Tarefas	Ambiente	Justificativa
Criação de resource locks	Azure CLI (az lock)	Automação e rastreabilidade
Aplicação de tags em lote	PowerShell (Update-AzTag)	O cmdlet Update-AzTag com -Operation Merge é mais eficiente para atualização em lote do que a Azure CLI
Criação de management groups	Azure CLI (az account management-group)	Provisionamento de hierarquia
Movimentação de subscriptions	Portal Azure, blade "Management Groups"	A interface de drag-and-drop e a visualização da hierarquia são fundamentais para compreender a estrutura antes de mover subscriptions em produção
Configuração de budget e alertas de custo	Portal Azure, blade "Cost Management"	O wizard de budget com configuração de alertas por percentual e período tem fluxo interativo que CLI não replica com clareza equivalente

Estimativa: 50 a 65 minutos. O recurso Cost Management não gera custo adicional, mas a subscription ativa gera custos dos recursos provisionados nas etapas anteriores e posteriores.

Tarefas:

1. [Azure CLI] Aplique um lock do tipo CanNotDelete com nome nxr-lock-prd-nodelete nos resource groups nxr-rg-prd-use-01 e nxr-rg-prd-brs-01. Use az lock create com os parâmetros --lock-type, --name e --resource-group. O lock deve ter notes descrevendo "Production RG - deletion protected per CFO policy".

2. [PowerShell] Usando Update-AzTag com -Operation Merge, adicione a tag costcenter=CC-3200-IT a todos os resource groups da subscription. Use Get-AzResourceGroup para iterar sobre todos os RGs e aplique a tag em cada um. Atenção: o cmdlet Update-AzTag exige o ResourceId completo do recurso, não apenas o nome.

3. [Azure CLI] Crie a seguinte hierarquia de management groups:

   nxr-mg-root
   ├── nxr-mg-brasil
   └── nxr-mg-transroute

   Use az account management-group create com o parâmetro --parent para definir a hierarquia. O management group raiz da Nexora deve ser filho do Tenant Root Group.

4. [Azure CLI] Atribua a policy nxr-policy-allowed-regions (criada na Etapa 4) ao management group nxr-mg-brasil para que a restrição de região seja herdada por todas as subscriptions filhas. Use az policy assignment create com o --scope no formato /providers/Microsoft.Management/managementGroups/nxr-mg-brasil.

5. [Troubleshooting] Tente deletar o resource group nxr-rg-prd-use-01 usando az group delete --name nxr-rg-prd-use-01 --yes. O comando retornará erro ScopeLocked. Identifique o lock usando az lock list --resource-group nxr-rg-prd-use-01 e documente o id do lock. Em seguida, simule o cenário em que um administrador precisa excluir o RG legitimamente, descrevendo a sequência correta de operações (sem executá-la), incluindo quem tem permissão para remover o lock e como o RBAC interage com locks.

[Portal Azure] Após criar o budget, configure um alerta de custo com threshold de 80% do valor mensal estimado da subscription. Acesse o blade "Cost Management" na subscription e use o wizard "Budgets" para criar um budget mensal chamado nxr-budget-monthly-use com o valor de USD 500, período de reset mensal, e alertas em 50%, 80% e 100% enviados para lab-admin@<tenant>.onmicrosoft.com.

Registro de Variáveis:

Valor	Onde Encontrar	Onde será Usado
ID do lock nxr-lock-prd-nodelete (RG prd-use)	az lock list --resource-group nxr-rg-prd-use-01 --query "[0].id"	Documentação e Etapa de validação global
ID do management group nxr-mg-brasil	az account management-group show --name nxr-mg-brasil --query id	Referência de hierarquia

# Variáveis da Etapa 5
LOCK_PRD_USE_ID=""
MG_BRASIL_ID=""
MG_TRANSROUTE_ID=""

Critérios de Sucesso:

1. az lock list --resource-group nxr-rg-prd-use-01 --query "[0].properties.level" retorna "CanNotDelete".
2. az group list --query "[].tags.costcenter" --output tsv | sort -u retorna apenas CC-3200-IT (todas as tags iguais).
3. az account management-group show --name nxr-mg-brasil --query properties.displayName retorna "nxr-mg-brasil".
4. az policy assignment list --scope /providers/Microsoft.Management/managementGroups/nxr-mg-brasil --query "[].displayName" inclui a policy de regiões permitidas.
5. az group delete --name nxr-rg-prd-use-01 --yes retorna erro com errorCode igual a ScopeLocked.

Controle de Custos: O budget criado é apenas de alerta e não tem custo. Mantenha os locks e management groups ativos. Não mova a subscription de laboratório para o management group nxr-mg-brasil se isso afetar a configuração atual, pois a herança de policies pode bloquear provisionamentos futuros no laboratório.

---

Etapa 6: Configure and Manage Storage Accounts

Contexto de Negócios: O time de dados da Nexora precisa de uma infraestrutura de storage para três casos de uso distintos: armazenamento de logs operacionais com retenção de 90 dias, repositório de backups de bancos de dados com redundância geográfica, e compartilhamento de arquivos para os centros de distribuição que ainda operam on-premises. Esta é a primeira etapa de provisionamento de recursos de dados, e os storage accounts criados aqui serão consumidos pelas VMs provisionadas na Etapa 8 e pelo pipeline de monitoramento da Etapa 13.

Ambiente de Execução:

Grupo de Tarefas	Ambiente	Justificativa
Criação de storage accounts	Azure CLI (az storage account create)	Provisionamento padrão
Configuração de redundância	Azure CLI	Parâmetro --sku na criação
Configuração de criptografia com CMK	Azure CLI + Key Vault	Requer sequência multi-passo
Gerenciamento de access keys e rotação	Portal Azure, blade "Access keys"	A interface de rotação de chave com aviso de impacto em conexões ativas e o botão de swap é uma operação operacional cujo fluxo visual reduz risco de incidentes
Object replication	Azure CLI	Configuração de policy via CLI

Estimativa: 55 a 70 minutos. Storage accounts geram custo contínuo baseado em capacidade e operações. Recursos de maior impacto: nxr-sa-prd-use-01 (GRS) e nxr-sa-prd-brs-01.

Tarefas:

1. [Azure CLI] Crie os seguintes storage accounts. Atenção: nomes de storage accounts não permitem hífens, adapte a convenção removendo hífens e mantendo o prefixo reconhecível:

   Nome (sem hífens)	Resource Group	Região	SKU	Kind	Acesso HTTPS
   nxrsaprduse01	nxr-rg-prd-use-01	East US	Standard_GRS	StorageV2	Enabled
   nxrsashareduse01	nxr-rg-shared-use-01	East US	Standard_LRS	StorageV2	Enabled
   nxrsaprdbrs01	nxr-rg-prd-brs-01	Brazil South	Standard_ZRS	StorageV2	Enabled

   Use --https-only true e --min-tls-version TLS1_2 em todos os storage accounts.

2. [Azure CLI] Configure object replication do storage account nxrsaprduse01 (East US, origem) para nxrsaprdbrs01 (Brazil South, destino). Antes de configurar a replication policy, habilite o blob versioning em ambos os storage accounts (flag --enable-versioning true via az storage account blob-service-properties update) e habilite o change feed apenas na conta de origem (flag --enable-change-feed true). A policy de replicação é criada com az storage account or-policy create.

3. [Azure CLI] Configure um lifecycle management policy no storage account nxrsashareduse01 para mover blobs para o tier Cool após 30 dias e para o tier Archive após 90 dias, aplicado ao container logs (a ser criado na Etapa 7). Salve a policy como JSON antes de aplicar com az storage account management-policy create --policy @policy.json.

4. [Azure CLI] Habilite soft delete para blobs com retenção de 14 dias e soft delete para containers com retenção de 7 dias no storage account nxrsaprduse01. Use az storage account blob-service-properties update com os flags --enable-delete-retention e --delete-retention-days para blobs, e --enable-container-delete-retention e --container-delete-retention-days para containers.

5. [Troubleshooting] Tente criar uma object replication policy sem ter habilitado previamente o change feed na conta de origem. O erro retornado pelo comando az storage account or-policy create indicará que o change feed não está habilitado. Identifique no erro qual propriedade exatamente precisa ser habilitada, corrija e reaplique. Em seguida, confirme que a policy foi criada verificando o policyId retornado e o ruleId da primeira regra.

[Portal Azure] Acesse o blade "Access keys" do storage account nxrsaprduse01. Observe a interface de rotação de chave, identifique a diferença entre key1 e key2, e execute a rotação da key2 pelo portal. Documente a nova string de conexão após a rotação.

Registro de Variáveis:

Valor	Onde Encontrar	Onde será Usado
Nome do SA nxrsaprduse01	Criado nesta etapa	Etapas 7, 8, 13
Nome do SA nxrsashareduse01	Criado nesta etapa	Etapas 7, 13
Nome do SA nxrsaprdbrs01	Criado nesta etapa	Etapa 13
Object replication policy ID	az storage account or-policy list --account-name nxrsaprduse01	Etapa 13
Connection string do SA nxrsaprduse01	az storage account show-connection-string --name nxrsaprduse01	Etapas 7, 8

# Variáveis da Etapa 6
SA_PRD_USE="nxrsaprduse01"
SA_SHARED_USE="nxrsashareduse01"
SA_PRD_BRS="nxrsaprdbrs01"
SA_PRD_USE_CONN_STRING=""
OR_POLICY_ID=""

Critérios de Sucesso:

1. az storage account show --name nxrsaprduse01 --query "{sku:sku.name, tls:minimumTlsVersion, https:supportsHttpsTrafficOnly}" retorna Standard_GRS, TLS1_2, true.
2. az storage account blob-service-properties show --account-name nxrsaprduse01 --query "{deleteRetention:deleteRetentionPolicy.enabled, days:deleteRetentionPolicy.days}" retorna true e 14.
3. az storage account or-policy list --account-name nxrsaprduse01 --query "[0].rules[0].ruleId" retorna um UUID não vazio.
4. az storage account management-policy show --account-name nxrsashareduse01 --query "policy.rules[0].name" retorna o nome da regra de lifecycle criada.
5. az storage account show --name nxrsaprdbrs01 --query "sku.name" retorna "Standard_ZRS".

Controle de Custos: Os três storage accounts geram custo contínuo. nxrsaprduse01 (GRS) tem maior custo por armazenar dados em duas regiões. Mantenha-os ativos, pois são dependências de Etapas 7, 8 e 13. Evite carregar dados desnecessários durante o laboratório para minimizar custos de transação e capacidade.

---

Etapa 7: Configure Azure Files, Azure Blob Storage, SAS Tokens e Access Policies

Contexto de Negócios: Com os storage accounts operacionais, o time de operações da Nexora precisa configurar os containers de blob para os logs do sistema de rastreamento e os file shares para os scripts de automação dos centros de distribuição. A equipe de segurança exige que o acesso externo aos blobs seja controlado por SAS tokens com escopo mínimo e expiração curta, e que as políticas de acesso armazenadas sejam usadas para revogação centralizada.

Ambiente de Execução:

Grupo de Tarefas	Ambiente	Justificativa
Criação de containers e file shares	Azure CLI	Provisionamento padrão
Geração de SAS tokens	Azure CLI (az storage blob generate-sas)	Geração programática rastreável
Configuração de stored access policies	Azure CLI	Criação e gerenciamento de policies via CLI
Gerenciamento visual de blobs	Azure Storage Explorer	Ferramenta de diagnóstico visual para upload, download e inspeção de metadados de blobs, indispensável para o objetivo do exame
Transferência de dados com AzCopy	CLI local (AzCopy)	Ferramenta dedicada para transferência de dados em larga escala
Configuração de identity-based access para Azure Files	Azure CLI + PowerShell	Requer habilitação de AD DS ou Entra Kerberos

Estimativa: 60 a 75 minutos. File shares do tipo Premium geram custo provisionado (mesmo sem dados). Use o tier Standard para este laboratório.

Tarefas:

1. [Azure CLI] No storage account nxrsaprduse01, crie dois containers: logs (access level: private) e tracking-exports (access level: blob). No storage account nxrsashareduse01, crie o container scripts (access level: private). Use az storage container create com o parâmetro --public-access.

2. [Azure CLI] No storage account nxrsashareduse01, crie um file share chamado nxr-fs-dist-centers com quota de 100 GiB e tier TransactionOptimized. Use az storage share-rm create (não o comando legado az storage share create) com os parâmetros --storage-account, --name, --quota e --access-tier.

3. [Azure CLI] Crie uma stored access policy chamada nxr-sap-logs-readonly no container logs do storage account nxrsaprduse01, com permissão de leitura (r) e listagem (l), válida por 30 dias a partir de hoje. Use az storage container policy create. Em seguida, gere um SAS token para o container logs referenciando esta stored access policy (parâmetro --policy-name), em vez de embutir permissões e validade diretamente no token.

4. [AzCopy] Usando AzCopy, faça upload de um arquivo de teste local (crie um arquivo test-log.txt localmente com conteúdo arbitrário) para o container logs do storage account nxrsaprduse01 autenticando via azcopy login com sua conta Microsoft Entra. O comando principal é azcopy copy com a URL do destino no formato https://<storage>.blob.core.windows.net/<container>/<blob>. Em seguida, verifique o blob via az storage blob list.

5. [Troubleshooting] Gere um SAS token para o blob test-log.txt com permissão de leitura e expiração de 1 minuto no passado (defina --expiry como um timestamp já expirado). Tente acessar o blob via curl usando a URL com o SAS token. O servidor retornará HTTP 403 com AuthenticationFailed. Identifique no body XML da resposta qual campo indica a causa específica do erro (diferente de credenciais inválidas), corrija o SAS token com uma expiração válida de 2 horas e confirme que o acesso retorna HTTP 200.

[Azure Storage Explorer] Abra o Azure Storage Explorer, conecte-se à subscription usando sua conta Microsoft Entra, navegue até o storage account nxrsaprduse01, expanda o container logs e inspecione as propriedades e metadados do blob test-log.txt carregado via AzCopy. Verifique o tier de acesso (Hot), o tipo de conteúdo e o tamanho.

Registro de Variáveis:

Valor	Onde Encontrar	Onde será Usado
URL do container logs	az storage account show --name nxrsaprduse01 --query primaryEndpoints.blob	Etapas 8, 13
Nome do file share nxr-fs-dist-centers	Criado nesta etapa	Etapa 8 (montagem em VM)
SAS token da stored access policy	Gerado no passo 3	Etapa 13 (teste de acesso externo)

# Variáveis da Etapa 7
BLOB_ENDPOINT_PRD_USE=""
FILE_SHARE_NAME="nxr-fs-dist-centers"
LOGS_CONTAINER_SAS_TOKEN=""

Critérios de Sucesso:

1. az storage container list --account-name nxrsaprduse01 --query "[].{name:name, public:properties.publicAccess}" retorna logs com null e tracking-exports com blob.
2. az storage container policy list --container-name logs --account-name nxrsaprduse01 --query "[0].name" retorna "nxr-sap-logs-readonly".
3. az storage blob list --container-name logs --account-name nxrsaprduse01 --query "[0].name" retorna "test-log.txt".
4. az storage share-rm show --storage-account nxrsashareduse01 --name nxr-fs-dist-centers --query "{quota:properties.shareQuota, tier:accessTier}" retorna quota 100 e tier TransactionOptimized.
5. curl -s -o /dev/null -w "%{http_code}" "<URL_DO_BLOB_COM_SAS_EXPIRADO>" retorna 403.

Controle de Custos: Containers e file shares dentro dos storage accounts já provisionados não geram custo adicional além do volume de dados. Mantenha os recursos ativos. Remova blobs de teste desnecessários após a validação para reduzir custos de capacidade.

---

Etapa 8: Automate Deployment with ARM Templates and Bicep

Contexto de Negócios: O time de infraestrutura da Nexora precisa padronizar o provisionamento de VMs usando IaC para garantir que todas as máquinas sigam as mesmas configurações de segurança, tamanho e disco. O arquiteto definiu que o template deve ser reutilizável para múltiplos ambientes (produção e desenvolvimento), com parâmetros externalizados. Esta etapa estabelece o modelo de implantação que será usado para criar as VMs das Etapas 9 e 10.

Ambiente de Execução:

Grupo de Tarefas	Ambiente	Justificativa
Criação e edição de template Bicep	VS Code com extensão Bicep	Validação estática e IntelliSense
Conversão de ARM para Bicep	Bicep CLI (bicep decompile)	Habilidade diretamente cobrada no exame
Validação de template	Azure CLI (az deployment group validate)	Validação pré-implantação
Implantação do template	Azure CLI (az deployment group create)	Provisionamento via IaC
Export de deployment existente	Portal Azure, blade "Export template"	A exportação de templates de recursos existentes e a comparação com o Bicep gerado é um exercício visual com ganho pedagógico real

Estimativa: 60 a 80 minutos. A VM provisionada nesta etapa (se não desalocada) gera custo contínuo. Importante: desaloque a VM após validação dos critérios de sucesso se não houver orçamento disponível.

Tarefas:

1. [VS Code + Bicep CLI] Crie um arquivo nxr-vm-template.bicep que provisione os seguintes recursos como um módulo reutilizável: uma Virtual Network com uma subnet, uma NIC vinculada à subnet, um Public IP (SKU Standard, allocation Static) e uma VM Linux (Ubuntu 22.04 LTS) com os parâmetros externalizados: vmName, location, vmSize, adminUsername, adminPassword (tipo securestring), subnetAddressPrefix e vnetAddressPrefix. O template deve usar @description() decorators nos parâmetros e ter valores default para vmSize (Standard_B2s) e location (resourceGroup().location).

2. [Bicep CLI] Valide o template Bicep usando bicep build para verificar erros de sintaxe e gere o ARM JSON equivalente. Em seguida, use bicep decompile em um ARM template fornecido abaixo para praticar a conversão inversa. Salve o template ARM como legacy-vm.json com o seguinte conteúdo mínimo que representa uma VM básica com parâmetros de localização e tamanho, depois converta para Bicep e compare as diferenças estruturais.

3. [Azure CLI] Implante o template nxr-vm-template.bicep no resource group nxr-rg-prd-use-01 usando az deployment group create com os parâmetros: vmName=nxr-vm-prd-use-01, location=eastus, adminUsername=nxradmin, adminPassword (use uma senha forte, mínimo 12 caracteres com maiúsculas, minúsculas, números e símbolos). Use --mode Incremental. Monitore o progresso com az deployment group show.

4. [Portal Azure] Após a implantação bem-sucedida, acesse o resource group nxr-rg-prd-use-01, selecione a VM nxr-vm-prd-use-01 e use o blade "Export template" (dentro de "Automation") para exportar o template ARM da VM provisionada. Compare o template exportado com o Bicep original, identificando quais propriedades adicionais o Azure adicionou automaticamente (como provisioningState, vmId e propriedades de sistema).

5. [Troubleshooting] Modifique o arquivo nxr-vm-template.bicep para incluir um parâmetro diskSizeGB com o valor 30 (abaixo do mínimo de 30 GB para o OS disk do Ubuntu, que é 30 GB, mas tente 29). Execute az deployment group validate antes do deploy. O comando retornará InvalidTemplate ou InvalidParameter indicando a violação de constraint. Identifique o campo details[0].message na resposta de erro, corrija o valor para 32 e re-valide até que o comando retorne "provisioningState": "Succeeded" na validação.

Registro de Variáveis:

Valor	Onde Encontrar	Onde será Usado
Nome da VM nxr-vm-prd-use-01	Definido no template	Etapas 9, 10, 13
Resource ID da VM	az vm show --name nxr-vm-prd-use-01 --resource-group nxr-rg-prd-use-01 --query id	Etapas 9, 10, 13
IP público da VM	az vm show --name nxr-vm-prd-use-01 --resource-group nxr-rg-prd-use-01 --show-details --query publicIps	Etapa 9 (Bastion)
VNet criada pelo template	az network vnet list --resource-group nxr-rg-prd-use-01 --query "[0].name"	Etapas 9, 10
Subnet ID	az network vnet subnet list --resource-group nxr-rg-prd-use-01 --vnet-name <vnet_name> --query "[0].id"	Etapas 9, 10

# Variáveis da Etapa 8
VM_PRD_USE_NAME="nxr-vm-prd-use-01"
VM_PRD_USE_ID=""
VM_PRD_USE_IP=""
VNET_PRD_USE_NAME=""
SUBNET_PRD_USE_ID=""
DEPLOYMENT_NAME="nxr-deploy-vm-prd-use-01"

Critérios de Sucesso:

1. az deployment group show --resource-group nxr-rg-prd-use-01 --name ${DEPLOYMENT_NAME} --query properties.provisioningState retorna "Succeeded".
2. az vm show --name nxr-vm-prd-use-01 --resource-group nxr-rg-prd-use-01 --query provisioningState retorna "Succeeded".
3. az vm show --name nxr-vm-prd-use-01 --resource-group nxr-rg-prd-use-01 --query storageProfile.osDisk.diskSizeGb retorna 32 (ou o valor configurado acima de 30).
4. az deployment group validate --resource-group nxr-rg-prd-use-01 --template-file nxr-vm-template.bicep --parameters vmName=test-validate --query properties.provisioningState retorna "Succeeded".
5. bicep build nxr-vm-template.bicep executa sem erros e gera o arquivo .json correspondente.

Controle de Custos: A VM nxr-vm-prd-use-01 gera custo contínuo enquanto em estado Running. Se o orçamento for limitado, execute az vm deallocate --name nxr-vm-prd-use-01 --resource-group nxr-rg-prd-use-01 após validar os critérios de sucesso. A VM será necessária na Etapa 9 (reinicie com az vm start naquele momento). O disco gerenciado gera custo mesmo com VM desalocada.

---

Etapa 9: Create and Configure Virtual Machines (Advanced)

Contexto de Negócios: A VM básica criada via template na Etapa 8 precisa ser endurecida conforme as políticas de segurança da Nexora: criptografia em nível de host, disco de dados dedicado para o volume de logs e implantação em Availability Zone para resiliência. Adicionalmente, o time de operações precisa de uma segunda VM em Brazil South para atender o requisito de latência dos centros de distribuição nordestinos. O arquiteto também solicitou que um VM Scale Set seja configurado para o workload de processamento de eventos de rastreamento, que tem picos de tráfego durante janelas de entrega.

Ambiente de Execução:

Grupo de Tarefas	Ambiente	Justificativa
Habilitação de encryption at host	Azure CLI + feature registration	Exige registro do feature no provider
Adição de disco de dados	Azure CLI (az vm disk attach)	Operação de storage em VM
Criação de VM em Availability Zone	Azure CLI (az vm create com --zone)	Provisionamento com parâmetro de zona
VM Scale Set	Azure CLI (az vmss create)	Provisionamento e configuração
Movimentação de VM entre resource groups	Azure CLI (az resource move)	Operação de gerenciamento de recursos
Redimensionamento de VM	Portal Azure, blade "Size" da VM	O filtro visual de SKUs disponíveis por família, vCPUs e memória é um fluxo de seleção que o portal apresenta de forma mais eficiente para entender as famílias de VM do Azure

Estimativa: 70 a 90 minutos. Múltiplas VMs e o VMSS geram custo contínuo significativo. Desaloque todos os recursos após os critérios de sucesso serem validados.

Tarefas:

1. [Azure CLI] Registre o feature EncryptionAtHost no provider Microsoft.Compute da subscription usando az feature register --namespace Microsoft.Compute --name EncryptionAtHost. Aguarde até que az feature show retorne "state": "Registered". Em seguida, registre novamente o provider com az provider register --namespace Microsoft.Compute. Após o registro, habilite a encryption at host na VM nxr-vm-prd-use-01 usando az vm update com o flag --set securityProfile.encryptionAtHost=true. Atenção: a VM precisa estar desalocada para esta operação.

2. [Azure CLI] Crie e anexe um disco de dados gerenciado de 128 GiB, SKU Premium_LRS, chamado nxr-disk-prd-use-01, à VM nxr-vm-prd-use-01. Use az disk create seguido de az vm disk attach com o flag --new ou referenciando o disco existente. O disco deve ser associado ao LUN 0.

3. [Azure CLI] Crie uma segunda VM chamada nxr-vm-prd-brs-01 no resource group nxr-rg-prd-brs-01, região brazilsouth, com --zone 1, tamanho Standard_B2s, Ubuntu 22.04 LTS, usando a imagem Canonical:ubuntu-24_04-lts:server:latest. Esta VM não precisa de Public IP (use --public-ip-address ""). Para acesso, será usado o Bastion configurado na Etapa 10.

4. [Azure CLI] Crie um VM Scale Set chamado nxr-vmss-prd-use-01 no resource group nxr-rg-prd-use-01, zona 1,2,3, com capacidade inicial de 2 instâncias, capacidade mínima 1, máxima 5, e política de escalonamento baseada em CPU com threshold de 70% para scale-out e 30% para scale-in. Use az vmss create com os parâmetros --instance-count, --zones e configure a autoscale separadamente com az monitor autoscale create e az monitor autoscale rule create.

5. [Troubleshooting] Tente habilitar a encryption at host na VM nxr-vm-prd-use-01 sem desalocá-la primeiro. O erro retornado será OperationNotAllowed com mensagem indicando que a VM deve estar no estado Deallocated. Verifique o estado da VM com az vm get-instance-view --name nxr-vm-prd-use-01 --resource-group nxr-rg-prd-use-01 --query instanceView.statuses[1].displayStatus. Desaloque a VM e reaplique a configuração.

[Portal Azure] Após a VM estar com encryption at host habilitado, acesse o blade "Size" da VM nxr-vm-prd-use-01 e use o seletor de tamanhos para filtrar SKUs da família D com suporte a Premium Storage. Identifique o SKU Standard_D2s_v5 na lista e documente as diferenças de vCPU, memória e limite de IOPS em comparação com o Standard_B2s atual. Não execute o redimensionamento.

Registro de Variáveis:

Valor	Onde Encontrar	Onde será Usado
ID do disco nxr-disk-prd-use-01	az disk show --name nxr-disk-prd-use-01 --resource-group nxr-rg-prd-use-01 --query id	Etapa 13 (backup)
Nome do VMSS	nxr-vmss-prd-use-01	Etapas 10, 13
IP privado da VM nxr-vm-prd-brs-01	az vm show --name nxr-vm-prd-brs-01 --resource-group nxr-rg-prd-brs-01 --show-details --query privateIps	Etapa 10 (Bastion)

# Variáveis da Etapa 9
VM_PRD_BRS_NAME="nxr-vm-prd-brs-01"
VM_PRD_BRS_IP_PRIVATE=""
VMSS_NAME="nxr-vmss-prd-use-01"
DISK_PRD_USE_ID=""

Critérios de Sucesso:

1. az vm show --name nxr-vm-prd-use-01 --resource-group nxr-rg-prd-use-01 --query securityProfile.encryptionAtHost retorna true.
2. az vm show --name nxr-vm-prd-use-01 --resource-group nxr-rg-prd-use-01 --query storageProfile.dataDisks[0].diskSizeGb retorna 128.
3. az vm show --name nxr-vm-prd-brs-01 --resource-group nxr-rg-prd-brs-01 --query zones[0] retorna "1".
4. az vmss show --name nxr-vmss-prd-use-01 --resource-group nxr-rg-prd-use-01 --query sku.capacity retorna 2.
5. az monitor autoscale show --resource-group nxr-rg-prd-use-01 --name <autoscale_name> --query profiles[0].capacity.maximum retorna "5".

Controle de Custos: VMs e VMSS geram custo contínuo. Após validação dos critérios, execute az vm deallocate para ambas as VMs e az vmss deallocate --instance-ids * para o VMSS. O VMSS em escala mínima (0 instâncias) ainda pode gerar custo de infraestrutura associada.

---

Etapa 10: Provision Containers, App Service e Virtual Networking

Contexto de Negócios: O time de desenvolvimento da Nexora adotou containers para o novo microserviço de API de rastreamento de frotas. O Container Registry centralizado armazena as imagens oficiais, o Container Instances serve para jobs batch esporádicos (reconciliação de dados), e o Container Apps serve para o microserviço de API com escalamento automático. A VNet criada via template precisa ser expandida com peering para a rede de Brazil South, NSGs e Bastion para acesso seguro às VMs sem exposição de IP público.

Ambiente de Execução:

Grupo de Tarefas	Ambiente	Justificativa
Criação de ACR	Azure CLI	Provisionamento padrão
Build e push de imagem	Docker CLI + Azure CLI (az acr build)	Pipeline de imagem
Container Instances	Azure CLI (az container create)	Provisionamento declarativo
Container Apps	Azure CLI (az containerapp create)	Provisionamento com KEDA
VNet peering	Azure CLI (az network vnet peering)	Topologia de rede
NSG e ASG	Azure CLI	Segurança de rede programática
Azure Bastion	Azure CLI (az network bastion create)	Provisionamento inicial
Topologia de rede	Portal Azure, blade "Network Watcher - Topology"	Visualização da topologia de VNet, peering, subnets e NSGs em grafo é um ganho pedagógico único que o portal oferece
App Service + slots	Azure CLI + Portal para configuração de deployment slots	Slots de deployment têm fluxo visual de swap com configurações de sticky settings

Estimativa: 90 a 120 minutos. Azure Bastion (Standard SKU) gera custo contínuo significativo. ACR Basic e Container Apps também geram custo. Desaloque Bastion após os testes de conectividade.

Tarefas:

1. [Azure CLI] Crie um Azure Container Registry chamado nxracrprduse01 (sem hífens, globalmente único) no resource group nxr-rg-prd-use-01, SKU Basic, com admin user habilitado (--admin-enabled true). Em seguida, use az acr build para construir uma imagem Docker de um Dockerfile local simples (crie um Dockerfile baseado em nginx:alpine que exponha a porta 80) e publicar a imagem no registry com a tag nxr-tracking-api:v1.0.

2. [Azure CLI] Crie um container no Azure Container Instances chamado nxr-aci-prd-use-01 no resource group nxr-rg-prd-use-01, usando a imagem nxracrprduse01.azurecr.io/nxr-tracking-api:v1.0, com --cpu 1, --memory 1.5, porta 80 exposta, e credenciais do registry via --registry-login-server, --registry-username e --registry-password. Confirme que o container está Running após a criação.

3. [Azure CLI] Crie uma VNet chamada nxr-vnet-prd-brs-01 no resource group nxr-rg-prd-brs-01, região brazilsouth, com address space 10.1.0.0/16 e subnet nxr-snet-prd-brs-01 com range 10.1.1.0/24. Em seguida, configure VNet peering bidirecional entre nxr-vnet-prd-use-01 (East US, criada na Etapa 8) e nxr-vnet-prd-brs-01 (Brazil South). Use az network vnet peering create duas vezes, uma para cada direção, com --allow-vnet-access habilitado em ambas.

4. [Azure CLI] Crie um NSG chamado nxr-nsg-prd-use-01 no resource group nxr-rg-net-use-01 com as seguintes regras de entrada (inbound): Allow SSH da faixa 10.0.0.0/8 na porta 22 (prioridade 100), Allow HTTPS de qualquer origem na porta 443 (prioridade 110), Deny All inbound de qualquer origem em qualquer porta (prioridade 4000). Associe o NSG à subnet nxr-snet-prd-use-01 da VNet nxr-vnet-prd-use-01.

5. [Troubleshooting] Configure o VNet peering de nxr-vnet-prd-use-01 para nxr-vnet-prd-brs-01 com --allow-forwarded-traffic false. Em seguida, tente fazer uma requisição HTTP do ACI criado no passo 2 para o IP privado da VM nxr-vm-prd-brs-01. A conexão falhará por routing. Use az network watcher check-connectivity para diagnosticar o problema, identificando no resultado qual connectionStatus e issues[0].type são retornados. Corrija o peering atualizando --allow-forwarded-traffic true e verifique novamente.

[Azure CLI] Provisione o Azure Bastion no resource group nxr-rg-net-use-01 com o nome nxr-bas-prd-use-01, SKU Standard, associado à VNet nxr-vnet-prd-use-01. Crie previamente a subnet obrigatória chamada AzureBastionSubnet com range 10.0.2.0/27 (mínimo exigido pelo Bastion) dentro da VNet. Use az network bastion create.

[Portal Azure] Após o Bastion estar provisionado, acesse o blade "Network Watcher" na subscription e clique em "Topology". Selecione a subscription, o resource group nxr-rg-prd-use-01 e a VNet nxr-vnet-prd-use-01. Observe o grafo de topologia gerado, identificando VMs, NICs, NSGs, Public IPs e o Bastion, e suas conexões. Identifique visualmente qual subnet está protegida pelo NSG nxr-nsg-prd-use-01.

Registro de Variáveis:

Valor	Onde Encontrar	Onde será Usado
Nome do ACR nxracrprduse01	Criado nesta etapa	Etapa 13
FQDN do ACI nxr-aci-prd-use-01	az container show --name nxr-aci-prd-use-01 --resource-group nxr-rg-prd-use-01 --query ipAddress.fqdn	Teste de integração
NSG ID nxr-nsg-prd-use-01	az network nsg show --name nxr-nsg-prd-use-01 --resource-group nxr-rg-net-use-01 --query id	Etapa 13
VNet ID nxr-vnet-prd-brs-01	az network vnet show --name nxr-vnet-prd-brs-01 --resource-group nxr-rg-prd-brs-01 --query id	Etapas 11, 13

# Variáveis da Etapa 10
ACR_NAME="nxracrprduse01"
ACI_NAME="nxr-aci-prd-use-01"
ACI_FQDN=""
VNET_PRD_BRS_NAME="nxr-vnet-prd-brs-01"
VNET_PRD_BRS_ID=""
NSG_PRD_USE_ID=""
BASTION_NAME="nxr-bas-prd-use-01"

Critérios de Sucesso:

1. az container show --name nxr-aci-prd-use-01 --resource-group nxr-rg-prd-use-01 --query instanceView.state retorna "Running".
2. az network vnet peering show --name <peering_name> --vnet-name nxr-vnet-prd-use-01 --resource-group nxr-rg-prd-use-01 --query peeringState retorna "Connected".
3. az network nsg rule list --nsg-name nxr-nsg-prd-use-01 --resource-group nxr-rg-net-use-01 --query "[?priority==\4000`].access"retorna["Deny"]`.
4. az network vnet subnet show --vnet-name nxr-vnet-prd-use-01 --resource-group nxr-rg-prd-use-01 --name nxr-snet-prd-use-01 --query networkSecurityGroup.id retorna o ID do NSG nxr-nsg-prd-use-01 (não vazio).
5. az network bastion show --name nxr-bas-prd-use-01 --resource-group nxr-rg-net-use-01 --query provisioningState retorna "Succeeded".

Controle de Custos: Azure Bastion Standard gera custo por hora, mesmo sem conexões ativas (USD ~0.19/hora). Após os testes de conectividade, execute az network bastion delete --name nxr-bas-prd-use-01 --resource-group nxr-rg-net-use-01 para eliminar o custo. O Bastion pode ser recriado rapidamente na Etapa 13 se necessário. ACI em estado Running gera custo por CPU/memória por segundo.

---

Etapa 11: Configure DNS, Load Balancer, Service Endpoints e Private Endpoints

Contexto de Negócios: A API de rastreamento da Nexora precisa de um ponto de entrada com alta disponibilidade e nome DNS amigável. O arquiteto definiu que o balanceamento de carga do tráfego interno deve usar um Internal Load Balancer (para comunicação entre os serviços internos) e que o acesso ao storage account de logs deve ser restrito apenas à VNet de produção via Private Endpoint, eliminando a exposição pública. O time de DNS precisa configurar zonas privadas para resolução interna de nomes.

Ambiente de Execução:

Grupo de Tarefas	Ambiente	Justificativa
Zona DNS privada	Azure CLI (az network private-dns zone create)	Provisionamento de DNS
Link de VNet ao DNS privado	Azure CLI	Vinculação programática
Internal Load Balancer	Azure CLI (az network lb create)	Provisionamento de rede
Backend pool e health probe	Azure CLI	Configuração de LB
Private Endpoint para storage	Azure CLI (az network private-endpoint create)	Segurança de acesso a PaaS
Service Endpoint para subnet	Azure CLI (az network vnet subnet update --service-endpoints)	Alternativa a private endpoint
Diagnóstico de Load Balancer	Portal Azure, blade "Load balancer" com "Diagnose and solve problems"	O diagnóstico guiado de LB com insights de health probe e session persistence tem valor pedagógico visual

Estimativa: 75 a 90 minutos. Load Balancer Standard e Private Endpoint geram custo contínuo.

Tarefas:

1. [Azure CLI] Crie uma zona DNS privada chamada nexora.internal e vincule-a às VNets nxr-vnet-prd-use-01 e nxr-vnet-prd-brs-01 com auto-registration habilitado (--registration-enabled true). Use az network private-dns zone create e az network private-dns link vnet create. Crie um registro A manual na zona nexora.internal apontando api-tracking para 10.0.1.10 (IP reservado para o LB na próxima tarefa).

2. [Azure CLI] Crie um Internal Load Balancer chamado nxr-lb-prd-use-01 (SKU Standard) no resource group nxr-rg-net-use-01, zona 1, com frontend IP estático 10.0.1.10 associado à subnet nxr-snet-prd-use-01 da VNet nxr-vnet-prd-use-01. Crie um backend pool chamado nxr-lb-be-tracking, um health probe HTTP na porta 80 com intervalo de 15 segundos e threshold de 2 falhas, e uma load balancing rule na porta 80 para 80 com session persistence None.

3. [Azure CLI] Adicione as NICs das VMs nxr-vm-prd-use-01 ao backend pool nxr-lb-be-tracking. Use az network nic ip-config address-pool add com o --lb-name, --address-pool e --nic-name corretos. Confirme que a VM está no pool com az network lb address-pool show.

4. [Azure CLI] Configure um Private Endpoint chamado nxr-pe-sa-logs-01 no resource group nxr-rg-prd-use-01 para o storage account nxrsaprduse01, subresource blob, dentro da subnet nxr-snet-prd-use-01 da VNet nxr-vnet-prd-use-01. Use az network private-endpoint create com --group-ids blob e --connection-name nxr-pec-sa-logs-01. Após a criação, aprove a conexão com az network private-endpoint-connection approve.

5. [Troubleshooting] Após criar o Private Endpoint para o storage account, o acesso ao blob via endpoint público (https://nxrsaprduse01.blob.core.windows.net) ainda funciona de fora da VNet. Isso não é o comportamento desejado pela política de segurança da Nexora. Identifique qual configuração adicional precisa ser aplicada no storage account para negar o acesso público e permitir apenas o tráfego via Private Endpoint. Aplique a configuração usando az storage account update com o flag correto e confirme que o acesso público retorna HTTP 403 enquanto o acesso via Private Endpoint (de dentro da VNet, via ACI) continua funcional.

[Portal Azure] Após o Load Balancer estar configurado, acesse o blade do LB nxr-lb-prd-use-01 e clique em "Diagnose and solve problems". Navegue pelos diagnósticos disponíveis e verifique o status do health probe para o backend pool. Observe o painel de "Backend health" e identifique se os backends estão Healthy ou Unhealthy, e qual seria a causa mais comum para estado Unhealthy neste cenário (NSG bloqueando a porta do health probe).

Registro de Variáveis:

Valor	Onde Encontrar	Onde será Usado
IP do LB frontend 10.0.1.10	Definido na criação	Testes de integração end-to-end
FQDN api-tracking.nexora.internal	Registro A criado	Testes de DNS
ID do Private Endpoint	az network private-endpoint show --name nxr-pe-sa-logs-01 --resource-group nxr-rg-prd-use-01 --query id	Etapa 13

# Variáveis da Etapa 11
DNS_ZONE="nexora.internal"
LB_NAME="nxr-lb-prd-use-01"
LB_FRONTEND_IP="10.0.1.10"
PE_SA_LOGS_ID=""

Critérios de Sucesso:

1. az network private-dns zone show --name nexora.internal --resource-group nxr-rg-net-use-01 --query id retorna um ID não vazio.
2. az network lb backend-address-pool show --lb-name nxr-lb-prd-use-01 --resource-group nxr-rg-net-use-01 --name nxr-lb-be-tracking --query backendIPConfigurations | length(@) retorna 1 (ou mais se múltiplas VMs foram adicionadas).
3. az network private-endpoint show --name nxr-pe-sa-logs-01 --resource-group nxr-rg-prd-use-01 --query provisioningState retorna "Succeeded".
4. az storage account show --name nxrsaprduse01 --query publicNetworkAccess retorna "Disabled".
5. az network private-dns record-set a show --zone-name nexora.internal --resource-group nxr-rg-net-use-01 --name api-tracking --query aRecords[0].ipv4Address retorna "10.0.1.10".

Controle de Custos: Load Balancer Standard gera custo por regra e por hora de disponibilidade (~USD 0.025/hora base). Private Endpoint gera custo por hora e por GB processado. Mantenha o LB e PE ativos para os testes de integração da Etapa 13 e validação global.

---

Etapa 12: App Service, Azure Container Apps e Configurações Avançadas

Contexto de Negócios: O portal web da Nexora para clientes finais (consulta de status de entrega) precisa ser hospedado em Azure App Service com certificado TLS customizado, deployment slots para zero-downtime deployment e backup automatizado. O microserviço de API de rastreamento foi migrado do ACI para Container Apps para suporte a escalamento baseado em eventos HTTP (KEDA). A área de plataforma precisa validar os deployment slots antes do go-live.

Ambiente de Execução:

Grupo de Tarefas	Ambiente	Justificativa
Criação de App Service Plan e App	Azure CLI	Provisionamento padrão
Configuração de TLS e certificado	Azure CLI (az webapp config ssl)	Gerenciamento de certificados
Deployment slots	Azure CLI + Portal para slot swap	O swap de slots com "Sticky settings" e a visualização do tráfego em roteamento percentual têm valor pedagógico visual que a CLI não replica
Backup de App Service	Azure CLI (az webapp config backup)	Configuração de política de backup
Container Apps Environment e App	Azure CLI (az containerapp)	Provisionamento de Container Apps
Escalamento de Container Apps	Azure CLI	Configuração de scaling rules

Estimativa: 70 a 85 minutos. App Service Plan P1v3 gera custo contínuo (~USD 0.077/hora). Container Apps Environment gera custo por vCPU/memória por segundo de execução.

Tarefas:

1. [Azure CLI] Crie um App Service Plan chamado nxr-asp-prd-use-01 no resource group nxr-rg-prd-use-01, SKU P1v3, OS Linux, região eastus. Em seguida, crie um Web App chamado nxr-app-prd-use-01 (globalmente único, adicione sufixo numérico se necessário) no mesmo resource group, associado ao plan criado, runtime NODE:18-lts.

2. [Azure CLI] Configure um deployment slot chamado staging para o App nxr-app-prd-use-01 usando az webapp deployment slot create. Configure as app settings ENVIRONMENT=staging e API_ENDPOINT=https://staging.nexora.internal no slot de staging (não no slot de produção), usando az webapp config appsettings set --slot staging.

3. [Azure CLI] Configure o backup automático do App Service nxr-app-prd-use-01 para o storage account nxrsashareduse01, container scripts, com frequência de 24 horas e retenção de 30 dias. Use az webapp config backup update com os parâmetros --backup-name, --frequency, --retain-period-days e --storage-account-url (SAS URL do container). Para gerar a SAS URL do container, use az storage container generate-sas com permissões rwdl e adicione o resultado à URL base do container.

4. [Azure CLI] Crie um Container Apps Environment chamado nxr-cae-prd-use-01 no resource group nxr-rg-prd-use-01 integrado à subnet nxr-snet-prd-use-01 (usando --infrastructure-subnet-resource-id). Em seguida, crie um Container App chamado nxr-ca-tracking-api-01 usando a imagem nxracrprduse01.azurecr.io/nxr-tracking-api:v1.0, com ingress externo na porta 80, min replicas 1, max replicas 5, e uma scaling rule baseada em HTTP com threshold de 100 concurrent requests.

5. [Troubleshooting] Tente criar o Container Apps Environment com a flag --internal-only true sem ter uma subnet dedicada com delegação correta. O erro indicará que o subnet não tem o tamanho mínimo necessário ou a delegação Microsoft.App/environments ausente. Identifique a subnet que precisa ser criada (mínimo /27 para ambientes de workload profiles, ou /23 para Consumption), crie uma nova subnet nxr-snet-cae-use-01 com range 10.0.3.0/23 na VNet nxr-vnet-prd-use-01, e recrie o ambiente apontando para a nova subnet.

[Portal Azure] Após ambos os slots (production e staging) estarem disponíveis, acesse o blade do App Service nxr-app-prd-use-01 e clique em "Deployment slots". Execute um swap entre staging e production pelo portal. Observe o painel de "Swap" que mostra as configurações sticky vs. non-sticky e a prévia das mudanças antes da confirmação. Após o swap, verifique que a app setting ENVIRONMENT no slot de produção passou a ser staging (confirmando o swap) e reaplique as settings corretas para cada slot.

Registro de Variáveis:

Valor	Onde Encontrar	Onde será Usado
URL do App Service	az webapp show --name nxr-app-prd-use-01 --resource-group nxr-rg-prd-use-01 --query defaultHostName	Testes de integração
FQDN do Container App	az containerapp show --name nxr-ca-tracking-api-01 --resource-group nxr-rg-prd-use-01 --query properties.configuration.ingress.fqdn	Testes de integração

# Variáveis da Etapa 12
APP_SERVICE_NAME="nxr-app-prd-use-01"
APP_SERVICE_HOSTNAME=""
CAE_NAME="nxr-cae-prd-use-01"
CA_TRACKING_FQDN=""

Critérios de Sucesso:

1. az webapp show --name nxr-app-prd-use-01 --resource-group nxr-rg-prd-use-01 --query state retorna "Running".
2. az webapp deployment slot list --name nxr-app-prd-use-01 --resource-group nxr-rg-prd-use-01 --query "[0].name" retorna "staging".
3. az webapp config backup list --webapp-name nxr-app-prd-use-01 --resource-group nxr-rg-prd-use-01 --query "[0].storageAccountUrl" retorna uma URL não vazia apontando para nxrsashareduse01.
4. az containerapp show --name nxr-ca-tracking-api-01 --resource-group nxr-rg-prd-use-01 --query properties.provisioningState retorna "Succeeded".
5. curl -s -o /dev/null -w "%{http_code}" "https://${CA_TRACKING_FQDN}" retorna 200 (nginx default page do container).

Controle de Custos: O App Service Plan P1v3 gera custo contínuo independente do tráfego. Após os testes, considere fazer az appservice plan update --sku F1 para o tier gratuito (com limitações) ou deletar o plan após a validação. O Container Apps Environment em modo Consumption gera custo apenas durante execução. Mantenha o App Service ativo para a validação global.

---

Etapa 13: Monitor, Backup, Site Recovery e Alertas

Contexto de Negócios: Com toda a infraestrutura da Nexora provisionada, o time de operações precisa da visibilidade completa sobre o estado do ambiente: métricas das VMs e do storage, logs de auditoria centralizados no Log Analytics, alertas para incidentes críticos e uma estratégia de backup e recuperação de desastres para as VMs de produção. O RTO definido pela área de negócio é de 4 horas e o RPO é de 24 horas para as VMs de produção.

Ambiente de Execução:

Grupo de Tarefas	Ambiente	Justificativa
Criação de Log Analytics Workspace	Azure CLI	Provisionamento padrão
Configuração de Diagnostic Settings	Azure CLI (az monitor diagnostic-settings create)	Automação de configuração
Criação de alertas e action groups	Azure CLI (az monitor action-group create e az monitor alert create)	Provisionamento de alertas
Consultas KQL no Log Analytics	Portal Azure, blade "Log Analytics Workspace - Logs"	O editor de KQL com IntelliSense, histórico de queries e visualização inline de resultados é o ambiente canônico para análise de logs do exame
Métricas e Insights de VM	Portal Azure, blade "Azure Monitor - Insights - VM"	O painel de VM Insights com mapas de dependência e correlação entre métricas tem valor pedagógico visual específico do exame
Recovery Services Vault e backup	Azure CLI + PowerShell	Configuração de política
Site Recovery para regiões	Portal Azure, blade "Site Recovery"	O wizard de configuração de replicação para DR, com mapeamento de rede e configuração de failover, tem fluxo guiado com validação de pré-requisitos que é parte central do objetivo do exame

Estimativa: 90 a 110 minutos. Recovery Services Vault, Log Analytics Workspace e Site Recovery geram custo contínuo. Maior impacto financeiro: Site Recovery (por VM protegida, ~USD 25/mês).

Tarefas:

1. [Azure CLI] Crie um Log Analytics Workspace chamado nxr-law-shared-use-01 no resource group nxr-rg-mon-use-01, região eastus, retention de 30 dias. Configure diagnostic settings para: (a) a VM nxr-vm-prd-use-01 enviando métricas e logs de performance para o workspace, usando az monitor diagnostic-settings create --resource <VM_ID>; (b) o storage account nxrsaprduse01 enviando logs de StorageRead, StorageWrite e StorageDelete para o workspace; (c) o NSG nxr-nsg-prd-use-01 enviando NetworkSecurityGroupFlowEvent para o workspace (Flow Logs via Network Watcher).

2. [Azure CLI] Crie um Action Group chamado nxr-ag-ops-use-01 no resource group nxr-rg-mon-use-01 com um receiver do tipo email para lab-admin@<tenant>.onmicrosoft.com. Em seguida, crie as seguintes alert rules:

   • nxr-alert-vm-cpu-high: CPU Percentage > 80% por 5 minutos na VM nxr-vm-prd-use-01, severity 2.
   • nxr-alert-storage-capacity: Used capacity do storage account nxrsaprduse01 > 80 GiB, severity 3. Use az monitor metrics alert create com os parâmetros --condition, --window-size, --severity e --action.

3. [Portal Azure] Acesse o blade "Log Analytics Workspace" > workspace nxr-law-shared-use-01 > "Logs". Execute as seguintes queries KQL para validar a ingestão de dados (aguarde 10 a 15 minutos após a configuração dos diagnostic settings para que os dados comecem a aparecer):

   • Query 1: Liste as últimas 10 entradas da tabela AzureMetrics filtradas por ResourceId contendo nxr-vm-prd-use-01.
   • Query 2: Agregue o Maximum de CounterValue da tabela Perf onde CounterName seja "% Processor Time", agrupado por bin(TimeGenerated, 5m).
   • Query 3: Conte eventos por OperationName na tabela StorageBlobLogs das últimas 24 horas, ordenado por contagem decrescente.

4. [Azure CLI] Crie um Recovery Services Vault chamado nxr-rsv-prd-use-01 no resource group nxr-rg-prd-use-01, região eastus. Configure uma backup policy customizada chamada nxr-bp-vm-daily com backup diário às 02:00 UTC, retenção de pontos diários de 30 dias, pontos semanais (segunda-feira) de 4 semanas. Use az backup policy create com o tipo AzureIaasVM e o JSON da policy. Em seguida, habilite o backup da VM nxr-vm-prd-use-01 usando az backup protection enable-for-vm apontando para o vault e a policy criada. Execute um backup inicial sob demanda com az backup protection backup-now.

5. [Troubleshooting] Ao tentar configurar o backup da VM nxr-vm-prd-use-01 no vault nxr-rsv-prd-use-01, o comando retorna o erro VMAndVaultInDifferentLocations ou o backup é registrado mas o job falha com ExtensionSnapshotFailedNoSecureNetwork. Diagnostique a causa: o vault e a VM precisam estar na mesma região, e a VM precisa ter o agente VM instalado e o acesso de rede ao serviço de backup não bloqueado pelo NSG. Verifique a regra do NSG que pode estar bloqueando o endpoint *.backup.windowsazure.com e adicione uma Service Tag AzureBackup como source de uma regra Allow outbound no NSG.

[Portal Azure] Após o vault e o backup da VM estarem configurados, acesse o blade "Site Recovery" dentro do vault nxr-rsv-prd-use-01. Clique em "Replicate" e configure a replicação da VM nxr-vm-prd-use-01 (East US) para a região brazilsouth. Mapeie as redes: VNet de origem nxr-vnet-prd-use-01 para VNet de destino nxr-vnet-prd-brs-01. Configure a política de replicação com RPO de 24 horas e retenção de pontos de recuperação de 48 horas. Inicie a replicação e observe o progresso no painel "Replicated items".

Registro de Variáveis:

Valor	Onde Encontrar	Onde será Usado
LAW ID	az monitor log-analytics workspace show --workspace-name nxr-law-shared-use-01 --resource-group nxr-rg-mon-use-01 --query id	Validação global
RSV ID	az backup vault show --name nxr-rsv-prd-use-01 --resource-group nxr-rg-prd-use-01 --query id	Validação global

# Variáveis da Etapa 13
LAW_NAME="nxr-law-shared-use-01"
LAW_ID=""
RSV_NAME="nxr-rsv-prd-use-01"
RSV_ID=""
ACTION_GROUP_NAME="nxr-ag-ops-use-01"

Critérios de Sucesso:

1. az monitor log-analytics workspace show --workspace-name nxr-law-shared-use-01 --resource-group nxr-rg-mon-use-01 --query provisioningState retorna "Succeeded".
2. az monitor diagnostic-settings list --resource ${VM_PRD_USE_ID} --query "[0].workspaceId" retorna o ID do workspace nxr-law-shared-use-01.
3. az monitor metrics alert list --resource-group nxr-rg-mon-use-01 --query "[].name" retorna os dois alert names criados.
4. az backup item list --vault-name nxr-rsv-prd-use-01 --resource-group nxr-rg-prd-use-01 --backup-management-type AzureIaasVM --query "[0].properties.lastBackupStatus" retorna "Completed" (após o backup sob demanda concluir).
5. az backup job list --vault-name nxr-rsv-prd-use-01 --resource-group nxr-rg-prd-use-01 --query "[?properties.jobType=='BackupJob'].properties.status" retorna pelo menos um job com status "Completed".

Controle de Custos: Site Recovery gera ~USD 25/mês por VM protegida. Se o orçamento for limitado, cancele a replicação após confirmar que o wizard foi concluído com sucesso, antes que a replicação inicial (que gera custo de storage e egress) seja completada. O RSV com backup diário gera custo por GB de dados protegidos. O Log Analytics workspace gera custo por GB ingerido (tier Pay-Per-Use) após os primeiros 5 GB gratuitos mensais.

---

4. Validação Global do Ambiente

Checklist de Recursos Provisionados

Nome do Recurso	Categoria	Status Esperado
nxr-rg-shared-use-01	Resource Group	Active
nxr-rg-prd-use-01	Resource Group	Active, CanNotDelete lock
nxr-rg-net-use-01	Resource Group	Active
nxr-rg-prd-brs-01	Resource Group	Active, CanNotDelete lock
nxr-rg-mon-use-01	Resource Group	Active
ana.lima	Microsoft Entra User	Enabled, Licensed
carlos.mendes	Microsoft Entra User	Enabled, Licensed
john.carter	Microsoft Entra User	Enabled, Licensed
sarah.kim	Microsoft Entra User	Enabled, Licensed
rapido.operacoes	Microsoft Entra Guest	Active, userType=Guest
nxr-grp-infra-admins	Security Group	Active
nxr-grp-net-engineers	Security Group	Active
SSPR Policy	Authentication Policy	Enabled (scoped to nxr-grp-infra-admins)
nxr-policy-allowed-regions	Policy Definition	Custom, Assigned at Subscription
nxr-initiative-baseline-security	Policy Initiative	Assigned at Subscription
nxr-mg-root	Management Group	Active
nxr-mg-brasil	Management Group	Child of nxr-mg-root
nxr-mg-transroute	Management Group	Child of nxr-mg-root
nxr-budget-monthly-use	Cost Budget	Active, $500/month
nxrsaprduse01	Storage Account	GRS, TLS1.2, Public Access Disabled
nxrsashareduse01	Storage Account	LRS, TLS1.2
nxrsaprdbrs01	Storage Account	ZRS, TLS1.2
nxr-fs-dist-centers	File Share	Active, 100 GiB
logs container	Blob Container	Private access
tracking-exports container	Blob Container	Blob access
nxr-vm-prd-use-01	Virtual Machine	Deallocated or Running
nxr-disk-prd-use-01	Managed Disk	Attached to VM
nxr-vm-prd-brs-01	Virtual Machine	Deallocated or Running
nxr-vmss-prd-use-01	VM Scale Set	Active, 2 instances
nxracrprduse01	Container Registry	Basic SKU, Active
nxr-aci-prd-use-01	Container Instance	Running
nxr-cae-prd-use-01	Container Apps Environment	Succeeded
nxr-ca-tracking-api-01	Container App	Running
nxr-vnet-prd-use-01	Virtual Network	Active, peered to BRS
nxr-vnet-prd-brs-01	Virtual Network	Active, peered to USE
nxr-nsg-prd-use-01	Network Security Group	Attached to subnet
nxr-bas-prd-use-01	Azure Bastion	Succeeded (or deleted after use)
nxr-lb-prd-use-01	Load Balancer	Standard SKU, Active
nexora.internal	Private DNS Zone	Linked to both VNets
nxr-pe-sa-logs-01	Private Endpoint	Succeeded
nxr-asp-prd-use-01	App Service Plan	P1v3, Linux
nxr-app-prd-use-01	App Service	Running, slot staging
nxr-law-shared-use-01	Log Analytics Workspace	Succeeded, 30-day retention
nxr-rsv-prd-use-01	Recovery Services Vault	Succeeded
nxr-ag-ops-use-01	Action Group	Active
nxr-alert-vm-cpu-high	Metric Alert	Active, severity 2
nxr-alert-storage-capacity	Metric Alert	Active, severity 3

Testes de Integração End-to-End

Teste 1: Resolução de DNS privado e conectividade via Load Balancer

Fluxo: De dentro da VM nxr-vm-prd-use-01 (acesse via Bastion), resolva o nome api-tracking.nexora.internal e valide que o IP retornado é 10.0.1.10.

Comando a executar (dentro da VM): nslookup api-tracking.nexora.internal

Resultado esperado: A resposta do servidor DNS privado deve retornar 10.0.1.10 como endereço A, e o servidor responsivo deve ser um dos nameservers da zona nexora.internal.

Teste 2: Acesso ao blob via Private Endpoint com acesso público negado

Fluxo: De uma máquina fora da VNet (workstation local), tente acessar o blob test-log.txt no storage account nxrsaprduse01 via URL pública. Em seguida, acesse o mesmo blob de dentro da VM nxr-vm-prd-use-01 via Private Endpoint.

Comandos: curl -s -o /dev/null -w "%{http_code}" "https://nxrsaprduse01.blob.core.windows.net/logs/test-log.txt?<SAS_TOKEN>" (de fora) e az storage blob download --account-name nxrsaprduse01 --container-name logs --name test-log.txt --auth-mode login (de dentro da VM).

Resultado esperado: Acesso externo retorna 403 ou ResourceNotFound (storage firewall ativo). Acesso interno via Private Endpoint retorna sucesso com conteúdo do blob.

Teste 3: Verificação de backup completo e integridade do job

Fluxo: Confirme que o backup sob demanda da VM nxr-vm-prd-use-01 foi completado com sucesso e que o ponto de recuperação está disponível.

Comando: az backup recovery-point list --vault-name nxr-rsv-prd-use-01 --resource-group nxr-rg-prd-use-01 --container-name <container_name> --item-name nxr-vm-prd-use-01 --workload-type VM --query "[0].{name:name, time:properties.recoveryPointTime, type:properties.recoveryPointType}"

Resultado esperado: Retorna pelo menos um ponto de recuperação com recoveryPointType igual a "AppConsistent" ou "CrashConsistent" e timestamp dentro das últimas 24 horas.

Teste 4: RBAC, escopo e herança de permissões

Fluxo: Valide que o usuário carlos.mendes (membro de nxr-grp-net-engineers) tem Network Contributor no nxr-rg-net-use-01 e Reader no nxr-rg-prd-use-01, mas nenhuma permissão no nxr-rg-prd-brs-01.

Comandos:

az role assignment list --assignee ${CARLOS_MENDES_ID} --all --query "[].{scope:scope, role:roleDefinitionName}"

Resultado esperado: Retorna exatamente duas entradas, uma com scope /subscriptions/.../resourceGroups/nxr-rg-net-use-01 e role Network Contributor, e outra com scope /subscriptions/.../resourceGroups/nxr-rg-prd-use-01 e role Reader. Nenhuma entrada com scope do nxr-rg-prd-brs-01.

Teste 5: Alert rule acionada e action group notificado

Fluxo: Estresse a CPU da VM nxr-vm-prd-use-01 para acionar o alert nxr-alert-vm-cpu-high. Conecte-se via Bastion e execute stress --cpu 2 --timeout 600 (instale via apt install stress). Aguarde 10 minutos e verifique se o alerta foi disparado.

Comando de verificação: az monitor activity-log alert list --resource-group nxr-rg-mon-use-01--query "[?contains(name,'cpu-high')].{name:name, condition:condition.allOf[0].field}" e az monitor metrics alert list --resource-group nxr-rg-mon-use-01 --query "[?name=='nxr-alert-vm-cpu-high'].{firedTime:lastModifiedTime, status:enabled}"

Resultado esperado: O alert aparece como enabled: true e um email é recebido no endereço configurado no Action Group dentro de 5 minutos após a CPU ultrapassar 80%.

Tabela de Troubleshooting

Sintoma	Causa Provável	Solução Esperada
az vm create falha com RequestDisallowedByPolicy	Policy de região bloqueando a location especificada	Verificar az policy assignment list e confirmar a region contra as allowed locations da policy nxr-policy-allowed-regions
VNet peering em estado Disconnected	Peering criado apenas em uma direção	Criar o peering na direção oposta com az network vnet peering create na VNet de destino
Backup job falha com ExtensionSnapshotFailedNoSecureNetwork	NSG bloqueando o tráfego de saída para o serviço de backup	Adicionar regra Allow outbound com Service Tag AzureBackup no NSG associado à NIC da VM
az storage blob upload falha com AuthorizationFailure	Conta autenticada não tem role Storage Blob Data Contributor no storage account	Atribuir role Storage Blob Data Contributor à identidade via az role assignment create no escopo do storage account
Container App não inicia e retorna erro de imagem	ACR sem acesso configurado para o Container Apps Environment	Habilitar identidade gerenciada no Container App e atribuir role AcrPull no ACR
Private Endpoint criado mas DNS resolve para IP público	Zona DNS privada não vinculada à VNet ou registro A automático não criado	Verificar link da zona privatelink.blob.core.windows.net à VNet e confirmar que o NIC do PE tem IP privado registrado na zona
SSPR falha com Authentication method not satisfied	Usuário não completou o registro dos métodos de autenticação obrigatórios	Redirecionar usuário para https://aka.ms/mfasetup para completar o registro de MFA e dos métodos de SSPR
az role assignment create falha com PrincipalNotFound	Object ID passado no --assignee-object-id está incorreto ou o principal não existe no tenant	Verificar o ID com az ad user show ou az ad group show antes de criar a atribuição
VM Scale Set não escala apesar de CPU elevada	Regras de autoscale não configuradas ou métricas com lag de avaliação	Verificar az monitor autoscale rule list e aguardar o período de cooldown (mínimo 5 minutos) entre operações de escala
az network bastion create falha com SubnetNotFound	Subnet AzureBastionSubnet não existe ou tem nome incorreto (case-sensitive)	Criar a subnet com exatamente o nome AzureBastionSubnet (sem variações) com range mínimo /26
Log Analytics não ingere dados após configurar diagnostic settings	Latência de ingestão (até 15 minutos) ou workspace em região diferente da VM	Aguardar 15 minutos e executar query KQL verificando `AzureMetrics
az backup recovery-point list retorna lista vazia	Backup inicial ainda em execução ou job falhou silenciosamente	Verificar status do job com az backup job list --status InProgress e aguardar a conclusão

Diagrama da Arquitetura Final

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular