[AZ-104] Grand Labs - NexaCore Sistemas S.A.

Ambiente Cumulativo de Implantação Real

---

1. O Cenário (Narrativa Central)

Empresa: NexaCore Sistemas S.A.

Setor: Tecnologia Financeira (Fintech), com atuação em processamento de pagamentos, análise de crédito e plataformas de open banking para instituições de médio porte no Brasil e América Latina.

Contexto do Problema:

A NexaCore opera atualmente com infraestrutura híbrida, combinando data centers próprios em São Paulo e um ambiente Azure legado criado sem governança centralizada, sem políticas de nomenclatura e com controle de acesso baseado exclusivamente em permissões de Proprietário atribuídas diretamente a usuários individuais. O crescimento acelerado da empresa resultou em proliferação de recursos órfãos, custos imprevisíveis, ausência de segregação de ambientes e falhas recorrentes de conformidade regulatória (BACEN, LGPD).

O conselho executivo aprovou um projeto de modernização e consolidação da plataforma Azure, com os seguintes requisitos técnicos macros:

• Implementar governança centralizada com hierarquia de grupos de gerenciamento, políticas obrigatórias e controle de custos.
• Estabelecer identidade corporativa unificada no Microsoft Entra ID, com licenciamento adequado, acesso condicional e recuperação de senha automatizada.
• Implantar infraestrutura de rede segmentada em duas regiões (East US como primária, Brazil South como secundária de DR), com peering, DNS privado, NSGs e endpoints privados.
• Provisionar storage corporativo com redundância, controle de acesso granular, ciclo de vida de objetos e replicação entre regiões.
• Implantar workloads de computação (VMs, Scale Sets, Container Apps, App Service) com alta disponibilidade e automação via IaC (Bicep).
• Configurar monitoramento unificado, backup e recuperação de desastres.

Todo recurso provisionado neste laboratório deve seguir a convenção de nomenclatura da NexaCore:

nxc-{tipo}-{ambiente}-{regiao}-{sequencial}

Exemplos: nxc-vnet-prod-eus-001, nxc-vm-prod-brs-001, nxc-st-prod-eus-001.

---

2. Ponto de Partida (Ambiente Inicial)

Recursos Pre-existentes

Recurso	Especificacao	Observacao
Subscription Azure	Pay-As-You-Go ou Visual Studio Enterprise	Permissao de Owner na subscription
Microsoft Entra ID Tenant	Tenant proprio (nao Microsoft Account pessoal)	Tenant sem usuarios convidados configurados
Resource Group legado	rg-legacy-nexacore na region East US	Criado sem tags, sem locks, sera migrado
Maquina local ou VM de gerenciamento	Windows 11 ou Ubuntu 22.04	Para execucao de CLI e scripts

Credenciais Base

Identidade	Tipo	Funcao Inicial
admin@{tenant}.onmicrosoft.com	Conta Global Administrator	Conta de break-glass, nao usar no dia a dia
Conta pessoal do aluno	Membro do tenant	Ponto de partida antes de atribuir roles

Ferramentas Necessarias

Ferramenta	Versao Minima	Finalidade
Azure CLI	2.60.0	Automacao e consultas
Azure PowerShell (Az module)	11.0.0	Administracao de identidade e governance
Bicep CLI	0.26.0	IaC para compute e rede
Azure Storage Explorer	1.34.0	Gerenciamento visual de storage
AzCopy	10.24.0	Transferencia e sincronizacao de dados
VS Code com extensao Bicep	Qualquer recente	Edicao de templates

Diagrama de Topologia Inicial

100%

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

---

3. As Etapas do Laboratório

---

Etapa 1: Configurar Management Groups e Hierarquia de Governança

Contexto de Negocios: Antes de qualquer recurso ser provisionado, a NexaCore precisa estabelecer a estrutura de governanca que controlara todas as subscriptions atuais e futuras. Esta etapa nao tem dependencias de recursos anteriores e serve de base para todas as politicas e roles das etapas seguintes.

Ambiente de Execucao:

Tarefa	Ambiente
Criar hierarquia de management groups	PowerShell
Validar estrutura criada	Portal Azure (Management Groups blade)

Tarefas:

1. [PowerShell] Crie a seguinte hierarquia de Management Groups sob o Root Management Group do tenant: um grupo raiz chamado nxc-mg-root, com dois filhos: nxc-mg-prod e nxc-mg-nonprod. Sob nxc-mg-prod, crie os filhos nxc-mg-prod-brasil e nxc-mg-prod-eua.
2. [Portal] Mova a subscription atual para o Management Group nxc-mg-prod-eua. Aguarde a propagacao e confirme no blade "Management Groups" que a subscription aparece aninhada corretamente.
3. [PowerShell] Verifique o ID completo de cada Management Group criado e registre os valores na tabela de variaveis abaixo. Os IDs serao necessarios para escopo de atribuicao de policies nas proximas etapas.
4. [Portal] No blade "Cost Management + Billing", configure um Budget de USD 500 mensais na subscription, com alertas em 70%, 90% e 100%, enviando notificacoes para o e-mail do administrador. Nomeie o budget como nxc-budget-prod-001.
5. [Portal] Acesse o Azure Advisor e registre quantas recomendacoes de "Cost" e "Security" ja existem na subscription legada. Este numero sera o baseline para comparacao na Etapa de Monitoramento.

Registro de Variaveis:

Valor	Onde Encontrar	Onde sera usado
ID do Management Group nxc-mg-prod	Output do cmdlet Get-AzManagementGroup	Escopo de atribuicao de Azure Policy (Etapa 4)
ID do Management Group nxc-mg-prod-eua	Output do cmdlet Get-AzManagementGroup	Escopo de RBAC (Etapa 3)
ID da Subscription	Portal: Subscriptions blade	Escopo de locks e tags (Etapas 4 e 5)
Budget ID	Portal: Cost Management, Budgets blade	Referencia em alertas (Etapa de Monitoramento)

Criterios de Sucesso:

• O comando Get-AzManagementGroup -Recurse retorna os cinco management groups em arvore.
• A subscription aparece listada sob nxc-mg-prod-eua no Portal.
• O budget nxc-budget-prod-001 aparece com status "Active" em Cost Management.

---

Etapa 2: Criar Usuarios e Grupos no Microsoft Entra ID

Contexto de Negocios: Com a hierarquia de governanca estabelecida na Etapa 1, a NexaCore precisa agora provisionar as identidades corporativas. Os usuarios e grupos criados aqui serao os sujeitos das atribuicoes de RBAC e das politicas de acesso nas etapas subsequentes.

Ambiente de Execucao:

Tarefa	Ambiente
Criar usuarios	PowerShell (Microsoft Graph via Az module)
Criar grupos e atribuir membros	Portal Azure (Microsoft Entra ID blade)
Licenciamento	Portal Azure (Microsoft Entra ID, Licenses blade)

Tarefas:

1. [PowerShell] Crie os seguintes usuarios no tenant, todos com UsageLocation definida como BR e PasswordProfile exigindo troca no primeiro login. Use o prefixo nxc- nos nomes de exibicao:

   UPN	Display Name	Departamento
   ops.lead@{tenant}	NXC Ops Lead	Platform Operations
   dev.lead@{tenant}	NXC Dev Lead	Application Development
   sec.analyst@{tenant}	NXC Sec Analyst	Security
   finance.mgr@{tenant}	NXC Finance Manager	Finance
   ext.partner@{tenant}	NXC External Partner	(externo, B2B)

2. [Portal] Crie tres grupos de seguranca no Microsoft Entra ID: nxc-grp-platform-ops (assigned, Security), nxc-grp-developers (assigned, Security) e nxc-grp-finance (assigned, Security). Adicione ops.lead ao grupo de ops, dev.lead ao grupo de developers e finance.mgr ao grupo de finance.

3. [Portal] No blade "Licenses", atribua uma licenca Microsoft Entra ID P2 ao grupo nxc-grp-platform-ops e ao usuario sec.analyst. Confirme que o estado de licenciamento propagou para os membros do grupo antes de prosseguir.

4. [Portal] Configure o usuario ext.partner como usuario convidado (B2B). Verifique qual e o UserType resultante no perfil do usuario e registre a diferenca comportamental em relacao a um membro interno nas restricoes de acesso padrao do tenant.

5. [PowerShell] Consulte via cmdlet todos os usuarios cujo Department e igual a Platform Operations e confirme que apenas ops.lead retorna. Este teste valida o atributo que sera usado como filtro em grupos dinamicos em etapas futuras.

Registro de Variaveis:

Valor	Onde Encontrar	Onde sera usado
Object ID do grupo nxc-grp-platform-ops	Entra ID, Groups, Overview do grupo	Atribuicao de RBAC (Etapa 3)
Object ID do grupo nxc-grp-developers	Entra ID, Groups, Overview do grupo	Atribuicao de RBAC (Etapa 3)
Object ID do usuario sec.analyst	Entra ID, Users, Overview do usuario	Atribuicao de role de Reader (Etapa 3)
Object ID do usuario ext.partner	Entra ID, Users, Overview do usuario	Teste de acesso restrito (Etapa 3)

Criterios de Sucesso:

• O comando Get-AzADUser -Filter "Department eq 'Platform Operations'" retorna exatamente um usuario.
• O blade "Licenses" mostra os membros de nxc-grp-platform-ops com a licenca P2 herdada do grupo (coluna "Assignment path" indica "Inherited").
• O usuario ext.partner tem UserType igual a Guest no portal.

---

Etapa 3: Gerenciar Acesso com RBAC (Built-in Roles e Escopos)

Contexto de Negocios: Com os usuarios e grupos provisionados na Etapa 2, a NexaCore precisa aplicar o principio de menor privilegio. Os grupos receberao permissoes estritamente necessarias para suas funcoes, nos escopos corretos da hierarquia criada na Etapa 1.

Ambiente de Execucao:

Tarefa	Ambiente
Atribuir roles	CLI (az role assignment create)
Verificar atribuicoes efetivas	Portal Azure (Access Control IAM blade)
Interpretar heranca de permissoes	Portal Azure (Check Access)

Tarefas:

1. [CLI] Atribua a role Contributor ao grupo nxc-grp-platform-ops no escopo da subscription atual. Atribua a role Reader ao grupo nxc-grp-developers no escopo do Management Group nxc-mg-prod-eua. Atribua a role Cost Management Reader ao grupo nxc-grp-finance no escopo da subscription.
2. [CLI] Atribua a role Security Reader ao usuario sec.analyst no escopo do Management Group nxc-mg-prod (escopo mais amplo que a subscription). Registre como a heranca funciona neste caso.
3. [Portal] Use a funcionalidade "Check Access" no blade "Access Control (IAM)" da subscription para verificar as permissoes efetivas de dev.lead. Explique por que dev.lead tem acesso de Reader mesmo a subscription nao tendo uma atribuicao direta para ele.
4. [CLI] Tente atribuir a role Owner ao usuario ext.partner na subscription e registre o resultado. Em seguida, atribua a role Reader ao mesmo usuario em um Resource Group especifico chamado nxc-rg-shared-eus-001 (crie o Resource Group antes desta sub-tarefa).
5. [Portal] No blade "Access Control (IAM)" da subscription, utilize a aba "Role assignments" filtrada por "Type: Group" e confirme que todas as tres atribuicoes de grupo estao visiveis com os escopos corretos.

Registro de Variaveis:

Valor	Onde Encontrar	Onde sera usado
ID do Resource Group nxc-rg-shared-eus-001	Portal, Resource Groups	Base para recursos de rede compartilhados (Etapa 7)
Assignment ID da role Contributor (ops group)	az role assignment list	Referencia em auditoria (Etapa de Monitoramento)

Criterios de Sucesso:

• az role assignment list --assignee {object-id-ops-group} --scope /subscriptions/{id} retorna exatamente uma atribuicao com roleDefinitionName: Contributor.
• dev.lead consegue listar recursos na subscription mas recebe erro de autorizacao ao tentar criar um Resource Group.
• A tentativa de atribuir Owner a ext.partner na subscription falha ou exige justificativa de PIM (dependendo da configuracao do tenant).

---

Etapa 4: Implementar Azure Policy e Locks

Contexto de Negocios: O audit interno da NexaCore identificou que recursos estao sendo criados sem tags de centro de custo e em regioes nao autorizadas, gerando custos difusos e riscos de compliance. Esta etapa implementa guardrails preventivos e detectivos usando o framework de policies no escopo dos management groups criados na Etapa 1.

Ambiente de Execucao:

Tarefa	Ambiente
Criar e atribuir policies	CLI e Portal Azure
Configurar resource locks	PowerShell
Verificar compliance	Portal Azure (Azure Policy blade)

Tarefas:

1. [Portal] Atribua a policy built-in "Allowed locations" ao Management Group nxc-mg-prod, configurando como localizacoes permitidas apenas eastus e brazilsouth. Defina o modo de enforcement como Enabled. Nomeie a atribuicao nxc-policy-allowed-locations.
2. [Portal] Atribua a policy built-in "Require a tag and its value on resources" duas vezes ao escopo da subscription: uma para exigir a tag CostCenter com valor NXC-PROD-001 e outra para exigir a tag Environment com valor Production. Nomeie as atribuicoes nxc-policy-tag-costcenter e nxc-policy-tag-environment.
3. [CLI] Tente criar um Resource Group na regiao westus2 e registre o erro retornado pelo Azure Policy. Este e o cenario de troubleshooting intencional. Em seguida, crie o Resource Group nxc-rg-network-eus-001 na regiao eastus com as tags CostCenter=NXC-PROD-001 e Environment=Production.
4. [PowerShell] Aplique um Resource Lock do tipo ReadOnly no Resource Group nxc-rg-shared-eus-001 criado na Etapa 3. Em seguida, tente criar um recurso qualquer (como uma Public IP) dentro deste RG e registre o comportamento. Depois, aplique um lock do tipo CanNotDelete no Resource Group nxc-rg-network-eus-001.
5. [CLI] Consulte o estado de compliance da policy nxc-policy-tag-costcenter e verifique se o Resource Group rg-legacy-nexacore esta marcado como NonCompliant. Registre o ID do compliance state result para referencia futura.

Registro de Variaveis:

Valor	Onde Encontrar	Onde sera usado
Assignment ID da policy allowed-locations	az policy assignment list	Referencia em remediation tasks
Resource ID do lock no nxc-rg-network-eus-001	Get-AzResourceLock	Verificacao antes de deletar recursos de rede
ID do Resource Group nxc-rg-network-eus-001	Portal, Resource Groups	Todos os recursos de rede (Etapas 7 a 10)

Criterios de Sucesso:

• A tentativa de criar recursos em westus2 retorna RequestDisallowedByPolicy com o nome da policy como causa.
• O Resource Group nxc-rg-shared-eus-001 com lock ReadOnly impede a criacao de novos recursos com mensagem ScopeLocked.
• O blade "Policy Compliance" mostra nxc-rg-legacy-nexacore como Non-compliant para a policy de tags.

---

Etapa 5: Configurar Self-Service Password Reset (SSPR)

Contexto de Negocios: O helpdesk da NexaCore processa mais de 200 tickets mensais de reset de senha, representando custo operacional significativo. A diretoria aprovou a habilitacao de SSPR para todos os usuarios internos licenciados com Entra ID P2 (provisionados e licenciados nas Etapas 2 e 3).

Ambiente de Execucao:

Tarefa	Ambiente
Configurar SSPR	Portal Azure (Microsoft Entra ID, Password reset blade)
Testar fluxo	Portal MyAccount (myaccount.microsoft.com)

Tarefas:

1. [Portal] No blade "Password reset" do Microsoft Entra ID, habilite o SSPR para o grupo nxc-grp-platform-ops. Configure os metodos de autenticacao exigidos como: numero minimo de 2 metodos, com os metodos "Mobile app notification" e "Email" habilitados. Desabilite "Security questions" explicitamente.
2. [Portal] Na aba "Registration", configure para que o registro seja exigido no proximo login e defina o intervalo de reconfirmacao de informacoes de autenticacao como 180 dias.
3. [Portal] Na aba "Notifications", habilite a notificacao ao usuario quando a senha for redefinida E habilite a notificacao aos administradores quando outros administradores redefinirem senhas.
4. [Portal] Na aba "On-premises integration", verifique o estado da integracao com Active Directory local. Registre se o writeback esta disponivel e qual pre-requisito de licenca e infraestrutura seria necessario para habilita-lo em um cenario real.
5. [Portal] Acesse myaccount.microsoft.com com a conta ops.lead e complete o registro dos metodos de autenticacao para SSPR. Em seguida, acesse o portal de reset em aka.ms/sspr e execute um reset de senha para validar o fluxo completo.

Registro de Variaveis:

Valor	Onde Encontrar	Onde sera usado
Status de SSPR habilitado para o grupo	Password reset blade, Properties	Evidencia de compliance para auditoria
Metodos configurados	Password reset blade, Authentication methods	Documentacao de politica de seguranca

Criterios de Sucesso:

• O blade "Password reset" mostra SSPR habilitado com escopo "Selected group: nxc-grp-platform-ops".
• O usuario ops.lead consegue completar o reset de senha via aka.ms/sspr sem intervencao do helpdesk.
• O usuario dev.lead (nao membro do grupo habilitado) recebe mensagem de que SSPR nao esta disponivel para sua conta ao tentar acessar o portal de reset.

---

Etapa 6: Criar e Configurar Storage Accounts

Contexto de Negocios: A NexaCore precisa de uma camada de storage corporativa para tres finalidades distintas: armazenamento de blobs para artefatos de aplicacao e backups, compartilhamento de arquivos para equipes de operacoes, e uma conta de storage separada e geo-redundante para dados regulatorios do BACEN. Os Resource Groups e a politica de regioes definidos nas Etapas 3 e 4 sao pre-requisitos.

Ambiente de Execucao:

Tarefa	Ambiente
Criar storage accounts	CLI
Configurar redundancia e replicacao	Portal Azure
Configurar acesso e SAS	Portal Azure e Storage Explorer

Tarefas:

1. [CLI] Crie dois storage accounts no Resource Group nxc-rg-shared-eus-001: nxcstprodeus001 (Standard, LRS, Hot tier, para artefatos gerais) e nxcstprodeus002 (Standard, GRS, Hot tier, para dados regulatorios). Certifique-se de incluir as tags CostCenter=NXC-PROD-001 e Environment=Production na criacao para evitar violacao da policy da Etapa 4.
2. [Portal] No storage account nxcstprodeus001, crie um container de blob chamado nxc-artifacts com nivel de acesso privado. Em seguida, habilite o blob versioning e configure uma regra de lifecycle management que mova blobs para o tier Cool apos 30 dias e para Archive apos 90 dias. Nomeie a regra nxc-lifecycle-artifacts.
3. [Portal] No storage account nxcstprodeus001, crie um file share chamado nxc-ops-share com quota de 100 GB. Configure a autenticacao baseada em identidade para o file share utilizando Microsoft Entra Kerberos Authentication. Verifique os pre-requisitos e registre quais configuracoes sao necessarias no lado do Entra ID.
4. [Portal] No storage account nxcstprodeus002, configure a replicacao de objetos (object replication) do container nxc-regulatory-data (crie o container antes) para um container de destino no mesmo storage account chamado nxc-regulatory-replica. Registre qual configuracao de versioning e pre-requisito para object replication.
5. [Portal] No storage account nxcstprodeus001, gere um SAS token de nivel de conta com permissoes de Read e List sobre o servico Blob, valido por 24 horas, restrito ao IP publico da sua maquina local. Registre o token gerado (apenas para este exercicio) e em seguida crie uma Stored Access Policy chamada nxc-sap-readonly no container nxc-artifacts com as mesmas permissoes, vinculando um novo SAS de servico a esta policy.

Registro de Variaveis:

Valor	Onde Encontrar	Onde sera usado
Nome do storage account nxcstprodeus001	Portal, Storage Accounts	Configuracao de firewall (Etapa 7), montagem de file share
Nome do storage account nxcstprodeus002	Portal, Storage Accounts	Endpoint privado (Etapa 10)
Connection string do nxcstprodeus001	Storage account, Access keys blade	Configuracao do Storage Explorer e AzCopy
SAS token gerado	Storage account, Shared Access Signature blade	Teste de acesso (Etapa 7)
Resource ID do nxcstprodeus001	Portal, Properties blade do storage account	Configuracao de diagnostics (Etapa de Monitoramento)

Criterios de Sucesso:

• az storage account show --name nxcstprodeus001 retorna replication: LRS e accessTier: Hot.
• az storage account show --name nxcstprodeus002 retorna replication: GRS.
• O container nxc-artifacts aparece com versioning habilitado e a regra de lifecycle nxc-lifecycle-artifacts esta listada com as transicoes corretas.
• O SAS token de conta permite listar blobs via Storage Explorer mas bloqueia operacoes de Write.

---

Etapa 7: Configurar Firewall e Acesso de Rede ao Storage

Contexto de Negocios: Apos a criacao dos storage accounts na Etapa 6, a equipe de seguranca da NexaCore exige que os dados regulatorios do nxcstprodeus002 sejam acessiveis apenas a partir da rede virtual corporativa, bloqueando o acesso publico. Esta etapa depende dos storage accounts da Etapa 6 e da rede virtual que sera criada nesta mesma etapa como pre-requisito imediato.

Ambiente de Execucao:

Tarefa	Ambiente
Criar VNet e subnet (pre-requisito desta etapa)	CLI
Configurar Storage Firewall	Portal Azure
Configurar Service Endpoint	Portal Azure

Tarefas:

1. [CLI] Crie a VNet nxc-vnet-prod-eus-001 no Resource Group nxc-rg-network-eus-001 com o espaco de enderecamento 10.10.0.0/16. Dentro desta VNet, crie quatro subnets: nxc-snet-ops-001 (10.10.1.0/24), nxc-snet-app-001 (10.10.2.0/24), nxc-snet-data-001 (10.10.3.0/24) e nxc-snet-bastion-001 (10.10.4.0/27, necessaria para Azure Bastion na Etapa 9).
2. [CLI] Habilite o Service Endpoint Microsoft.Storage na subnet nxc-snet-data-001.
3. [Portal] No storage account nxcstprodeus002, acesse o blade "Networking" e altere o acesso publico para "Enabled from selected virtual networks and IP addresses". Adicione a subnet nxc-snet-data-001 como rede permitida. Bloquei o acesso de todas as outras origens.
4. [Portal] Tente acessar o storage account nxcstprodeus002 via Storage Explorer a partir da sua maquina local (fora da VNet). Registre o erro recebido. Este e o cenario de troubleshooting intencional: o acesso esta bloqueado porque a maquina local nao esta na VNet nem seu IP foi adicionado como excecao.
5. [Portal] Adicione o IP publico da sua maquina local como excecao no firewall do nxcstprodeus002. Confirme que o acesso via Storage Explorer e restaurado. Documente a diferenca entre Service Endpoint (acesso de dentro da VNet) e excecao de IP publico (acesso de fora da VNet).

Registro de Variaveis:

Valor	Onde Encontrar	Onde sera usado
Resource ID da VNet nxc-vnet-prod-eus-001	az network vnet show	Peering (Etapa 9), Bastion (Etapa 9)
Resource ID da subnet nxc-snet-ops-001	az network vnet subnet show	Deploy de VMs (Etapa 11)
Resource ID da subnet nxc-snet-app-001	az network vnet subnet show	Deploy de App Service e Container Apps (Etapas 14, 15)
Resource ID da subnet nxc-snet-data-001	az network vnet subnet show	Private Endpoint do storage (Etapa 10)
Resource ID da subnet nxc-snet-bastion-001	az network vnet subnet show	Azure Bastion (Etapa 9)

Criterios de Sucesso:

• az network vnet subnet show para nxc-snet-data-001 mostra serviceEndpoints: [{service: Microsoft.Storage}].
• O acesso ao nxcstprodeus002 via Storage Explorer falha com erro de rede quando o IP local nao esta na lista de excecoes.
• Apos adicionar o IP como excecao, o Storage Explorer lista os containers com sucesso.

---

Etapa 8: Implantar Recursos com ARM Templates e Bicep

Contexto de Negocios: A equipe de plataforma da NexaCore precisa padronizar o provisionamento de recursos usando IaC. Esta etapa utiliza a VNet e os Resource Groups criados nas Etapas 3, 4 e 7 como alvos de deploy, e os resultados (NSG e Public IP) serao consumidos nas Etapas 9 e 11.

Ambiente de Execucao:

Tarefa	Ambiente
Interpretar e modificar Bicep	VS Code com extensao Bicep
Deploy de recursos	CLI (az deployment group create)
Exportar como ARM	Portal Azure

Tarefas:

1. [Portal] Acesse o Resource Group nxc-rg-network-eus-001 e utilize a funcionalidade "Export template" para gerar o ARM Template JSON dos recursos existentes (a VNet e suas subnets). Salve o arquivo localmente. Em seguida, utilize o Azure CLI para converter este ARM Template para Bicep usando o comando az bicep decompile.
2. [VS Code] Abra o arquivo Bicep gerado. Modifique-o para adicionar um Network Security Group chamado nxc-nsg-ops-001 com as seguintes regras de entrada: permitir RDP (porta 3389) apenas do IP 10.10.4.0/27 (a subnet do Bastion) e negar todo trafego de entrada da Internet na porta 3389. Associe o NSG a subnet nxc-snet-ops-001 dentro do mesmo template.
3. [CLI] Execute o deploy do Bicep modificado como um deployment incremental no Resource Group nxc-rg-network-eus-001. Resolva quaisquer erros de validacao antes de submeter o deploy final. Registre o ID do deployment apos a conclusao.
4. [VS Code] Crie um novo arquivo Bicep do zero para provisionar um Public IP Address chamado nxc-pip-lb-eus-001 com SKU Standard, alocacao Estatica e DNS label nxc-nexacore-lb. O arquivo deve aceitar location e resourceGroupName como parametros com valores padrao.
5. [CLI] Execute o deploy do Bicep do Public IP. Em seguida, execute az deployment group show para o deploy do NSG e interprete os campos provisioningState, timestamp e outputResources no JSON de resposta. Registre o Resource ID do NSG criado.

Registro de Variaveis:

Valor	Onde Encontrar	Onde sera usado
Resource ID do NSG nxc-nsg-ops-001	Output do deploy ou az network nsg show	Associacao com VMs (Etapa 11)
Resource ID do Public IP nxc-pip-lb-eus-001	Output do deploy ou az network public-ip show	Load Balancer (Etapa 10)
DNS FQDN do Public IP	az network public-ip show, campo dnsSettings.fqdn	Teste de conectividade do Load Balancer
ID do Deployment do NSG	az deployment group list	Auditoria e rollback de referencia

Criterios de Sucesso:

• O arquivo Bicep decompilado compila sem erros de validacao (az bicep build).
• O deploy do NSG retorna provisioningState: Succeeded e o NSG aparece associado a subnet nxc-snet-ops-001.
• O Public IP nxc-pip-lb-eus-001 aparece com alocacao Static e o DNS label configurado.
• az deployment group show para o deploy do NSG exibe ambos os recursos (NSG e associacao de subnet) em outputResources.

---

Etapa 9: Configurar Redes Virtuais, Peering e Azure Bastion

Contexto de Negocios: A NexaCore necessita conectar a infraestrutura de East US com a regiao de recuperacao de desastres em Brazil South, e garantir acesso seguro as VMs sem exposicao de RDP/SSH publico. Esta etapa consome a VNet da Etapa 7 e prepara a rede para os deploys de compute das Etapas 11 a 15.

Ambiente de Execucao:

Tarefa	Ambiente
Criar VNet de DR e peering	CLI
Configurar Bastion	Portal Azure
Configurar DNS privado	Portal Azure
Troubleshooting de conectividade	Portal Azure (Network Watcher)

Tarefas:

1. [CLI] Crie a VNet nxc-vnet-prod-brs-001 no Resource Group nxc-rg-network-eus-001 com espaco de enderecamento 10.20.0.0/16 e a regiao brazilsouth. Crie as subnets nxc-snet-ops-brs-001 (10.20.1.0/24) e nxc-snet-app-brs-001 (10.20.2.0/24).
2. [CLI] Configure VNet Peering bidirecional entre nxc-vnet-prod-eus-001 e nxc-vnet-prod-brs-001. Nomeie os peerings como nxc-peer-eus-to-brs e nxc-peer-brs-to-eus. Habilite "Allow forwarded traffic" e "Allow gateway transit" em ambos os lados (mesmo que nao haja gateway ainda, a configuracao deve estar pronta).
3. [Portal] Crie um Azure Bastion com SKU Standard no Resource Group nxc-rg-network-eus-001, associado a subnet nxc-snet-bastion-001 e ao Public IP nxc-pip-bastion-001 (crie um novo Public IP Standard para o Bastion, distinto do Public IP do Load Balancer). Nomeie o Bastion nxc-bastion-eus-001.
4. [Portal] Crie uma Private DNS Zone chamada nexacore.internal e vincule-a a VNet nxc-vnet-prod-eus-001 com auto-registration habilitado. Adicione manualmente um registro A chamado ops-db apontando para 10.10.3.10 (IP reservado para banco de dados futuro). Vincule tambem a VNet nxc-vnet-prod-brs-001 sem auto-registration.
5. [Portal] Acesse o Network Watcher na regiao East US. Execute um "Topology" para visualizar os recursos na VNet nxc-vnet-prod-eus-001. Em seguida, tente executar um "IP Flow Verify" simulando trafego RDP (porta 3389) de um IP externo para a subnet nxc-snet-ops-001 e registre o resultado (deve ser bloqueado pelo NSG da Etapa 8, cenario de validacao).

Registro de Variaveis:

Valor	Onde Encontrar	Onde sera usado
Resource ID da VNet nxc-vnet-prod-brs-001	az network vnet show	Site Recovery (Etapa de Backup/DR)
Resource ID do Peering nxc-peer-eus-to-brs	az network vnet peering show	Validacao de conectividade cross-region
Resource ID do Bastion nxc-bastion-eus-001	Portal, Azure Bastion blade	Acesso as VMs sem IP publico (Etapa 11)
FQDN do registro DNS ops-db.nexacore.internal	Private DNS Zone blade	Referencia em configuracoes de aplicacao

Criterios de Sucesso:

• az network vnet peering show para ambos os peerings retorna peeringState: Connected.
• O Azure Bastion aparece com status Provisioned e SKU Standard.
• A Private DNS Zone nexacore.internal exibe o registro A ops-db com TTL padrao.
• O "IP Flow Verify" para RDP externo retorna Access: Deny com a regra NSG como causa.

---

Etapa 10: Configurar Private Endpoints, Load Balancer e DNS

Contexto de Negocios: Com a rede estabelecida nas Etapas 7 e 9, a NexaCore precisa garantir que o storage de dados regulatorios seja acessivel exclusivamente via rede privada (eliminando a excecao de IP publico adicionada na Etapa 7) e que o trafego HTTP para as VMs de aplicacao seja balanceado. Esta etapa e critica antes do deploy das VMs.

Ambiente de Execucao:

Tarefa	Ambiente
Criar Private Endpoint	Portal Azure
Configurar Load Balancer	Portal Azure
Configurar Azure DNS	Portal Azure
Troubleshooting de Load Balancer	Portal Azure (Load Balancer diagnostics)

Tarefas:

1. [Portal] Crie um Private Endpoint chamado nxc-pe-storage-eus-001 na subnet nxc-snet-data-001, apontando para o storage account nxcstprodeus002, sub-resource blob. Durante a criacao, selecione a integracao automatica com a Private DNS Zone (o portal criara privatelink.blob.core.windows.net automaticamente). Vincule esta Private DNS Zone a VNet nxc-vnet-prod-eus-001.
2. [Portal] Apos criar o Private Endpoint, retorne ao storage account nxcstprodeus002 e remova a excecao de IP publico adicionada na Etapa 7. Mantenha apenas o acesso via "Selected virtual networks" com o Private Endpoint. Tente novamente acessar via Storage Explorer da maquina local e registre o comportamento (deve falhar, pois o acesso agora e exclusivamente privado).
3. [Portal] Crie um Azure Load Balancer chamado nxc-lb-prod-eus-001 com SKU Standard, tipo Public, usando o Public IP nxc-pip-lb-eus-001 criado na Etapa 8. Configure o frontend IP, um backend pool chamado nxc-lbpool-app-001, uma health probe HTTP na porta 80 com caminho /health, e uma regra de load balancing para a porta 80 (TCP) com session persistence por IP de cliente.
4. [Portal] Crie uma zona de DNS publica no Azure DNS chamada nexacore-app.com (zona de teste, nao precisa de dominio real registrado). Adicione um registro CNAME www apontando para o FQDN do Public IP do Load Balancer (nxc-nexacore-lb.eastus.cloudapp.azure.com). Adicione tambem um registro A api apontando diretamente para o IP do Public IP.
5. [Portal] No Load Balancer, acesse "Insights" em "Monitoring". Identifique as metricas de "Data Path Availability" e "Health Probe Status". Registre os valores atuais. O backend pool esta vazio (VMs serao adicionadas na Etapa 11), entao o "Health Probe Status" deve ser 0, o que e o comportamento esperado neste momento.

Registro de Variaveis:

Valor	Onde Encontrar	Onde sera usado
Resource ID do Load Balancer nxc-lb-prod-eus-001	az network lb show	Associacao de VMs ao backend pool (Etapa 11)
Resource ID do Backend Pool nxc-lbpool-app-001	az network lb address-pool show	Adicionar NICs das VMs (Etapa 11)
IP privado do Private Endpoint do storage	Portal, Private Endpoint blade, Network Interface	Validacao de DNS privado
Resource ID da zona DNS nexacore-app.com	az network dns zone show	Mapeamento de custom domain no App Service (Etapa 15)

Criterios de Sucesso:

• nslookup nxcstprodeus002.blob.core.windows.net a partir de uma VM na VNet resolve para o IP privado 10.10.3.x (do Private Endpoint), nao para o IP publico do Azure.
• O acesso ao storage via Storage Explorer da maquina local falha com erro de rede apos a remocao da excecao de IP.
• O Load Balancer aparece com provisioningState: Succeeded e o frontend IP associado ao Public IP correto.

---

Etapa 11: Criar e Configurar Virtual Machines

Contexto de Negocios: A NexaCore precisa de dois servidores de aplicacao Windows Server na subnet de aplicacao de East US, integrados ao Load Balancer da Etapa 10, com disco criptografado e disponibilidade garantida por Availability Zone. Uma terceira VM Linux sera usada como servidor de dados na subnet de dados.

Ambiente de Execucao:

Tarefa	Ambiente
Criar VMs	Portal Azure e CLI
Configurar discos e criptografia	Portal Azure
Gerenciar tamanhos e discos	Portal Azure

Tarefas:

1. [Portal] Crie duas VMs Windows Server 2022 Datacenter chamadas nxc-vm-app-eus-001 e nxc-vm-app-eus-002 no Resource Group nxc-rg-shared-eus-001. Use o tamanho Standard_D2s_v3. Coloque nxc-vm-app-eus-001 na Availability Zone 1 e nxc-vm-app-eus-002 na Availability Zone 2. Conecte ambas a subnet nxc-snet-app-001. Nao crie IP publico para nenhuma das VMs (o acesso sera via Bastion). Associe o NSG nxc-nsg-ops-001 a NIC de ambas as VMs.
2. [Portal] Apos o provisionamento, adicione a NIC de cada VM ao backend pool nxc-lbpool-app-001 do Load Balancer. Para isso, acesse o Load Balancer, backend pool, e adicione as NICs. Confirme que o "Health Probe Status" ainda e 0 (o servico HTTP nao esta rodando nas VMs ainda, cenario esperado).
3. [Portal] Na VM nxc-vm-app-eus-001, habilite "Encryption at host" (criptografia em nivel de host). Verifique qual pre-requisito de feature registration e necessario na subscription antes de poder habilitar esta opcao. Registre o comando necessario para registrar a feature.
4. [CLI] Adicione um disco de dados gerenciado de 128 GB (SKU Premium SSD LRS) a VM nxc-vm-app-eus-001, nomeando o disco nxc-disk-app-eus-001-data. Em seguida, redimensione a VM nxc-vm-app-eus-002 de Standard_D2s_v3 para Standard_D4s_v3 via CLI. Registre se a VM precisa ser desalocada para o redimensionamento.
5. [CLI] Crie uma VM Linux Ubuntu 22.04 chamada nxc-vm-data-eus-001 na subnet nxc-snet-data-001, tamanho Standard_B2s, sem IP publico. Mova esta VM para o Resource Group nxc-rg-network-eus-001 usando o comando de move de recursos. Registre qual validacao o Azure executa antes de permitir o move (dependencias de recursos na subscription de destino).

Registro de Variaveis:

Valor	Onde Encontrar	Onde sera usado
Resource ID de nxc-vm-app-eus-001	az vm show	Backup (Etapa de Recovery), Site Recovery
Resource ID de nxc-vm-app-eus-002	az vm show	Backup (Etapa de Recovery)
Resource ID de nxc-vm-data-eus-001	az vm show	Site Recovery (Etapa de Recovery)
IP privado de nxc-vm-app-eus-001	Portal, VM Network blade	Testes de conectividade via Bastion
IP privado de nxc-vm-app-eus-002	Portal, VM Network blade	Testes de conectividade via Bastion

Criterios de Sucesso:

• As VMs nxc-vm-app-eus-001 e nxc-vm-app-eus-002 aparecem em Availability Zones 1 e 2 respectivamente no Portal.
• az network lb address-pool show --name nxc-lbpool-app-001 exibe as NICs de ambas as VMs na lista backendIPConfigurations.
• O disco nxc-disk-app-eus-001-data aparece como Attached no portal com SKU Premium_LRS.
• A VM nxc-vm-data-eus-001 aparece no Resource Group nxc-rg-network-eus-001 apos o move.

---

Etapa 12: Implantar Virtual Machine Scale Set

Contexto de Negocios: O time de produto da NexaCore identificou que os servidores de aplicacao tem picos de carga previsiveis. A solucao e migrar o workload de aplicacao para um VM Scale Set com autoscaling, substituindo as VMs fixas criadas na Etapa 11 para esta camada especifica. O Scale Set usara a mesma rede e Load Balancer.

Ambiente de Execucao:

Tarefa	Ambiente
Criar VMSS	Portal Azure
Configurar autoscaling	Portal Azure
Validar scaling	Azure Monitor (Metrics)

Tarefas:

1. [Portal] Crie um Virtual Machine Scale Set chamado nxc-vmss-app-eus-001 no Resource Group nxc-rg-shared-eus-001. Use Windows Server 2022, tamanho Standard_D2s_v3, modo de orquestracao "Flexible", espalhamento por Availability Zones 1, 2 e 3. Conecte a subnet nxc-snet-app-001 e associe ao Load Balancer nxc-lb-prod-eus-001 com o backend pool nxc-lbpool-app-001.
2. [Portal] Configure o autoscaling do VMSS com as seguintes regras: instancia minima 2, maxima 6, padrao 2. Regra de scale-out: quando CPU media > 70% por 5 minutos, adicione 1 instancia (cooldown de 5 minutos). Regra de scale-in: quando CPU media < 30% por 10 minutos, remova 1 instancia (cooldown de 5 minutos).
3. [Portal] Verifique o blade "Instances" do VMSS e confirme que 2 instancias foram provisionadas nas Availability Zones corretas. Acesse o Azure Bastion para se conectar a uma das instancias do VMSS (use o Bastion criado na Etapa 9) e confirme a conectividade.
4. [Portal] Acesse "Upgrade Policy" nas configuracoes do VMSS e configure a politica de upgrade para "Rolling" com um batch size de 25% e pausa de 5 minutos entre batches. Documente a diferenca entre as politicas Manual, Automatic e Rolling em termos de impacto operacional.
5. [Portal] No blade "Scaling" do VMSS, force um scale-out manual para 4 instancias. Aguarde o provisionamento. Em seguida, force um scale-in para 2 instancias. Monitore o "Activity Log" do VMSS para registrar os eventos de scaling.

Registro de Variaveis:

Valor	Onde Encontrar	Onde sera usado
Resource ID do VMSS nxc-vmss-app-eus-001	az vmss show	Monitoramento (Etapa de Monitor), Backup
Numero de instancias atuais	VMSS blade, Instances	Baseline para testes de autoscaling

Criterios de Sucesso:

• O VMSS aparece com provisioningState: Succeeded e 2 instancias distribuidas entre as Availability Zones.
• O autoscaling profile esta configurado com as regras de scale-in e scale-out visiveis no blade "Scaling".
• O Activity Log do VMSS exibe os eventos de scale-out e scale-in manuais com timestamps.

---

Etapa 13: Provisionar Azure Container Registry e Container Instances

Contexto de Negocios: O time de desenvolvimento da NexaCore esta migrando um microservico de analise de credito para containers. Nesta etapa, sera criado o registro privado de imagens e um container de instancia simples para validacao rapida antes do deploy em Container Apps (Etapa 14).

Ambiente de Execucao:

Tarefa	Ambiente
Criar ACR	CLI
Publicar imagem	CLI (Docker e ACR Tasks)
Criar ACI	Portal Azure e CLI

Tarefas:

1. [CLI] Crie um Azure Container Registry chamado nxcacrprodeus001 (SKU Premium, para suportar geo-replication e Private Link) no Resource Group nxc-rg-shared-eus-001, regiao East US. Habilite o admin user no registry.
2. [CLI] Usando ACR Tasks (sem necessidade de Docker local), execute um build direto no ACR de uma imagem simples. Use o seguinte Dockerfile inline via az acr build a partir de um diretorio temporario com um Dockerfile contendo apenas FROM nginx:alpine e EXPOSE 80. Nomeie a imagem nxc-credit-api:v1.0.
3. [CLI] Crie um Azure Container Instance chamado nxc-aci-test-001 no Resource Group nxc-rg-shared-eus-001 a partir da imagem nxc-credit-api:v1.0 do ACR. Configure 1 vCPU e 1.5 GB de memoria. Exponha a porta 80. Use a identidade gerenciada (Managed Identity) do ACI para autenticacao no ACR, em vez de username/password do admin user.
4. [Portal] Verifique o ACI criado: acesse o blade "Containers", veja os logs e o evento de start. Acesse o IP publico provisionado automaticamente e confirme que o nginx responde na porta 80. Registre o IP publico do ACI.
5. [Portal] Acesse o ACR e verifique o repositorio nxc-credit-api. Confirme que a imagem v1.0 esta listada com o digest correto. Em seguida, configure uma regra de retencao no ACR para deletar imagens sem tag apos 7 dias (lifecycle policy do ACR).

Registro de Variaveis:

Valor	Onde Encontrar	Onde sera usado
Login server do ACR (nxcacroprodeus001.azurecr.io)	az acr show, campo loginServer	Deploy no Container Apps (Etapa 14)
Resource ID do ACR	az acr show	Atribuicao de role AcrPull para Container Apps
IP publico do ACI nxc-aci-test-001	Portal, ACI blade, Overview	Teste de acesso HTTP
Digest da imagem nxc-credit-api:v1.0	ACR blade, Repositories	Referencia para deploy imutavel

Criterios de Sucesso:

• az acr repository list --name nxcacroprodeus001 retorna nxc-credit-api.
• O ACI nxc-aci-test-001 aparece com provisioningState: Succeeded e currentState: Running.
• Uma requisicao HTTP GET para o IP publico do ACI na porta 80 retorna o HTML padrao do nginx.

---

Etapa 14: Provisionar Azure Container Apps

Contexto de Negocios: Apos a validacao do container com ACI na Etapa 13, o microservico de analise de credito sera implantado em Azure Container Apps para beneficiar-se de autoscaling baseado em HTTP e integracao com a VNet corporativa.

Ambiente de Execucao:

Tarefa	Ambiente
Criar Container Apps Environment	Portal Azure e CLI
Criar Container App	CLI
Configurar scaling	Portal Azure

Tarefas:

1. [CLI] Crie um Container Apps Environment chamado nxc-cae-prod-eus-001 no Resource Group nxc-rg-shared-eus-001, integrado a subnet nxc-snet-app-001 (o ambiente deve ser do tipo "Workload profiles", nao consumption-only, para suportar integracao com VNet dedicada). Configure o environment como internal (sem IP publico externo).
2. [CLI] Crie um Container App chamado nxc-ca-creditapi-001 no environment nxc-cae-prod-eus-001, usando a imagem nxcacroprodeus001.azurecr.io/nxc-credit-api:v1.0. Configure a revisao como Single. Defina 0.5 CPU e 1.0 Gi de memoria. Exponha o servico na porta 80 como external: false (acesso apenas interno).
3. [Portal] No Container App, acesse "Scale and replicas" e configure a regra de scaling: minimo 1 replica, maximo 5 replicas, com escalonamento baseado em requisicoes HTTP com threshold de 100 requisicoes por segundo por replica.
4. [CLI] Crie uma nova revisao do Container App atualizando a imagem para nxc-credit-api:v1.0 com uma variavel de ambiente adicional APP_ENV=production. Ative o modo de revisao "Multiple" e configure o trafego: 80% para a revisao nova e 20% para a revisao anterior. Este cenario simula um canary deployment.
5. [Portal] Verifique o blade "Revisions" do Container App e confirme a distribuicao de trafego. Acesse "Log stream" para verificar os logs em tempo real de ambas as revisoes. Registre o FQDN interno do Container App.

Registro de Variaveis:

Valor	Onde Encontrar	Onde sera usado
FQDN interno do Container App	Portal, Container Apps, Overview	Configuracao de DNS privado e testes
Resource ID do Container Apps Environment	az containerapp env show	Referencia para outros Container Apps futuros
Nome da revisao ativa principal	Portal, Revisions blade	Rollback em caso de incidente

Criterios de Sucesso:

• az containerapp show --name nxc-ca-creditapi-001 retorna provisioningState: Succeeded e runningState: Running.
• O blade "Revisions" exibe duas revisoes com distribuicao de trafego 80/20.
• A regra de scaling aparece configurada com HTTP scaler e thresholds corretos.

---

Etapa 15: Criar e Configurar Azure App Service

Contexto de Negocios: Alem dos containers, a NexaCore possui uma aplicacao web legada em .NET que sera migrada para Azure App Service. O App Service precisa ser configurado com TLS, deployment slots para blue-green deployment e integracao com a VNet.

Ambiente de Execucao:

Tarefa	Ambiente
Criar App Service Plan e App	CLI
Configurar TLS e DNS	Portal Azure
Configurar deployment slots	Portal Azure
Configurar backup	Portal Azure

Tarefas:

1. [CLI] Crie um App Service Plan chamado nxc-asp-prod-eus-001 no Resource Group nxc-rg-shared-eus-001, SKU P2v3 (para suportar VNet Integration e deployment slots). Em seguida, crie um App Service chamado nxc-app-portal-eus-001 neste plan, runtime stack .NET 8.
2. [Portal] No App Service, configure VNet Integration com a subnet nxc-snet-app-001. Esta configuracao permite que o App Service alcance recursos na VNet (como o Container App e o storage privado) mas nao torna o App Service privado em si. Verifique o campo "Outbound IP addresses" antes e depois da integracao.
3. [Portal] Crie um deployment slot chamado staging no App Service nxc-app-portal-eus-001. Configure as seguintes slot settings (configuracoes que nao fazem swap): APP_ENV, APPLICATIONINSIGHTS_CONNECTION_STRING. Implante uma atualizacao no slot staging (pode ser um arquivo index.html simples via ZIP deploy via CLI) e execute um swap para producao.
4. [Portal] No App Service de producao, configure um certificado TLS gerenciado pelo App Service (App Service Managed Certificate) para o hostname www.nexacore-app.com (mapeado via CNAME na Etapa 10). Realize o mapeamento do dominio customizado primeiro, depois vincule o certificado. Configure o TLS minimum version como 1.2.
5. [Portal] Configure o backup automatico do App Service: storage account nxcstprodeus001, container nxc-artifacts, frequencia diaria, retencao de 30 dias, incluindo o banco de dados de conexao (adicione uma connection string ficticia chamada DefaultConnection nas configuracoes do App para testar a inclusao no backup).

Registro de Variaveis:

Valor	Onde Encontrar	Onde sera usado
URL de producao do App Service	Portal, App Service, Overview	Teste de acesso HTTPS
URL do slot staging	Portal, App Service, Deployment slots	Testes pre-swap
Outbound IPs do App Service	Portal, App Service, Properties	Whitelist em firewalls de banco de dados
Resource ID do App Service Plan	az appservice plan show	Configuracao de autoscaling do plan

Criterios de Sucesso:

• O App Service responde com HTTP 200 na URL https://nxc-app-portal-eus-001.azurewebsites.net.
• O swap entre staging e producao completa sem downtime percebido.
• O dominio customizado www.nexacore-app.com aparece como "Secured" com o certificado gerenciado.
• O backup automatico aparece configurado com agendamento visivel em "Backup".

---

Etapa 16: Configurar Azure Monitor, Alertas e Insights

Contexto de Negocios: Com toda a infraestrutura provisionada nas Etapas anteriores, a NexaCore precisa estabelecer visibilidade operacional centralizada. Esta etapa conecta todos os recursos ao Azure Monitor e configura alertas proativos para os SLAs corporativos.

Ambiente de Execucao:

Tarefa	Ambiente
Criar Log Analytics Workspace	CLI
Configurar Diagnostic Settings	Portal Azure e CLI
Criar Alert Rules e Action Groups	Portal Azure
Consultar logs com KQL	Portal Azure (Log Analytics)

Tarefas:

1. [CLI] Crie um Log Analytics Workspace chamado nxc-law-prod-eus-001 no Resource Group nxc-rg-shared-eus-001, regiao East US, retention de 90 dias. Este workspace sera o destino central de todos os logs de diagnostico.
2. [Portal] Configure Diagnostic Settings para os seguintes recursos, enviando todos os logs e metricas para nxc-law-prod-eus-001: VM nxc-vm-app-eus-001 (habilite o Azure Monitor Agent via Data Collection Rule), storage account nxcstprodeus001 (habilite logs de StorageRead, StorageWrite e StorageDelete para o blob service), e Load Balancer nxc-lb-prod-eus-001.
3. [Portal] Crie um Action Group chamado nxc-ag-ops-001 com um receptor de e-mail para ops.lead@{tenant} e um segundo receptor de SMS (numero ficticio). Em seguida, crie as seguintes Alert Rules: CPU > 80% por 5 minutos nas VMs do VMSS (severidade 2), disponibilidade do App Service < 99% (severidade 1), e falha de autenticacao no tenant Entra ID > 10 em 10 minutos (usando Entra ID Sign-in logs).
4. [Portal] Acesse o Log Analytics Workspace e execute as seguintes consultas KQL. Primeiro: liste todas as operacoes de criacao de recursos dos ultimos 7 dias a partir dos Azure Activity Logs. Segundo: liste os top 5 IPs que mais fizeram requests ao App Service (a partir dos logs de diagnostico do App Service). Registre as consultas utilizadas.
5. [Portal] Acesse "Insights" de cada recurso principal: VM Insights para nxc-vm-app-eus-001 (verifique mapa de dependencias), Storage Insights para nxcstprodeus001 (verifique latencia e disponibilidade), e Network Insights para nxc-vnet-prod-eus-001 (verifique fluxos de trafego). Registre quais dados estao disponiveis sem configuracao adicional e quais requerem habilitacao explicita.

Registro de Variaveis:

Valor	Onde Encontrar	Onde sera usado
Resource ID do Log Analytics Workspace	az monitor log-analytics workspace show	Diagnostic Settings, Azure Site Recovery (Etapa 17)
ID do Action Group nxc-ag-ops-001	Portal, Monitor, Action Groups	Todas as Alert Rules
Workspace ID (GUID)	LAW blade, Overview	Conexao de agentes e Data Collection Rules
Primary key do LAW	LAW blade, Agents management	Configuracao manual de agentes legados

Criterios de Sucesso:

• O Log Analytics Workspace aparece com provisioningState: Succeeded e retencao de 90 dias.
• As Diagnostic Settings aparecem configuradas para todos os tres recursos listados.
• Uma consulta KQL simples AzureActivity | take 10 retorna resultados no workspace.
• As Alert Rules aparecem com status "Enabled" e vinculadas ao Action Group correto.

---

Etapa 17: Implementar Backup e Azure Site Recovery

Contexto de Negocios: Esta e a etapa final de infraestrutura. A NexaCore precisa garantir que os dados e workloads criados nas Etapas 6 a 15 possam ser recuperados em caso de falha. O Recovery Services Vault protegera as VMs e o Azure Site Recovery replicara as VMs criticas para Brazil South (VNet provisionada na Etapa 9).

Ambiente de Execucao:

Tarefa	Ambiente
Criar vaults	CLI
Configurar backup policies	Portal Azure
Executar backup e restore	Portal Azure
Configurar Site Recovery	Portal Azure

Tarefas:

1. [CLI] Crie um Recovery Services Vault chamado nxc-rsv-prod-eus-001 no Resource Group nxc-rg-shared-eus-001, regiao East US, com storage type GRS. Crie tambem um Azure Backup Vault chamado nxc-bkpv-prod-eus-001 no mesmo RG (o Backup Vault e usado para datasources mais novos como Blob Storage e Discos gerenciados).
2. [Portal] No Recovery Services Vault nxc-rsv-prod-eus-001, crie uma Backup Policy chamada nxc-bkp-policy-vms-001 com as seguintes configuracoes: backup diario as 23:00 UTC, retencao de pontos diarios por 30 dias, semanais por 12 semanas (toda segunda-feira), mensais por 12 meses.
3. [Portal] Aplique a policy nxc-bkp-policy-vms-001 as VMs nxc-vm-app-eus-001, nxc-vm-app-eus-002 e nxc-vm-data-eus-001. Dispare um backup on-demand imediato para nxc-vm-app-eus-001 e monitore o job ate a conclusao. Registre o tempo de duracao do backup.
4. [Portal] No Recovery Services Vault, configure o Azure Site Recovery para replicar a VM nxc-vm-app-eus-001 de East US para Brazil South. Selecione a VNet nxc-vnet-prod-brs-001 como rede de destino e a subnet nxc-snet-ops-brs-001 como subnet de destino. Aguarde a sincronizacao inicial (pode levar varios minutos).
5. [Portal] Apos a replicacao estar em estado "Protected", execute um Test Failover para Brazil South utilizando o recovery point mais recente. Confirme que a VM de teste sobe na VNet de DR corretamente. Em seguida, execute "Cleanup test failover" para remover os recursos de teste. Configure um alerta de backup no Recovery Services Vault para notificar o Action Group nxc-ag-ops-001 em caso de falha de job de backup.

Registro de Variaveis:

Valor	Onde Encontrar	Onde sera usado
Resource ID do RSV nxc-rsv-prod-eus-001	az backup vault show	Referencia para restore e failover
Job ID do backup on-demand	Portal, RSV, Backup Jobs	Troubleshooting de backup
RPO atual da replicacao ASR	Portal, RSV, Replicated items	Validacao de SLA de DR
Resource ID do Backup Vault	az dataprotection backup-vault show	Backup de blobs e discos

Criterios de Sucesso:

• O backup on-demand da nxc-vm-app-eus-001 completa com status "Completed" no blade "Backup Jobs".
• O item replicado nxc-vm-app-eus-001 aparece com Replication health: Healthy e RPO menor que 1 hora.
• O Test Failover resulta na criacao de uma VM temporaria na VNet nxc-vnet-prod-brs-001.
• O alerta de backup falha esta configurado no RSV com o Action Group correto.

---

4. Validacao Global do Ambiente

Checklist de Recursos Provisionados

Categoria	Recurso	Nome	Status Esperado
Governance	Management Group Raiz	nxc-mg-root	Active
Governance	Management Group Prod	nxc-mg-prod	Active
Governance	Management Group Prod EUA	nxc-mg-prod-eua	Active
Governance	Budget	nxc-budget-prod-001	Active
Governance	Policy: Allowed Locations	nxc-policy-allowed-locations	Enabled
Governance	Policy: Tag CostCenter	nxc-policy-tag-costcenter	Enabled
Governance	Policy: Tag Environment	nxc-policy-tag-environment	Enabled
Identity	Grupo Entra ID	nxc-grp-platform-ops	Active, licensed
Identity	Grupo Entra ID	nxc-grp-developers	Active
Identity	Grupo Entra ID	nxc-grp-finance	Active
Identity	SSPR	Configurado para nxc-grp-platform-ops	Enabled
Networking	VNet Primaria	nxc-vnet-prod-eus-001	Succeeded
Networking	VNet DR	nxc-vnet-prod-brs-001	Succeeded
Networking	VNet Peering EUS-BRS	nxc-peer-eus-to-brs	Connected
Networking	NSG	nxc-nsg-ops-001	Succeeded
Networking	Public IP LB	nxc-pip-lb-eus-001	Succeeded, Static
Networking	Load Balancer	nxc-lb-prod-eus-001	Succeeded
Networking	Azure Bastion	nxc-bastion-eus-001	Provisioned
Networking	Private Endpoint Storage	nxc-pe-storage-eus-001	Approved
Networking	Private DNS Zone	nexacore.internal	Active
Networking	DNS Zone Publica	nexacore-app.com	Active
Storage	Storage Account Geral	nxcstprodeus001	Succeeded, LRS
Storage	Storage Account Regulatorio	nxcstprodeus002	Succeeded, GRS
Storage	File Share	nxc-ops-share	Succeeded
Storage	Container Blob	nxc-artifacts	Succeeded, private
Compute	VM App 1	nxc-vm-app-eus-001	Running, Zone 1
Compute	VM App 2	nxc-vm-app-eus-002	Running, Zone 2
Compute	VM Data	nxc-vm-data-eus-001	Running
Compute	VMSS App	nxc-vmss-app-eus-001	Succeeded, 2+ instances
Compute	ACR	nxcacroprodeus001	Succeeded, Premium
Compute	ACI	nxc-aci-test-001	Running
Compute	Container Apps Environment	nxc-cae-prod-eus-001	Succeeded
Compute	Container App	nxc-ca-creditapi-001	Running
Compute	App Service Plan	nxc-asp-prod-eus-001	Succeeded, P2v3
Compute	App Service	nxc-app-portal-eus-001	Running
Monitoring	Log Analytics Workspace	nxc-law-prod-eus-001	Succeeded
Monitoring	Action Group	nxc-ag-ops-001	Enabled
Backup	Recovery Services Vault	nxc-rsv-prod-eus-001	Succeeded, GRS
Backup	Backup Vault	nxc-bkpv-prod-eus-001	Succeeded

---

Testes de Integracao End-to-End

Teste 1: Acesso privado ao storage via VM na VNet

A partir da VM nxc-vm-app-eus-001 (acessada via Azure Bastion), execute um nslookup nxcstprodeus002.blob.core.windows.net. O resultado esperado e a resolucao para o IP privado do Private Endpoint (faixa 10.10.3.x), nao para um IP publico do Azure. Em seguida, use o AzCopy instalado na VM para listar os containers do nxcstprodeus002 usando a connection string. O acesso deve ser bem-sucedido, confirmando que o Private Endpoint e o DNS privado estao funcionando em conjunto.

Teste 2: Fluxo de autenticacao e RBAC

Autentique-se no Azure CLI com a conta dev.lead. Tente listar os recursos da subscription com az resource list. A operacao deve ter sucesso (role Reader herdada do Management Group). Tente criar um Resource Group com az group create e registre o erro de autorizacao. Em seguida, autentique com ops.lead e confirme que a criacao de Resource Group e bem-sucedida (role Contributor na subscription).

Teste 3: Conectividade cross-region via Peering

A partir da VM nxc-vm-app-eus-001 (East US), execute um ping ou teste de conexao TCP para o IP privado de uma VM na VNet nxc-vnet-prod-brs-001 (se houver). Alternativamente, use o Network Watcher "Connection Monitor" para criar um teste de conectividade entre as duas VNets. O resultado deve confirmar que o peering permite comunicacao direta entre os espacos de enderecamento 10.10.0.0/16 e 10.20.0.0/16.

Teste 4: Validacao de policy enforcement

Tente criar um storage account na regiao westeurope usando uma conta com role Contributor. O Azure Policy nxc-policy-allowed-locations deve bloquear a operacao imediatamente no momento do deploy, retornando o erro RequestDisallowedByPolicy. Confirme tambem que tentar criar um recurso sem as tags CostCenter e Environment retorna o erro correspondente da policy de tags.

Teste 5: Backup e resolucao de DNS

Confirme que o backup on-demand da Etapa 17 criou um Recovery Point visivelno blade "Recovery Points" do RSV. Verifique o RPO da replicacao ASR da nxc-vm-app-eus-001 e confirme que esta abaixo de 1 hora. A partir da VM nxc-vm-app-eus-001, resolva o nome ops-db.nexacore.internal e confirme que retorna 10.10.3.10 (registro A criado na Etapa 9 na Private DNS Zone).

---

Tabela de Troubleshooting

Sintoma	Causa Provavel	Solucao Esperada
RequestDisallowedByPolicy ao criar recurso em regiao diferente	Policy nxc-policy-allowed-locations ativa no Management Group	Recriar o recurso nas regioes eastus ou brazilsouth
ScopeLocked ao tentar criar recurso no nxc-rg-shared-eus-001	Resource Lock ReadOnly aplicado na Etapa 4	Remover o lock via Remove-AzResourceLock antes de criar recursos, depois reaplicar
Storage Explorer retorna erro 403 ao acessar nxcstprodeus002	Acesso publico bloqueado apos configuracao do Private Endpoint na Etapa 10	Acessar o storage apenas de dentro da VNet (via VM + Bastion) ou reabilitar excecao de IP temporariamente
nslookup do storage account resolve para IP publico ao inves de IP privado	Private DNS Zone nao vinculada a VNet ou registro A nao propagado	Verificar vinculo da zona privatelink.blob.core.windows.net com nxc-vnet-prod-eus-001
Peering com status Disconnected	Peering criado em apenas um lado (unidirecional)	Criar o peering no sentido inverso e confirmar que ambos mostram Connected
VM nao aparece no backend pool do Load Balancer	NIC nao adicionada ao backend pool ou VM em subnet diferente da configurada no LB	Verificar a subnet da NIC da VM e adicionar manualmente a NIC no blade do backend pool
Health Probe do Load Balancer retorna 0%	Servico HTTP nao esta rodando nas instancias do backend na porta 80	Instalar e iniciar o servico web nas VMs (IIS no Windows, nginx no Linux)
Backup job com status Failed no RSV	VM desligada no momento do backup ou agente de VM desatualizado	Verificar o status do Azure VM Agent na VM e atualizar se necessario; reagendar backup
Site Recovery com status Critical apos configuracao	Conectividade de saida da VM para endpoints do Site Recovery bloqueada por NSG	Adicionar regras de NSG outbound para AzureSiteRecovery service tag na porta 443
Deploy Bicep falha com InvalidTemplateDeployment	Erro de sintaxe no arquivo Bicep ou referencia a recurso que ainda nao existe	Executar az bicep build para validar o template antes do deploy e corrigir as referencias
SSPR nao disponivel para usuario especifico	Usuario nao e membro do grupo nxc-grp-platform-ops ou nao concluiu o registro de metodo	Verificar a associacao ao grupo e exigir novo registro via blade "Registration" do SSPR
Container App nao inicializa e mostra erro de pull	Role AcrPull nao atribuida ao Managed Identity do Container Apps Environment	Atribuir AcrPull no ACR para o principal do Container Apps Environment
App Service retorna HTTP 503 apos swap de slot	Slot staging nao estava "aquecido" antes do swap	Habilitar Auto-Swap ou usar "Swap with preview" para validar o slot antes de completar o swap

---

Diagrama da Arquitetura Final

100%

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