[AZ-104] Grand Labs - Strivex Educação Digital Ltda.

Ambiente Cumulativo de Implantação Real

Narrativa Central

A Empresa: Strivex Educação Digital Ltda.

A Strivex Educação Digital Ltda. é uma edtech com sede em São Paulo (SP) e operações em Recife (PE). Com 600 colaboradores e uma plataforma de ensino online com 180.000 alunos ativos, a empresa decidiu migrar toda a infraestrutura para o Azure após o encerramento do contrato com o datacenter terceirizado.

O projeto de migração exige:

Gestão de identidades com Microsoft Entra ID, incluindo usuários externos (professores parceiros), licenças e SSPR
Governança com RBAC granular, Azure Policy, resource locks, tags e management groups
Storage seguro e replicado para materiais didáticos, vídeos e backups
VMs de alta disponibilidade para o servidor de streaming e o backend da API
Automação de implantação via ARM Templates
Rede virtual segmentada com NSGs, Private Endpoints e load balancer
Monitoramento centralizado e backup com recovery services

Você é o administrador Azure responsável por toda a implantação. O laboratório reproduz cada fase desse projeto do início ao ambiente validado.

Tenant Microsoft Entra ID: strivex.onmicrosoft.com
Prefixo de recursos: STX-
Região primária: East US
Região secundária: Brazil South
Resource Groups principais: STX-RG-Core, STX-RG-Apps, STX-RG-Storage, STX-RG-Network, STX-RG-Security

Ambiente Inicial

Recursos necessários antes do início do laboratório

Recurso	Especificação mínima	Observação
Assinatura Azure	Pay-As-You-Go ou MSDN	Owner na assinatura; budget mínimo USD 100 disponível
Tenant Microsoft Entra ID	`strivex.onmicrosoft.com`	Conta Global Admin `admin@strivex.onmicrosoft.com`
Azure CLI	v2.55+	Instalado na estação de trabalho de administração
PowerShell	7.x com módulo `Az` 11.x+	Instalado na estação de trabalho de administração
Azure Storage Explorer	Versão mais recente	Para tarefas de gerenciamento de blobs e files
AzCopy	v10+	Para operações de transferência de dados em massa

Credenciais fictícias do laboratório

Conta	Tipo	Senha	Escopo
`admin@strivex.onmicrosoft.com`	Global Admin Entra ID	`Strivex@Entra2024!`	Tenant
`Administrator` (VMs locais)	Admin local Azure VMs	`Strivex@VM2024!`	Todas as VMs
`pedro.dev@strivex.onmicrosoft.com`	Dev interno	`Strivex@Usr2024!`	Tenant
`ana.ops@strivex.onmicrosoft.com`	Ops interno	`Strivex@Usr2024!`	Tenant
`prof.externo@parceiro.edu`	Usuário convidado (B2B)	Gerenciado pelo tenant externo	Guest

caution

Senhas exclusivas para este ambiente de laboratório.

Ferramentas necessárias

Azure CLI 2.55+, PowerShell 7.x com módulo Az
Azure Storage Explorer (download em storageexplorer.com)
AzCopy v10+ (download em aka.ms/downloadazcopy)
Navegador com acesso ao Portal Azure (portal.azure.com) e Entra Admin Center (entra.microsoft.com)

Diagrama de topologia inicial

Microsoft Entra ID: strivex.onmicrosoft.com
  [Apenas conta admin — sem usuários, grupos ou licenças]

Azure Subscription
  [Sem Resource Groups]
  [Sem recursos provisionados]

Etapa 1 — Gerenciar Usuários e Grupos do Microsoft Entra ID

Contexto da etapa

O primeiro passo da migração da Strivex é estruturar as identidades. A equipe de TI, os professores internos e parceiros externos precisam de contas organizadas em grupos que reflitam a estrutura da empresa. Os professores parceiros acessam o tenant via convite B2B (Microsoft Entra External ID). Licenças Microsoft 365 Business Basic serão atribuídas por grupo para automatizar o provisionamento.

Ambiente de execução

Modo	Disponível nesta etapa
Portal Azure / Entra Admin Center	Sim
PowerShell	Sim
CLI	Sim
IaC (Nenhuma)	Não

Tarefas

1. [Portal / PowerShell] No Entra Admin Center (entra.microsoft.com), crie os usuários internos:

pedro.dev@strivex.onmicrosoft.com: nome Pedro Silva, departamento Engineering, cargo Developer, uso de localização Brazil
ana.ops@strivex.onmicrosoft.com: nome Ana Costa, departamento Operations, cargo Cloud Administrator, uso de localização Brazil
lucas.instrutor@strivex.onmicrosoft.com: nome Lucas Ferreira, departamento Education, cargo Instructor

Crie os grupos de segurança: STX-GG-Developers (Pedro), STX-GG-Ops (Ana), STX-GG-Instructors (Lucas). Crie também o grupo dinâmico STX-GG-AllBrazilUsers com regra de membership baseada em user.usageLocation -eq "BR".

2. [Portal] Convide o usuário externo prof.externo@parceiro.edu como Guest via External Identities > External users > Invite user. Configure as permissões do convidado para permitir apenas acesso a aplicações específicas. Após o convite, adicione o usuário ao grupo STX-GG-Instructors. Verifique o estado do convite (Pending/Accepted) em Users > prof.externo#EXT#.

3. [Portal / PowerShell] Atribua licenças aos grupos usando Group-based licensing (requer pelo menos licença de avaliação ou MSDN):

STX-GG-Developers: licença Microsoft 365 Business Basic (ou a disponível na assinatura de avaliação)
STX-GG-Instructors: mesma licença

Confirme que Pedro, Ana e Lucas receberam a licença indiretamente. Verifique em Users > [usuário] > Licenses.

4. [Portal] Configure o Self-Service Password Reset (SSPR) para o grupo STX-GG-AllBrazilUsers: em Protection > Password Reset, habilite SSPR para Selected, escolha o grupo STX-GG-AllBrazilUsers. Configure os métodos de autenticação requeridos: 2 métodos. Métodos habilitados: Email, Mobile phone, Security questions (5 perguntas, exigir 3). Habilite a opção de registrar ao fazer login.

Valor capturado

Valor	Onde encontrar	Usado na etapa
Object ID de `pedro.dev`	Entra Admin Center > Users	2, 10
Object ID de `STX-GG-Ops`	Entra Admin Center > Groups	2, 10
Tenant ID `strivex.onmicrosoft.com`	Entra Admin Center > Overview	2, 3, 10

Critérios de validação

1. Confirme os usuários criados:

az ad user list --filter "startswith(userPrincipalName,'pedro') or startswith(userPrincipalName,'ana') or startswith(userPrincipalName,'lucas')" --query "[].{UPN:userPrincipalName, Dept:department}" -o table

Resultado esperado: 3 usuários listados com departamentos corretos.

2. Confirme o grupo dinâmico com regra de membership:

az ad group show --group STX-GG-AllBrazilUsers --query "membershipRule" -o tsv

Resultado esperado: user.usageLocation -eq "BR".

3. Confirme SSPR habilitado para o grupo selecionado: Portal > Microsoft Entra ID > Protection > Password Reset > Properties: Self service password reset enabled: Selected, grupo STX-GG-AllBrazilUsers listado.

Etapa 2 — Gerenciar Acesso a Recursos Azure

Contexto da etapa

Com os usuários e grupos criados, a Strivex precisa definir quem pode fazer o quê no Azure. Pedro (Desenvolvedor) precisa implantar recursos em um resource group específico sem poder alterar a rede. Ana (Ops) precisa de visibilidade completa na assinatura. Os professores não devem ter acesso ao Azure. Esta etapa demonstra a ausência de controle antes de aplicar RBAC.

Ambiente de execução

Modo	Disponível nesta etapa
Portal Azure	Sim
PowerShell	Sim
CLI	Sim
IaC (Nenhuma)	Não

Tarefas

1. [Portal / CLI] Crie os Resource Groups que serão usados ao longo do laboratório:

STX-RG-Core — East US
STX-RG-Apps — East US
STX-RG-Storage — East US
STX-RG-Network — East US
STX-RG-Security — East US
STX-RG-DR — Brazil South

Aplique a tag Project=Strivex-Migration e Environment=Production em todos os resource groups.

2. [Portal / CLI] Atribua as seguintes roles RBAC:

ana.ops@strivex.onmicrosoft.com: papel Reader no escopo da assinatura inteira
pedro.dev@strivex.onmicrosoft.com: papel Contributor no escopo de STX-RG-Apps apenas
Grupo STX-GG-Ops: papel Monitoring Reader no escopo da assinatura

3. [Portal / PowerShell] Demonstre a ausência de controle antes de aplicar o role customizado: faça login com pedro.dev (via CLI az login) e tente criar um recurso em STX-RG-Core (onde Pedro não tem permissão). Confirme o erro AuthorizationFailed. Em seguida, crie um Custom RBAC Role STX-ROLE-AppDeploy com permissões:

Microsoft.Compute/virtualMachines/*
Microsoft.Network/networkInterfaces/*
Microsoft.Storage/storageAccounts/read
Microsoft.Resources/deployments/*

Escopo atribuível: STX-RG-Apps. Atribua o custom role a pedro.dev no STX-RG-Apps (além do Contributor já atribuído; depois remova o Contributor para testar o custom role isoladamente).

4. [Portal] Interprete o Effective Access de pedro.dev: em STX-RG-Apps > Access control (IAM) > Check access, selecione pedro.dev e confirme quais ações são permitidas. Tente criar um recurso proibido pelo custom role (ex: az network vnet create sem permissão de VNet) e confirme o bloqueio.

Valor capturado

Valor	Onde encontrar	Usado na etapa
Custom Role `STX-ROLE-AppDeploy` definition ID	`az role definition list --name STX-ROLE-AppDeploy`	10
Resource Group IDs (6 grupos)	Portal > Resource Groups > Properties	3, 4, 5, 6, 7

Critérios de validação

1. Confirme a atribuição de role de ana.ops:

az role assignment list --assignee ana.ops@strivex.onmicrosoft.com --query "[].{Role:roleDefinitionName, Scope:scope}" -o table

Resultado esperado: Reader no escopo da assinatura.

2. Confirme o Custom Role criado:

az role definition list --name "STX-ROLE-AppDeploy" --query "[].{Name:roleName, Type:roleType, Scopes:assignableScopes}" -o table

Resultado esperado: Type: CustomRole, escopo listando STX-RG-Apps.

3. Confirme o bloqueio de pedro.dev em STX-RG-Core:

az resource list --resource-group STX-RG-Core # executar como pedro.dev

Resultado esperado: AuthorizationFailed ou lista vazia com erro de permissão.

Etapa 3 — Gerenciar Assinaturas e Governança

Contexto da etapa

A Strivex precisa garantir que todos os recursos Azure estejam em conformidade com os padrões da empresa: nomenclatura padronizada, localização restrita, tags obrigatórias e proteção contra deleção acidental. O Management Group organiza a hierarquia de assinaturas e o Azure Policy enforça os padrões automaticamente.

Ambiente de execução

Modo	Disponível nesta etapa
Portal Azure	Sim
PowerShell	Sim
CLI	Sim
IaC (Nenhuma)	Não

Tarefas

1. [Portal / CLI] Configure a hierarquia de Management Groups:

Tenant Root Group
└── STX-MG-Root
    ├── STX-MG-Production
    │   └── [Assinatura atual]
    └── STX-MG-Development

Mova a assinatura atual para STX-MG-Production. Atribua o papel Reader ao grupo STX-GG-Ops no escopo STX-MG-Root.

2. [Portal / CLI] Implemente as Azure Policies no escopo STX-MG-Production:

STX-POLICY-AllowedLocations: built-in Allowed locations, efeito Deny, parâmetros: eastus e brazilsouth
STX-POLICY-RequireTagProject: built-in Require a tag and its value on resources, tag Project, valor Strivex-Migration, efeito Deny
STX-POLICY-AuditVMSize: built-in Allowed virtual machine size SKUs em modo Audit, listar apenas Standard_B2s, Standard_B4ms, Standard_D2s_v3

Agrupe as três em uma Policy Initiative STX-INITIATIVE-Compliance. Execute um Compliance Scan e verifique os recursos não conformes (os RGs criados sem tag Project na Etapa 2 devem aparecer).

3. [Portal / CLI] Configure Resource Locks nos resource groups críticos:

STX-RG-Network: lock tipo CanNotDelete, nome STX-LOCK-Network-NoDel
STX-RG-Core: lock tipo ReadOnly, nome STX-LOCK-Core-RO

Tente deletar o resource group STX-RG-Network via Portal e confirme o bloqueio. Tente criar um recurso em STX-RG-Core via CLI e confirme que o lock ReadOnly impede modificações.

4. [Portal / CLI] Configure o Budget STX-BUDGET-Monthly na assinatura: valor USD 200, período Monthly. Configure alertas em 70% (USD 140), 90% (USD 180) e 100% (USD 200), todos notificando finops@strivex.com. Configure também um alerta de Azure Advisor para custos: em Advisor > Cost, implemente pelo menos uma recomendação de custo disponível (ou documente se não houver recomendações ativas). Adicione as tags Project=Strivex-Migration e Environment=Production em todos os 6 resource groups criados na Etapa 2 usando o comando az tag update em loop.

Valor capturado

Valor	Onde encontrar	Usado na etapa
Management Group `STX-MG-Production` ID	Portal > Management Groups	10
Policy Initiative `STX-INITIATIVE-Compliance` ID	Portal > Policy > Definitions	10
Budget `STX-BUDGET-Monthly`	Portal > Cost Management > Budgets	10

Critérios de validação

1. Confirme os Management Groups:

az account management-group show --name STX-MG-Production --query "{Name:name, Parent:details.parent.id}" -o json

Resultado esperado: STX-MG-Production com parent STX-MG-Root.

2. Confirme o lock no resource group de rede:

az lock list --resource-group STX-RG-Network --query "[].{Name:name, Level:level}" -o table

Resultado esperado: STX-LOCK-Network-NoDel com Level: CanNotDelete.

3. Confirme a policy de localização em compliance scan:

az policy state summarize --management-group STX-MG-Production --query "results.nonCompliantPolicies" -o table

Resultado esperado: número de políticas não conformes (pode ser > 0 antes da remediação de tags).

Etapa 4 — Configurar Acesso ao Storage

Contexto da etapa

A Strivex armazena vídeos de aulas (até 4 GB cada), materiais PDF e backups de banco de dados. O acesso ao storage precisa ser controlado: SAS tokens para os players de vídeo externos, políticas de acesso armazenadas para os sistemas internos, e autenticação baseada em identidade para os professores que fazem upload pelo portal de administração.

Ambiente de execução

Modo	Disponível nesta etapa
Portal Azure	Sim
PowerShell	Sim
CLI	Sim
IaC (Nenhuma)	Não

Tarefas

1. [Portal / CLI] Crie a Storage Account stxstorageprimary (nome único, sem hífens) no STX-RG-Storage, região East US, SKU Standard_GZRS, Kind StorageV2, HTTPS only, TLS mínimo TLS1_2, acesso público a blobs desabilitado. Configure o Firewall da storage account com ação padrão Deny e adicione a regra de IP 203.0.113.0/24 (rede de administração simulada). Configure o Trusted Azure Services como exceção permitida.

2. [Portal / PowerShell] Configure a autenticação baseada em identidade para Azure Files: habilite a integração com Microsoft Entra Kerberos na storage account stxstorageprimary em Data Storage > File shares > Active Directory. Atribua o papel Storage File Data SMB Share Contributor ao grupo STX-GG-Instructors no file share stx-share-instructors (criar na Etapa 5).

3. [Portal / CLI] Gere uma Service SAS para o container videos (a ser criado na Etapa 5) com: permissões Read e List, expiração em 7 dias, protocolo HTTPS only, IP range 0.0.0.0/0 (público, para players de vídeo). Crie uma Stored Access Policy STX-SAP-InternalAccess com permissões Read,Write,List válidas por 30 dias. Gerencie as Access Keys: confirme que há duas chaves, rotacione a Key 2 e verifique que a Key 1 permanece ativa.

4. [Portal / CLI] Configure as Diagnostic Settings da storage account stxstorageprimary para enviar logs de StorageRead, StorageWrite e StorageDelete para um Log Analytics Workspace STX-LAW-Core (crie o workspace no STX-RG-Core, SKU PerGB2018, retenção 90 dias). Este workspace será usado em todas as etapas de monitoramento.

Valor capturado

Valor	Onde encontrar	Usado na etapa
Storage Account name `stxstorageprimary`	Portal > Storage Account > Overview	5, 6, 9, 13
Connection String da `stxstorageprimary`	Portal > Storage Account > Access Keys	5, 9
Log Analytics Workspace ID `STX-LAW-Core`	Portal > LAW > Properties	9, 10, 13
SAS URI gerada	Saída do comando SAS	5

Critérios de validação

1. Confirme o SKU e acesso público:

az storage account show --name stxstorageprimary --resource-group STX-RG-Storage --query "{SKU:sku.name, PublicAccess:allowBlobPublicAccess, HTTPS:supportsHttpsTrafficOnly}" -o json

Resultado esperado: SKU: Standard_GZRS, PublicAccess: false, HTTPS: true.

2. Confirme o Firewall com ação padrão Deny:

az storage account show --name stxstorageprimary --resource-group STX-RG-Storage --query "networkRuleSet.defaultAction"

Resultado esperado: Deny.

3. Confirme o LAW criado:

az monitor log-analytics workspace show --workspace-name STX-LAW-Core --resource-group STX-RG-Core --query "{SKU:sku.name, RetentionDays:retentionInDays}" -o json

Resultado esperado: SKU: PerGB2018, RetentionDays: 90.

Etapa 5 — Configurar e Gerenciar Storage Accounts

Contexto da etapa

Com o acesso ao storage configurado, esta etapa provisiona os containers e file shares necessários para a operação da Strivex, configura a replicação e criptografia, e demonstra o uso do Storage Explorer e AzCopy para gerenciamento de dados. Os vídeos de aulas serão transferidos em massa via AzCopy simulando a migração dos servidores legados.

Ambiente de execução

Modo	Disponível nesta etapa
Portal Azure	Sim
PowerShell	Sim
CLI	Sim
Storage Explorer	Sim
AzCopy	Sim
IaC (Nenhuma)	Não

Tarefas

1. [Portal / CLI] Na storage account stxstorageprimary, configure a Object Replication para replicar o container videos para uma storage account secundária stxstoragedr (crie em STX-RG-DR, região Brazil South, SKU Standard_LRS). A replicação precisa de blob versioning habilitado em ambas as contas. Crie a Replication Policy com filtro de prefixo aulas/ (apenas vídeos de aulas replicados).

2. [Portal / CLI] Configure a storage account stxstorageprimary:

Habilite Blob Versioning
Habilite Blob Soft Delete com retenção de 14 dias
Habilite Container Soft Delete com retenção de 7 dias
Configure a Encryption: use Customer-managed keys (CMK) via Key Vault stx-kv-storage (crie o KV no STX-RG-Security com RBAC authorization). Crie uma chave RSA 4096 stx-storage-key no KV e configure a storage account para usar essa chave.

3. [Portal / Storage Explorer] Usando o Azure Storage Explorer, conecte-se à storage account stxstorageprimary via Connection String (capturada na Etapa 4). Crie o container videos (acesso privado) e o container thumbnails (acesso privado). Crie o file share stx-share-instructors com quota de 50 GB. Faça upload de um arquivo de teste teste-video.mp4 (crie um arquivo fictício de qualquer conteúdo) para o container videos/aulas/.

4. [CLI] Use o AzCopy para transferir arquivos em massa simulando a migração: execute azcopy copy para copiar todos os arquivos de uma pasta local ./materiais-legados/ (crie a pasta com 3 arquivos .pdf fictícios) para o container thumbnails da storage account stxstorageprimary. Use autenticação via SAS token gerada na Etapa 4. Confirme a transferência com azcopy jobs list.

Valor capturado

Valor	Onde encontrar	Usado na etapa
Storage Account DR `stxstoragedr`	Portal > Storage Account	13
Key Vault `stx-kv-storage` URI	Portal > Key Vault > Overview	6
Object Replication Policy ID	Portal > Storage Account > Object Replication	Validação

Critérios de validação

1. Confirme o Blob Versioning habilitado:

az storage account blob-service-properties show --account-name stxstorageprimary --query "isVersioningEnabled"

Resultado esperado: true.

2. Confirme o Soft Delete:

az storage blob service-properties delete-policy show --account-name stxstorageprimary --query "{Enabled:enabled, Days:days}" -o json

Resultado esperado: Enabled: true, Days: 14.

3. Confirme o arquivo no container após AzCopy:

az storage blob list --account-name stxstorageprimary --container-name thumbnails --query "[].name" -o table

Resultado esperado: os 3 arquivos .pdf listados.

Etapa 6 — Configurar Azure Files e Azure Blob Storage

Contexto da etapa

Os containers e file shares existem, mas precisam de configurações avançadas de ciclo de vida e tier para otimizar custos. Os vídeos antigos (mais de 90 dias sem acesso) devem migrar automaticamente para o tier Cool e depois Archive. Os file shares dos professores precisam de snapshots automáticos para proteção contra deleção acidental.

Ambiente de execução

Modo	Disponível nesta etapa
Portal Azure	Sim
PowerShell	Sim
CLI	Sim
IaC (Nenhuma)	Não

Tarefas

1. [Portal / CLI] Configure a Lifecycle Management Policy na storage account stxstorageprimary para o container videos:

Regra STX-LCM-VideosTierCool: se Last Modified > 30 dias e Last Access Time > 30 dias, mover para tier Cool
Regra STX-LCM-VideosArchive: se Last Modified > 90 dias, mover para tier Archive
Regra STX-LCM-ThumbnailsDelete: se Last Modified > 365 dias, deletar o blob

Habilite o Last Access Time Tracking na storage account para suportar a política baseada em acesso.

2. [Portal / CLI] Configure os storage tiers explicitamente nos containers existentes: defina o Access Tier padrão da storage account como Hot. Faça o upload de um segundo arquivo teste-antigo.mp4 no container videos e altere manualmente seu tier para Cool via az storage blob set-tier. Confirme a mudança de tier.

3. [Portal / CLI] Configure Snapshots e Soft Delete para Azure Files no file share stx-share-instructors:

Habilite Azure Backup para o file share (crie o Recovery Services Vault STX-RSV-FileShare no STX-RG-Security para este fim — o vault principal de backup será criado na Etapa 13)
Configure a política de snapshot com retenção: daily (30 dias), weekly (4 semanas), monthly (3 meses)
Habilite Soft Delete para file shares com período de retenção de 14 dias

4. [Portal / CLI] Configure a Blob Lifecycle Management adicional para versões de blob: adicione uma regra STX-LCM-OldVersionsDelete que deleta versões de blob mais antigas que 30 dias (não a versão atual). Confirme a regra com az storage account management-policy show.

Valor capturado

Valor	Onde encontrar	Usado na etapa
RSV `STX-RSV-FileShare`	Portal > Recovery Services Vault	13
Lifecycle Policy ID	Portal > Storage Account > Lifecycle Management	Validação

Critérios de validação

1. Confirme a política de lifecycle:

az storage account management-policy show --account-name stxstorageprimary --resource-group STX-RG-Storage --query "policy.rules[].name" -o table

Resultado esperado: STX-LCM-VideosTierCool, STX-LCM-VideosArchive, STX-LCM-ThumbnailsDelete, STX-LCM-OldVersionsDelete listados.

2. Confirme a mudança de tier do blob de teste:

az storage blob show --account-name stxstorageprimary --container-name videos --name teste-antigo.mp4 --query "properties.blobTier"

Resultado esperado: Cool.

3. Confirme o Soft Delete para file shares:

az storage account file-service-properties show --account-name stxstorageprimary --query "shareDeleteRetentionPolicy.{Enabled:enabled, Days:days}" -o json

Resultado esperado: Enabled: true, Days: 14.

Etapa 7 — Automatizar Implantação com ARM Templates

Contexto da etapa

O time de infraestrutura da Strivex precisa padronizar a implantação de ambientes de desenvolvimento para novos cursos. ARM Templates garantirão que cada ambiente seja idêntico e auditável. Esta etapa exporta o ARM Template do storage já configurado, modifica-o para parametrizar a região, e implanta um segundo ambiente de storage para a equipe de P&D.

Ambiente de execução

Modo	Disponível nesta etapa
Portal Azure	Sim
PowerShell	Sim
CLI	Sim
IaC (Nenhuma)	Não

Tarefas

1. [Portal / CLI] Exporte o ARM Template do resource group STX-RG-Storage via STX-RG-Storage > Export template. Baixe o template e parâmetros. Analise o arquivo JSON exportado e identifique: o tipo de recurso da storage account, os parâmetros que precisam ser dinâmicos (nome, localização, SKU) e as propriedades que devem ser hardcoded. Modifique o template para parametrizar storageAccountName, location e skuName.

2. [CLI] Valide o template modificado com az deployment group validate antes de implantar, usando o resource group STX-RG-Apps como destino e os parâmetros: name stxstoragedev, location eastus, sku Standard_LRS. Corrija qualquer erro de validação. Implante o template validado com az deployment group create fornecendo os parâmetros inline.

3. [Portal / CLI] Converta o ARM Template para Bicep: use o comando az bicep decompile no arquivo template.json exportado. Abra o arquivo .bicep gerado e ajuste manualmente qualquer aviso produzido pelo decompiler (geralmente relacionado a expressões não suportadas). Valide o arquivo Bicep com az bicep build para confirmar que não há erros de sintaxe.

4. [Portal] Implante o arquivo Bicep modificado usando o Azure Portal > Deploy a custom template > Build your own template in the editor: cole o conteúdo do arquivo .bicep (ou o JSON equivalente), configure os parâmetros para criar stxstoragedev2 em eastus, e confirme a implantação. Verifique o deployment history em STX-RG-Apps > Deployments.

Valor capturado

Valor	Onde encontrar	Usado na etapa
Deployment ID do ARM Template	`az deployment group list --resource-group STX-RG-Apps`	Documentação
Storage `stxstoragedev` criada	Portal > Storage Accounts	Validação

Critérios de validação

1. Confirme a storage implantada via ARM:

az storage account show --name stxstoragedev --resource-group STX-RG-Apps --query "{SKU:sku.name, State:provisioningState}" -o json

Resultado esperado: SKU: Standard_LRS, State: Succeeded.

2. Confirme o deployment history:

az deployment group list --resource-group STX-RG-Apps --query "[].{Name:name, State:properties.provisioningState, Timestamp:properties.timestamp}" -o table

Resultado esperado: pelo menos 2 deployments com State: Succeeded.

3. Confirme que o arquivo Bicep é válido:

az bicep build --file template.bicep

Resultado esperado: sem erros na saída, arquivo template.json gerado com sucesso.

Etapa 8 — Criar e Configurar Máquinas Virtuais

Contexto da etapa

O backend da API da plataforma Strivex roda em dois servidores Windows Server 2022 em alta disponibilidade. O servidor de streaming roda em Linux Ubuntu 22.04. Esta etapa implanta as VMs com alta disponibilidade, configura encryption at host e os discos de dados, e move uma VM de teste para o resource group correto.

Diagrama da etapa

STX-RG-Apps (East US)
  ├── STX-AVSET-API (Availability Set: 3 FD, 5 UD)
  │   ├── STX-VM-API-01 (Windows Server 2022, Standard_B4ms)
  │   └── STX-VM-API-02 (Windows Server 2022, Standard_B4ms)
  └── STX-VMSS-Streaming (VM Scale Set, Ubuntu 22.04)
      ├── Instance 0
      └── Instance 1

STX-RG-Core (East US)
  └── STX-VM-Test (Ubuntu 22.04, Standard_B2s) — a mover para STX-RG-Apps

Ambiente de execução

Modo	Disponível nesta etapa
Portal Azure	Sim
PowerShell	Sim
CLI	Sim
IaC (Nenhuma)	Não

Tarefas

1. [Portal / CLI] Crie o Availability Set STX-AVSET-API no STX-RG-Apps, região East US, 3 Fault Domains e 5 Update Domains. Implante as VMs:

STX-VM-API-01 e STX-VM-API-02: Windows Server 2022 Datacenter, Standard_B4ms, disco OS Premium SSD 128 GB, sem IP público, no STX-AVSET-API. Para cada VM, adicione dois discos de dados Premium SSD de 128 GB (um para dados da API, um para logs).

2. [Portal / CLI] Habilite o Encryption at Host nas duas VMs SAP. Primeiro, registre o feature provider: az feature register --namespace Microsoft.Compute --name EncryptionAtHost. Aguarde o estado Registered e re-registre o provider. Em cada VM, em Settings > Disks > Additional settings, habilite Encryption at host. Confirme que a VM precisa ser desalocada para aplicar a configuração.

3. [Portal / CLI] Crie a VM de teste STX-VM-Test (Ubuntu 22.04, Standard_B2s) no resource group STX-RG-Core (intencionalmente errado). Em seguida, mova a VM para STX-RG-Apps usando Portal > VM > Overview > Move > Move to another resource group. Após a movimentação, confirme que todos os recursos dependentes (NIC, disco OS, IP público se houver) foram movidos junto.

4. [Portal / CLI] Implante o VM Scale Set STX-VMSS-Streaming:

Imagem: Ubuntu Server 22.04 LTS
SKU: Standard_D2s_v3
Instâncias iniciais: 2, mínimo 1, máximo 5
Orchestration mode: Uniform
Scaling: CPU > 75% por 5 minutos adiciona 1 instância; CPU < 25% por 10 minutos remove 1
Upgrade policy: Rolling, batch size 20%
Disco de dados: 64 GB adicionado a cada instância

Valor capturado

Valor	Onde encontrar	Usado na etapa
Resource IDs das VMs API	Portal > VM > Properties	9, 10, 13
VMSS name `STX-VMSS-Streaming`	Portal > VM Scale Sets	10, 12
Availability Set ID	Portal > Availability Set > Properties	13

Critérios de validação

1. Confirme as VMs no Availability Set:

az vm availability-set show --name STX-AVSET-API --resource-group STX-RG-Apps --query "virtualMachines[].id" -o table

Resultado esperado: 2 IDs de VMs listados.

2. Confirme a VM movida para o RG correto:

az vm show --name STX-VM-Test --resource-group STX-RG-Apps --query "resourceGroup" -o tsv

Resultado esperado: STX-RG-Apps.

3. Confirme o VMSS com autoscale configurado:

az monitor autoscale list --resource-group STX-RG-Apps --query "[?name=='STX-VMSS-Streaming-Autoscale'].{Name:name, Min:profiles[0].capacity.minimum, Max:profiles[0].capacity.maximum}" -o table

Resultado esperado: Min: 1, Max: 5.

Etapa 9 — Provisionar e Gerenciar Contêineres

Contexto da etapa

O time de produto da Strivex está migrando o microserviço de notificações para contêineres. O Azure Container Registry armazenará as imagens. O Azure Container Apps substituirá o monolito de notificações com auto-scaling. Uma Container Instance será usada para jobs de processamento de relatórios agendados.

Ambiente de execução

Modo	Disponível nesta etapa
Portal Azure	Sim
PowerShell	Sim
CLI	Sim
IaC (Nenhuma)	Não

Tarefas

1. [CLI] Crie o Azure Container Registry stxacr (nome único, sem hífens) no STX-RG-Apps, SKU Standard, região East US. Habilite o admin user. Construa e faça push de uma imagem de contêiner simples diretamente no ACR usando az acr build com um Dockerfile local:

FROM node:20-alpine
WORKDIR /app
RUN echo '{"status":"ok","service":"notifications"}' > response.json
CMD ["node", "-e", "const h=require('http');h.createServer((_,r)=>{r.writeHead(200,{'Content-Type':'application/json'});r.end(require('fs').readFileSync('response.json'))}).listen(3000)"]
EXPOSE 3000

Tag a imagem como stxacr.azurecr.io/notifications:1.0.

2. [Portal / CLI] Crie o Azure Container Apps Environment STX-CAE-Production no STX-RG-Apps, usando o Log Analytics Workspace STX-LAW-Core criado na Etapa 4. Implante o Container App stx-ca-notifications usando a imagem stxacr.azurecr.io/notifications:1.0:

CPU: 0.5 vCPU, Memória: 1 Gi
Réplicas mínimas: 1, máximas: 5
Regra de scaling: HTTP requests, threshold 100 req/s por réplica
Ingress: external, porta 3000, sem TLS (para lab)

3. [Portal / CLI] Crie um Azure Container Instance STX-ACI-ReportJob no STX-RG-Apps para o job de relatórios:

Imagem: mcr.microsoft.com/azure-cli:latest (imagem pública)
CPU: 1, Memória: 1.5 GB
OS: Linux
Restart Policy: OnFailure
Environment variable: STORAGE_ACCOUNT=stxstorageprimary
Command: ["az", "storage", "blob", "list", "--account-name", "stxstorageprimary", "--container-name", "videos", "--output", "table"] (requer identidade ou SAS)

4. [Portal / CLI] Gerencie o scaling do Container App stx-ca-notifications: acesse Container Apps > stx-ca-notifications > Scale and replicas. Confirme o estado atual (1 réplica). Configure uma regra adicional de scaling baseada em CPU (50% threshold). Verifique os logs do container em Container Apps > stx-ca-notifications > Log stream e confirme que o serviço responde em HTTP.

Valor capturado

Valor	Onde encontrar	Usado na etapa
ACR Login Server `stxacr.azurecr.io`	Portal > ACR > Overview	12, Validação
Container App URL	Portal > Container Apps > Overview	Validação
Container Apps Environment ID	Portal > CAE > Properties	12

Critérios de validação

1. Confirme a imagem no ACR:

az acr repository list --name stxacr --query "[?contains(@,'notifications')]" -o table

Resultado esperado: notifications listado.

2. Confirme o Container App respondendo:

curl https://<Container-App-URL>/

Resultado esperado: {"status":"ok","service":"notifications"}.

3. Confirme o Container Instance criado:

az container show --name STX-ACI-ReportJob --resource-group STX-RG-Apps --query "instanceView.state" -o tsv

Resultado esperado: Running ou Terminated (se o job concluiu).

Etapa 10 — Criar e Configurar Azure App Service

Contexto da etapa

O portal web da Strivex (frontend Next.js) será hospedado no Azure App Service com deployment slots para releases sem downtime. A aplicação precisa de certificado TLS, integração com a VNet (para acessar as VMs de API) e backup automático. O SSPR configurado na Etapa 1 deve ser acessível pelo portal.

Ambiente de execução

Modo	Disponível nesta etapa
Portal Azure	Sim
PowerShell	Sim
CLI	Sim
IaC (Nenhuma)	Não

Tarefas

1. [Portal / CLI] Crie o App Service Plan STX-ASP-Portal no STX-RG-Apps, região East US, SKU P2v3 (necessário para VNet Integration), OS Linux. Crie o App Service stx-portal-strivex (nome globalmente único) usando o plano STX-ASP-Portal, runtime Node 20 LTS.

Configure as Application Settings:

API_BASE_URL: http://10.10.1.100 (IP interno do ILB a ser criado na Etapa 12)
STORAGE_ACCOUNT: stxstorageprimary
ENVIRONMENT: Production
NODE_ENV: production

2. [Portal / CLI] Configure o custom DNS no App Service stx-portal-strivex: em Custom domains, adicione o hostname portal.strivex.com.br (crie a zona DNS strivex.com.br no STX-RG-Network com um registro CNAME portal apontando para stx-portal-strivex.azurewebsites.net). Configure um certificado TLS gerenciado pelo App Service (gratuito, via Certificates > Managed certificate) para o domínio customizado.

3. [Portal / CLI] Configure os Deployment Slots:

Slot staging: clone das configurações do slot de produção com ENVIRONMENT=Staging não clonado
Implante um HTML estático de teste no slot staging via az webapp deployment source config-zip
Execute o slot swap de staging para produção e confirme que o conteúdo foi promovido
Configure o Auto Swap do slot staging para produção

4. [Portal / CLI] Configure o Backup do App Service stx-portal-strivex: em Settings > Backup, configure backups automáticos para a storage account stxstorageprimary, container backups, frequência de 1 dia, retenção de 30 dias. Execute um backup manual imediato e confirme o arquivo .zip no container backups. Configure a VNet Integration com a subnet STX-SNET-Apps (a ser criada na Etapa 11; documente e aplique após a criação da VNet).

Valor capturado

Valor	Onde encontrar	Usado na etapa
App Service URL	Portal > App Service > Overview	12, 13, Validação
App Service Plan ID	Portal > ASP > Properties	12
Deployment Slot `staging` URL	Portal > Deployment Slots	Validação

Critérios de validação

1. Confirme o App Service running:

az webapp show --name stx-portal-strivex --resource-group STX-RG-Apps --query "{State:state, DefaultHostname:defaultHostName}" -o json

Resultado esperado: State: Running, hostname correto.

2. Confirme o deployment slot staging:

az webapp deployment slot list --name stx-portal-strivex --resource-group STX-RG-Apps --query "[].{Name:name, State:state}" -o table

Resultado esperado: slot staging com State: Running.

3. Confirme o backup automático configurado:

az webapp config backup show --resource-group STX-RG-Apps --webapp-name stx-portal-strivex --query "{Enabled:backupSchedule.enabled, Frequency:backupSchedule.frequencyInterval, Container:storageAccountUrl}" -o json

Resultado esperado: Enabled: true, Frequency: 1.

Etapa 11 — Configurar e Gerenciar Redes Virtuais no Azure

Contexto da etapa

Com os recursos de aplicação implantados, a Strivex precisa da infraestrutura de rede para conectar tudo de forma segura. A VNet principal em East US conectará VMs, App Services, containers e Private Endpoints. Um peering com a VNet de DR no Brazil South garantirá failover de rede.

Diagrama da etapa

STX-VNET-EastUS (10.10.0.0/16)
  ├── STX-SNET-Core     (10.10.1.0/24) — VMs de API
  ├── STX-SNET-Apps     (10.10.2.0/24) — App Service, Containers
  ├── STX-SNET-Data     (10.10.3.0/24) — Private Endpoints
  ├── STX-SNET-GW       (10.10.0.0/27) — Gateway subnet
  └── AzureBastionSubnet (10.10.0.32/27)

STX-VNET-BrazilSouth (10.20.0.0/16)
  ├── STX-SNET-DR       (10.20.1.0/24)
  └── STX-SNET-Data-DR  (10.20.2.0/24)

Peering ←──────────────────────────────► Peering
STX-PEER-EUS-to-BR                        STX-PEER-BR-to-EUS

Ambiente de execução

Modo	Disponível nesta etapa
Portal Azure	Sim
PowerShell	Sim
CLI	Sim
IaC (Nenhuma)	Não

Tarefas

1. [Portal / CLI] Crie as VNets:

STX-VNET-EastUS no STX-RG-Network, East US, 10.10.0.0/16, com todas as subnets do diagrama. Configure STX-SNET-Apps com delegação para Microsoft.Web/serverFarms. Configure STX-SNET-Data com privateEndpointNetworkPolicies: Disabled.
STX-VNET-BrazilSouth no STX-RG-DR, Brazil South, 10.20.0.0/16, com as subnets STX-SNET-DR e STX-SNET-Data-DR.

Mova as NICs das VMs STX-VM-API-01 e STX-VM-API-02 para a subnet STX-SNET-Core (realoque as NICs se as VMs foram criadas sem VNet configurada).

2. [Portal / CLI] Configure o VNet Peering entre as duas VNets:

STX-PEER-EUS-to-BR: de STX-VNET-EastUS para STX-VNET-BrazilSouth, allowForwardedTraffic: true
STX-PEER-BR-to-EUS: de STX-VNET-BrazilSouth para STX-VNET-EastUS, allowForwardedTraffic: true

3. [Portal / CLI] Configure os Public IP Addresses: crie STX-PIP-LB (Standard, Static, zone-redundant 1 2 3, região East US) para o Load Balancer da Etapa 12. Configure um User-Defined Route (Route Table) STX-RT-Apps para a subnet STX-SNET-Apps com a rota 0.0.0.0/0 → 10.10.1.4 (NVA simulado; use o IP privado futuro de uma VM NVA). Associe o Route Table à subnet.

4. [Portal / CLI] Configure o Azure DNS: crie a zona DNS privada strivex.internal vinculada à STX-VNET-EastUS com auto-registration. Adicione os registros A manualmente: api → 10.10.1.100 (ILB), storage → 10.10.3.10 (Private Endpoint). Confirme a resolução DNS da VM STX-VM-API-01 (via Bastion a ser criado na Etapa 12) após a configuração.

Valor capturado

Valor	Onde encontrar	Usado na etapa
VNet ID `STX-VNET-EastUS`	Portal > VNet > Properties	12, 13
Subnet IDs (todas as subnets)	Portal > VNet > Subnets	12
IP `STX-PIP-LB`	Portal > Public IP > Overview	12

Critérios de validação

1. Confirme as VNets e peerings:

az network vnet peering list --vnet-name STX-VNET-EastUS --resource-group STX-RG-Network --query "[].{Name:name, State:peeringState}" -o table

Resultado esperado: STX-PEER-EUS-to-BR com State: Connected.

2. Confirme o Route Table associado:

az network vnet subnet show --vnet-name STX-VNET-EastUS --name STX-SNET-Apps --resource-group STX-RG-Network --query "routeTable.id" -o tsv

Resultado esperado: Resource ID de STX-RT-Apps.

3. Confirme a zona DNS privada vinculada:

az network private-dns link vnet list --resource-group STX-RG-Network --zone-name strivex.internal --query "[].{VNet:virtualNetwork.id, State:virtualNetworkLinkState}" -o table

Resultado esperado: vínculo com State: Completed para STX-VNET-EastUS.

Etapa 12 — Configurar Acesso Seguro a Redes Virtuais

Contexto da etapa

Com a rede estruturada, a Strivex precisa implementar segurança em camadas: NSGs para microsegmentação, Azure Bastion para acesso administrativo sem IP público, Service Endpoints para otimizar o acesso às PaaS services e Private Endpoints para que o banco de dados e o storage nunca trafeguem pela internet pública. Esta etapa demonstra o acesso desprotegido antes de aplicar os controles.

Ambiente de execução

Modo	Disponível nesta etapa
Portal Azure	Sim
PowerShell	Sim
CLI	Sim
IaC (Nenhuma)	Não

Tarefas

1. [Portal / CLI] Demonstre a ausência de controle: verifique que as VMs STX-VM-API-01 e STX-VM-API-02 não têm NSG associado. Tente um acesso RDP/SSH direto a uma das VMs (vai falhar por não ter IP público, mas demonstre que a subnet está sem restrições via az network nic show). Crie os NSGs e ASGs:

ASG STX-ASG-APIServers: associe às NICs das VMs API
NSG STX-NSG-Core: regras: Allow HTTPS 443 de AzureLoadBalancer, Allow RDP 3389 de AzureBastionSubnet, Deny All inbound. Associe à subnet STX-SNET-Core.
NSG STX-NSG-Data: Allow SQL 1433 de STX-ASG-APIServers, Deny All. Associe à subnet STX-SNET-Data.

2. [Portal / CLI] Configure o Azure Bastion STX-BASTION na subnet AzureBastionSubnet da STX-VNET-EastUS, SKU Standard. Configure o NSG STX-NSG-Bastion com as regras obrigatórias da Microsoft. Conecte-se a STX-VM-API-01 via Bastion e confirme o acesso RDP sem IP público.

3. [Portal / CLI] Configure os Private Endpoints para o storage na subnet STX-SNET-Data:

STX-PE-Storage-Blob: aponta para stxstorageprimary, sub-resource blob, IP estático 10.10.3.10
STX-PE-Storage-File: aponta para stxstorageprimary, sub-resource file, IP 10.10.3.11

Crie as zonas DNS privadas privatelink.blob.core.windows.net e privatelink.file.core.windows.net, vincule à STX-VNET-EastUS e integre aos Private Endpoints. Confirme a resolução privada de stxstorageprimary.blob.core.windows.net de dentro da VM.

4. [Portal / CLI] Configure os Service Endpoints na subnet STX-SNET-Apps: adicione Microsoft.Storage e Microsoft.KeyVault. Configure a Virtual Network Rule na storage account stxstorageprimary e no Key Vault stx-kv-storage permitindo tráfego de STX-SNET-Apps. Crie e configure o Load Balancer interno STX-ILB-API (Standard SKU):

Frontend IP: 10.10.1.100 na subnet STX-SNET-Core
Backend Pool: STX-VM-API-01 e STX-VM-API-02
Health Probe: TCP 443, intervalo 5s
Load Balancing Rule: TCP 443, Session Persistence None

Valor capturado

Valor	Onde encontrar	Usado na etapa
Private Endpoint IP `10.10.3.10`	Portal > Private Endpoint > Overview	13, 14
ILB Frontend IP `10.10.1.100`	Portal > Load Balancer > Frontend IP	10, 13, 14
Bastion `STX-BASTION`	Portal > Bastion	13

Critérios de validação

1. Confirme o NSG associado e as regras:

az network vnet subnet show --vnet-name STX-VNET-EastUS --name STX-SNET-Core --resource-group STX-RG-Network --query "networkSecurityGroup.id" -o tsv

Resultado esperado: Resource ID de STX-NSG-Core.

2. Confirme resolução privada do storage (execute em STX-VM-API-01 via Bastion):

nslookup stxstorageprimary.blob.core.windows.net

Resultado esperado: IP 10.10.3.10 (não o IP público da Microsoft).

3. Confirme o ILB com backend pool:

az network lb show --name STX-ILB-API --resource-group STX-RG-Network --query "{Frontend:frontendIPConfigurations[0].privateIPAddress, BackendCount:length(backendAddressPools[0].backendIPConfigurations)}" -o json

Resultado esperado: Frontend: 10.10.1.100, BackendCount: 2.

Etapa 13 — Configurar Resolução de Nomes e Load Balancing

Contexto da etapa

Com a rede segura, esta etapa verifica e aprofunda a resolução de nomes DNS (pública e privada) e diagnostica problemas de conectividade no Load Balancer. Uma falha deliberada será introduzida no health probe do ILB para exercitar o troubleshooting com Network Watcher.

Ambiente de execução

Modo	Disponível nesta etapa
Portal Azure	Sim
PowerShell	Sim
CLI	Sim
IaC (Nenhuma)	Não

Tarefas

1. [Portal / CLI] Aprofunde a configuração do Azure DNS público: na zona strivex.com.br (criada na Etapa 10), adicione:

Registro A api → STX-PIP-LB (IP público do LB) com TTL 300
Registro CNAME www → stx-portal-strivex.azurewebsites.net com TTL 300
Registro TXT @ → v=spf1 include:protection.outlook.com -all com TTL 3600

Confirme a resolução pública com nslookup portal.strivex.com.br de uma máquina externa (pode ser do Azure Cloud Shell).

2. [Portal / CLI] Crie um Public Load Balancer STX-PLB-Streaming (Standard, zona-redundante) para o VMSS de streaming:

Frontend IP: STX-PIP-LB (já criado na Etapa 11)
Backend Pool: instâncias do STX-VMSS-Streaming
Health Probe: HTTP, porta 80, path /health, intervalo 15s
Load Balancing Rule: TCP 80, Session Persistence None
Inbound NAT rule pool para SSH nas instâncias: porta 50001+ → porta 22

3. [Portal] Simule uma falha deliberada no Load Balancer: altere o health probe do STX-PLB-Streaming para uma porta incorreta (porta 9999). Aguarde 2-3 minutos e confirme que o backend pool fica Unhealthy em Load Balancer > Backend pools. Use o Network Watcher > Connection Troubleshoot para diagnosticar a falha entre o LB e uma instância do VMSS. Corrija o probe voltando para a porta correta.

4. [Portal / CLI] Use o Network Watcher para troubleshooting adicional:

Effective Security Rules: verifique as regras efetivas na NIC de STX-VM-API-01
Next Hop: confirme o próximo salto de STX-VM-API-01 para stxstorageprimary.blob.core.windows.net via Private Endpoint
Packet Capture: inicie uma captura de pacotes em STX-VM-API-01 por 60 segundos, salve em stxstorageprimary container diagnostics (crie o container)

Valor capturado

Valor	Onde encontrar	Usado na etapa
PLB `STX-PLB-Streaming` IP	Portal > Load Balancer > Frontend	Validação
Next Hop result	Network Watcher	Documentação

Critérios de validação

1. Confirme a resolução DNS pública:

nslookup api.strivex.com.br

Resultado esperado: IP público de STX-PIP-LB.

2. Confirme o health probe do PLB funcionando após correção:

az network lb probe list --lb-name STX-PLB-Streaming --resource-group STX-RG-Network --query "[].{Name:name, Port:port, Protocol:protocol}" -o table

Resultado esperado: probe com Port: 80, Protocol: Http.

3. Confirme o backend pool do PLB saudável: Portal > STX-PLB-Streaming > Backend pools > verificar estado de saúde das instâncias do VMSS. Resultado esperado: pelo menos 1 instância com Health: Healthy.

Etapa 14 — Monitorar Recursos no Azure

Contexto da etapa

Com toda a infraestrutura implantada, a Strivex precisa de visibilidade completa do ambiente. O Log Analytics Workspace STX-LAW-Core já recebe logs do storage. Esta etapa centraliza todos os logs das VMs, containers, redes e App Service, configura alertas proativos e queries KQL para detecção de anomalias.

Ambiente de execução

Modo	Disponível nesta etapa
Portal Azure	Sim
PowerShell	Sim
CLI	Sim
IaC (Nenhuma)	Não

Tarefas

1. [Portal / CLI] Conecte todos os recursos ao STX-LAW-Core via Diagnostic Settings:

VMs STX-VM-API-01 e STX-VM-API-02: instale o Azure Monitor Agent (AMA) via Extension, crie um Data Collection Rule STX-DCR-VMs coletando Performance Counters (CPU, Disk, Network) e Windows Event Logs (System, Application, Security)
App Service stx-portal-strivex: Diagnostic Settings enviando AppServiceHTTPLogs, AppServiceConsoleLogs e métricas para STX-LAW-Core
Load Balancers STX-ILB-API e STX-PLB-Streaming: enviar LoadBalancerAlertEvent e métricas

2. [Portal] Configure os Alert Rules no Azure Monitor vinculados a um Action Group STX-AG-Alerts (e-mail ops@strivex.com.br):

STX-ALERT-HighCPU: métrica Percentage CPU > 80% por 5 minutos em qualquer VM do STX-RG-Apps, severidade 2
STX-ALERT-LBUnhealthy: métrica Health Probe Status = 0 em STX-PLB-Streaming, severidade 1
STX-ALERT-StorageCost: alert de custo quando gasto em storage ultrapassa USD 30 no mês, severidade 3

3. [Portal] Execute as seguintes queries no Log Analytics (Azure Monitor > Logs):

// Top 10 VMs por CPU nos últimos 30 minutos
Perf
| where ObjectName == "Processor" and CounterName == "% Processor Time"
| where TimeGenerated > ago(30m)
| summarize AvgCPU = avg(CounterValue) by Computer
| top 10 by AvgCPU desc

// Requisições HTTP 5xx no App Service
AppServiceHTTPLogs
| where ScStatus >= 500
| summarize ErrorCount = count() by CsUriStem, ScStatus
| order by ErrorCount desc
| take 20

4. [Portal] Configure o Network Watcher Connection Monitor: crie o monitor STX-CM-API-to-Storage testando conectividade de STX-VM-API-01 para stxstorageprimary.blob.core.windows.net na porta 443, intervalo 30 segundos. Acesse Azure Monitor Insights > VM Insights para STX-VM-API-01 e verifique o mapa de dependências. Configure Storage Insights em Azure Monitor > Storage accounts apontando para stxstorageprimary.

Valor capturado

Valor	Onde encontrar	Usado na etapa
Data Collection Rule ID	Portal > DCR > Properties	15
Action Group `STX-AG-Alerts` ID	Portal > Monitor > Action Groups	15
Connection Monitor `STX-CM-API-to-Storage`	Portal > Network Watcher	15

Critérios de validação

1. Confirme o AMA instalado e dados chegando ao LAW:

az monitor log-analytics query --workspace STX-LAW-Core --analytics-query "Perf | where Computer contains 'STX-VM-API' | take 5" --timespan PT1H --query "tables[0].rows" -o table

Resultado esperado: pelo menos 5 linhas de dados de performance.

2. Confirme o Alert Rule criado:

az monitor metrics alert list --resource-group STX-RG-Apps --query "[].{Name:name, Severity:severity, Enabled:enabled}" -o table

Resultado esperado: STX-ALERT-HighCPU e STX-ALERT-LBUnhealthy listados com Enabled: true.

3. Confirme o Connection Monitor ativo:

az network watcher connection-monitor list --location eastus --query "[?name=='STX-CM-API-to-Storage'].{Name:name, State:provisioningState}" -o table

Resultado esperado: STX-CM-API-to-Storage com State: Succeeded.

Etapa 15 — Implementar Backup e Recuperação

Contexto da etapa

Esta etapa final configura a proteção completa do ambiente: backup das VMs de API, replicação para DR no Brazil South via Azure Site Recovery e verificação dos relatórios de backup. Uma falha simulada de VM testará o processo de restore end-to-end.

Ambiente de execução

Modo	Disponível nesta etapa
Portal Azure	Sim
PowerShell	Sim
CLI	Sim
IaC (Nenhuma)	Não

Tarefas

1. [Portal / CLI] Crie o Recovery Services Vault STX-RSV-Backup no STX-RG-Security, região East US, com storage redundancy Geo-redundant. Crie também o Azure Backup Vault STX-BAV-Blobs no STX-RG-Security para backup de blobs (os dois tipos de vault têm propósitos diferentes). Configure a Backup Policy STX-BKPOLICY-VMs para VMs:

Frequência: diária às 02:00 BRT
Retenção: 30 dias pontos diários, 12 semanas pontos semanais, 12 meses pontos mensais
Tipo: Enhanced Policy (suporta backups por hora)

2. [Portal / CLI] Habilite o backup para as VMs STX-VM-API-01 e STX-VM-API-02 usando a política STX-BKPOLICY-VMs no vault STX-RSV-Backup. Execute um backup manual imediato para ambas as VMs. Confirme o progresso em Backup Jobs no vault.

3. [Portal] Configure o Azure Site Recovery para replicação DR:

No vault STX-RSV-Backup, configure o Site Recovery
Replique STX-VM-API-01 para a região Brazil South:
- VNet de destino: STX-VNET-BrazilSouth, subnet STX-SNET-DR
- Storage de destino: crie stxstoragedrcache em East US (cache storage) e use stxstoragedr (já criada na Etapa 5) como destino
- Resource Group de destino: STX-RG-DR
Aguarde a replicação inicial e confirme Replication health: Healthy

4. [Portal] Execute um Test Failover de STX-VM-API-01 para a subnet STX-SNET-DR do Brazil South. Confirme que a VM réplica é acessível via Bastion (provisione um Bastion em STX-VNET-BrazilSouth ou use outro método de acesso). Após validar, execute Cleanup test failover. Configure os Reports e Alertas de Backup: em Backup Reports no vault, configure os relatórios para enviar para STX-LAW-Core. Crie um alerta para Backup job failed com notificação para ops@strivex.com.br via Action Group STX-AG-Alerts.

Valor capturado

Valor	Onde encontrar	Usado na etapa
RSV `STX-RSV-Backup` ID	Portal > RSV > Properties	Validação
ASR Replication Health	Portal > RSV > Replicated Items	Validação
Test Failover VM IP	Portal > VM réplica > Networking	Validação

Critérios de validação

1. Confirme backup configurado e job concluído:

az backup job list --resource-group STX-RG-Security --vault-name STX-RSV-Backup --query "[?status=='Completed'].{VM:properties.entityFriendlyName, Status:status, Duration:properties.duration}" -o table

Resultado esperado: 2 jobs completados para STX-VM-API-01 e STX-VM-API-02.

2. Confirme a replicação ASR saudável:

az site-recovery replication-protected-item list --vault-name STX-RSV-Backup --resource-group STX-RG-Security --query "[].{Name:name, Health:properties.replicationHealth, RTO:properties.rpoInSeconds}" -o table

Resultado esperado: STX-VM-API-01 com Health: Normal.

3. Confirme o alerta de backup configurado: Portal > STX-RSV-Backup > Backup Alerts > Alert Rules: alerta Backup job failed listado como Enabled.

Validação Global do Ambiente

Checklist de recursos criados

Recurso	Tipo	Estado esperado
`STX-GG-Developers`, `STX-GG-Ops`, `STX-GG-Instructors`	Entra ID Groups	Membros corretos; SSPR configurado
`STX-GG-AllBrazilUsers`	Grupo Dinâmico	Regra `usageLocation -eq "BR"` ativa
`pedro.dev`, `ana.ops`, `lucas.instrutor`	Usuários Entra ID	Licenças atribuídas via grupo
`prof.externo#EXT#`	Guest User	Convite aceito ou pendente
`STX-ROLE-AppDeploy`	Custom RBAC Role	Atribuído a `pedro.dev` em `STX-RG-Apps`
`STX-MG-Root` / `STX-MG-Production` / `STX-MG-Development`	Management Groups	Assinatura em `STX-MG-Production`
`STX-INITIATIVE-Compliance`	Policy Initiative	3 policies; compliance scan executado
`STX-LOCK-Network-NoDel` / `STX-LOCK-Core-RO`	Resource Locks	CanNotDelete / ReadOnly
`STX-BUDGET-Monthly`	Cost Budget	USD 200; alertas 70%/90%/100%
`STX-RG-Core` / `STX-RG-Apps` / `STX-RG-Storage` / `STX-RG-Network` / `STX-RG-Security` / `STX-RG-DR`	Resource Groups	Tags `Project` e `Environment` aplicadas
`stxstorageprimary`	Storage Account	Standard_GZRS; Firewall Deny; Versioning; Soft Delete; CMK
`stxstoragedr`	Storage Account	Standard_LRS; Brazil South; Replication Policy
`stxstoragedev`	Storage Account	Standard_LRS; implantado via ARM
`STX-LAW-Core`	Log Analytics Workspace	PerGB2018; 90 dias; conectado ao Defender e recursos
`stx-kv-storage`	Key Vault	RBAC auth; chave `stx-storage-key` RSA 4096
`STX-AVSET-API`	Availability Set	3 FD, 5 UD; 2 VMs
`STX-VM-API-01` / `STX-VM-API-02`	Windows Server 2022 VMs	Encryption at host; discos de dados; em `STX-SNET-Core`
`STX-VMSS-Streaming`	VM Scale Set	Ubuntu 22.04; autoscale 1-5; rolling upgrade
`stxacr`	Container Registry	Standard; imagem `notifications:1.0`
`STX-CAE-Production`	Container Apps Environment	Conectado ao `STX-LAW-Core`
`stx-ca-notifications`	Container App	1-5 réplicas; ingress externo porta 3000
`STX-ACI-ReportJob`	Container Instance	Linux; `OnFailure` restart
`STX-ASP-Portal`	App Service Plan	P2v3; Linux
`stx-portal-strivex`	App Service	Node 20; TLS; deployment slots; backup
`STX-VNET-EastUS`	VNet	`10.10.0.0/16`; 5 subnets; peering ativo
`STX-VNET-BrazilSouth`	VNet	`10.20.0.0/16`; 2 subnets
`STX-NSG-Core` / `STX-NSG-Data` / `STX-NSG-Bastion`	NSGs	Regras corretas; subnets associadas
`STX-ASG-APIServers`	Application Security Group	NICs das VMs API associadas
`STX-BASTION`	Azure Bastion	Standard SKU; AzureBastionSubnet
`STX-PE-Storage-Blob` / `STX-PE-Storage-File`	Private Endpoints	IPs `10.10.3.10/11`; DNS integrado
`STX-ILB-API`	Internal Load Balancer	Frontend `10.10.1.100`; 2 VMs
`STX-PLB-Streaming`	Public Load Balancer	Frontend `STX-PIP-LB`; VMSS
`STX-CM-API-to-Storage`	Connection Monitor	Ativo; intervalo 30s
`STX-RSV-Backup`	Recovery Services Vault	Geo-redundant; backup das VMs; ASR
`STX-BAV-Blobs`	Azure Backup Vault	Para backup de blobs
`STX-BKPOLICY-VMs`	Backup Policy	Daily; Enhanced; 30/12/12 retenção

Testes de integração end-to-end

Teste 1 — Autenticação e acesso RBAC

az login --username pedro.dev@strivex.onmicrosoft.com
# Tentar operação permitida em STX-RG-Apps
az webapp list --resource-group STX-RG-Apps --query "[].name" -o table
# Tentar operação proibida em STX-RG-Core
az storage account create --name teste123 --resource-group STX-RG-Core

Resultado esperado:

Operação em STX-RG-Apps: retorna lista de apps (permitido)
Operação em STX-RG-Core: erro AuthorizationFailed (bloqueado)

Teste 2 — Resolução DNS privada e acesso ao storage via Private Endpoint

Execute em STX-VM-API-01 via Bastion:

nslookup stxstorageprimary.blob.core.windows.net
ping 10.10.3.10
curl https://stxstorageprimary.blob.core.windows.net/thumbnails?restype=container&comp=list -H "x-ms-version: 2020-10-02"

Resultado esperado:

nslookup: IP 10.10.3.10 (Private Endpoint, não IP público)
ping: resposta de 10.10.3.10
curl: 403 ou lista XML (acesso via rede privada confirmado)

Teste 3 — Load Balancer e saúde do backend

# Verificar backend pool do ILB
az network lb show --name STX-ILB-API --resource-group STX-RG-Network --query "backendAddressPools[0].backendIPConfigurations[].id" -o table

# Verificar saúde do PLB (aguardar 2 minutos após health probe correto)
az network lb show --name STX-PLB-Streaming --resource-group STX-RG-Network --query "probes[0].{Port:port, Protocol:protocol}" -o json

Resultado esperado:

ILB: 2 IPs de NICs das VMs API listados
PLB: probe na porta 80, protocolo Http

Teste 4 — Backup e ponto de recuperação

# Listar pontos de recuperação para STX-VM-API-01
az backup recoverypoint list --resource-group STX-RG-Security --vault-name STX-RSV-Backup --container-name $(az backup container list --resource-group STX-RG-Security --vault-name STX-RSV-Backup --backup-management-type AzureIaasVM --query "[?properties.friendlyName=='STX-VM-API-01'].name" -o tsv) --item-name STX-VM-API-01 --workload-type VM --query "[0].{Name:name, Time:properties.recoveryPointTime}" -o json

Resultado esperado: pelo menos um ponto de recuperação listado com timestamp recente.

Teste 5 — Saúde completa do ambiente

# VMs em execução
az vm list --resource-group STX-RG-Apps --show-details --query "[].{Name:name, Power:powerState}" -o table

# VMSS instâncias
az vmss list-instances --name STX-VMSS-Streaming --resource-group STX-RG-Apps --query "[].{ID:instanceId, State:provisioningState}" -o table

# Container App status
az containerapp show --name stx-ca-notifications --resource-group STX-RG-Apps --query "properties.{State:runningStatus, Replicas:template.scale.minReplicas}" -o json

# Replicação ASR
az site-recovery replication-protected-item list --vault-name STX-RSV-Backup --resource-group STX-RG-Security --query "[].{VM:name, Health:properties.replicationHealth}" -o table

Resultado esperado: todas as VMs em VM running, instâncias VMSS Succeeded, Container App Running, ASR Normal.

O que pode dar errado

Etapa	Erro comum	Causa provável
1	Grupo dinâmico não adiciona membros	Pode levar até 24h para processar; verifique a regra de membership em Groups > Dynamic membership rules > Validate rules
1	Convite B2B não chega por e-mail	O domínio `parceiro.edu` pode bloquear e-mails externos; use um e-mail real de teste ou confirme via Portal
2	`AuthorizationFailed` inesperado ao logar com `pedro.dev`	A atribuição de role pode levar até 5 minutos para propagar; aguarde e tente novamente
3	Azure Policy `Deny` bloqueia a própria criação de recursos	Tags obrigatórias bloqueiam recursos sem a tag `Project`; aplique as tags nos RGs antes de ativar a policy em modo Deny
3	Management Group não aceita mover assinatura	Requer permissão `Management Group Contributor` no MG destino; verifique o RBAC
4	Firewall da storage rejeita o Portal Azure	Habilite "Allow Azure services on the trusted services list to access this storage account"
5	Object Replication falha com erro de versioning	Versioning precisa estar habilitado em AMBAS as storage accounts antes de criar a replication policy
5	CMK falha ao ser aplicado	O Key Vault deve ter o Soft Delete e Purge Protection habilitados; o MI da storage account precisa do role `Key Vault Crypto User` no KV
6	Last Access Time Tracking não está disponível	Requer habilitação explícita antes de criar políticas baseadas em acesso; habilite e aguarde 24h para coletar dados
7	Template ARM exportado tem erros de dependência	O export nem sempre captura a ordem correta de recursos; ajuste `dependsOn` manualmente
7	`az bicep decompile` produz avisos	Expressões complexas do ARM podem não converter perfeitamente; corrija os avisos manualmente
8	Encryption at Host falha com erro de feature não registrada	Execute `az feature register --namespace Microsoft.Compute --name EncryptionAtHost` e aguarde o estado `Registered`
8	Mover VM falha por recursos bloqueados	O lock `ReadOnly` em `STX-RG-Core` impedirá a operação; remova temporariamente o lock, mova e recrie
9	`az acr build` falha por falta de Docker	O `az acr build` não precisa do Docker local; usa o serviço de build do ACR. Se falhar, verifique o Dockerfile e as permissões do ACR
10	App Service custom domain falha na verificação	O CNAME `portal → stx-portal-strivex.azurewebsites.net` precisa ser resolvível publicamente; use uma zona DNS real ou o `asuid.portal` TXT record
11	Subnet com delegação não aceita Private Endpoint	A delegação para `Microsoft.Web/serverFarms` deve ser na subnet `STX-SNET-Apps`, não na `STX-SNET-Data` onde os PEs são criados
12	Bastion NSG bloqueado por regras incorretas	As regras obrigatórias do Bastion são muito específicas; qualquer desvio bloqueia o serviço completamente
12	Private Endpoint DNS não resolve na VNet	A zona `privatelink.blob.core.windows.net` precisa estar vinculada à `STX-VNET-EastUS`; verifique o vínculo
13	Health probe falha mesmo com porta correta	Verifique se o NSG `STX-NSG-Core` permite a porta do health probe do Azure Load Balancer (tag `AzureLoadBalancer`)
14	AMA não envia dados para o LAW	O Data Collection Rule precisa ser associado explicitamente à VM; verifique em Monitor > Data Collection Rules > Resources
15	ASR replicação inicial trava	O cache storage precisa ter permissão de escrita; verifique as roles da identidade do ASR na storage account
15	Test Failover VM não inicia	Verifique se a subnet de destino `STX-SNET-DR` tem conectividade e NSGs que permitem o tráfego necessário

Diagrama final do ambiente completo

Microsoft Entra ID: strivex.onmicrosoft.com
  Users: pedro.dev | ana.ops | lucas.instrutor | prof.externo (Guest)
  Groups: STX-GG-Developers | STX-GG-Ops | STX-GG-Instructors | STX-GG-AllBrazilUsers (dynamic)
  SSPR: Habilitado para STX-GG-AllBrazilUsers
  Licenses: Microsoft 365 Business Basic via group-based licensing
       │ RBAC: STX-ROLE-AppDeploy (pedro.dev → STX-RG-Apps)
       │ RBAC: Reader (ana.ops → Subscription)
       │
Management Groups: STX-MG-Root > STX-MG-Production > [Subscription]
Policy Initiative: STX-INITIATIVE-Compliance (AllowedLocations + RequireTag + AuditVMSize)
Resource Locks: STX-RG-Network (CanNotDelete) | STX-RG-Core (ReadOnly)
Budget: STX-BUDGET-Monthly USD 200
       │
Azure Subscription (East US)
       │
┌──────┴──────────────────────────────────────────────────────────────────────────┐
│  STX-VNET-EastUS (10.10.0.0/16)                                                 │
│                                                                                  │
│  STX-SNET-Core (10.10.1.0/24) — NSG-Core                                        │
│  ├── STX-VM-API-01 (WS2022, Encryption@Host, discos de dados)                   │
│  ├── STX-VM-API-02 (WS2022, Encryption@Host, discos de dados)                   │
│  └── STX-ILB-API → Frontend 10.10.1.100 → [VM-API-01, VM-API-02]               │
│                                                                                  │
│  STX-SNET-Apps (10.10.2.0/24) — Delegação Web/serverFarms — Service Endpoints  │
│  ├── stx-portal-strivex (App Service, Node 20, TLS, slots, backup)              │
│  ├── stx-ca-notifications (Container Apps, 1-5 réplicas)                        │
│  ├── STX-ACI-ReportJob (Container Instance)                                     │
│  └── STX-VMSS-Streaming → STX-PLB-Streaming → STX-PIP-LB                       │
│                                                                                  │
│  STX-SNET-Data (10.10.3.0/24) — NSG-Data — PE Network Policies Disabled        │
│  ├── STX-PE-Storage-Blob (10.10.3.10) → stxstorageprimary.blob                 │
│  └── STX-PE-Storage-File (10.10.3.11) → stxstorageprimary.file                 │
│                                                                                  │
│  AzureBastionSubnet (10.10.0.32/27)                                              │
│  └── STX-BASTION (Standard SKU) → acesso admin sem IP público                  │
└──────────────────────────────────────────────────────────────────────────────────┘
         │ VNet Peering ↔ VNet Peering
┌────────┴──────────────────────────────────────────────────────────────────────┐
│  STX-VNET-BrazilSouth (10.20.0.0/16) — STX-RG-DR                             │
│  ├── STX-SNET-DR (10.20.1.0/24) → STX-VM-API-01-replica (ASR failover)       │
│  └── STX-SNET-Data-DR (10.20.2.0/24)                                         │
└───────────────────────────────────────────────────────────────────────────────┘

Storage
  stxstorageprimary (GZRS, CMK, Versioning, Soft Delete, Object Replication)
    ├── Container: videos (Lifecycle: Cool→Archive, Private Endpoints)
    ├── Container: thumbnails (AzCopy migrated)
    ├── Container: backups (App Service backup)
    ├── Container: diagnostics (Network Watcher captures)
    └── File Share: stx-share-instructors (Entra Kerberos, Backup, Snapshots)
  stxstoragedr (LRS, Brazil South) ← Object Replication from stxstorageprimary/videos
  stxstoragedev / stxstoragedev2 (LRS) ← ARM Template deployments

ACR: stxacr → Image: notifications:1.0
Key Vault: stx-kv-storage → Key: stx-storage-key (RSA 4096, CMK for storage)

DNS
  Public Zone: strivex.com.br (A: api, CNAME: www, TXT: SPF)
  Private Zone: strivex.internal (A: api→10.10.1.100, A: storage→10.10.3.10)
  Private Link Zones: privatelink.blob / privatelink.file → 10.10.3.10 / .11

Monitoring (STX-LAW-Core)
  ├── VMs (AMA + DCR: Perf + Events)
  ├── App Service (HTTP + Console logs)
  ├── Load Balancers (Metrics)
  ├── Storage (Read/Write/Delete logs)
  └── Backup Reports

Backup (STX-RSV-Backup, Geo-redundant)
  ├── STX-VM-API-01 (daily policy, 30/12/12)
  ├── STX-VM-API-02 (daily policy, 30/12/12)
  ├── ASR: STX-VM-API-01 → Brazil South (Health: Normal)
  └── STX-RSV-FileShare → stx-share-instructors (daily/weekly/monthly)

Ambiente Cumulativo de Implantação Real​

Narrativa Central​

A Empresa: Strivex Educação Digital Ltda.​

Ambiente Inicial​

Recursos necessários antes do início do laboratório​

Credenciais fictícias do laboratório​

Ferramentas necessárias​

Diagrama de topologia inicial​

Etapa 1 — Gerenciar Usuários e Grupos do Microsoft Entra ID​

Contexto da etapa​

Ambiente de execução​

Tarefas​

Valor capturado​

Critérios de validação​

Etapa 2 — Gerenciar Acesso a Recursos Azure​

Contexto da etapa​

Ambiente de execução​

Tarefas​

Valor capturado​

Critérios de validação​

Etapa 3 — Gerenciar Assinaturas e Governança​

Contexto da etapa​

Ambiente de execução​

Tarefas​

Valor capturado​

Critérios de validação​

Etapa 4 — Configurar Acesso ao Storage​

Contexto da etapa​

Ambiente de execução​

Tarefas​

Valor capturado​

Critérios de validação​

Etapa 5 — Configurar e Gerenciar Storage Accounts​

Contexto da etapa​

Ambiente de execução​

Tarefas​

Valor capturado​

Critérios de validação​

Etapa 6 — Configurar Azure Files e Azure Blob Storage​

Contexto da etapa​

Ambiente de execução​

Tarefas​

Valor capturado​

Critérios de validação​

Etapa 7 — Automatizar Implantação com ARM Templates​

Contexto da etapa​

Ambiente de execução​

Tarefas​

Valor capturado​

Critérios de validação​

Etapa 8 — Criar e Configurar Máquinas Virtuais​

Contexto da etapa​

Diagrama da etapa​

Ambiente de execução​

Tarefas​

Valor capturado​

Critérios de validação​

Etapa 9 — Provisionar e Gerenciar Contêineres​

Contexto da etapa​

Ambiente de execução​

Tarefas​

Valor capturado​

Critérios de validação​

Etapa 10 — Criar e Configurar Azure App Service​

Contexto da etapa​

Ambiente de execução​

Tarefas​

Valor capturado​

Critérios de validação​

Etapa 11 — Configurar e Gerenciar Redes Virtuais no Azure​

Contexto da etapa​

Diagrama da etapa​

Ambiente de execução​

Tarefas​

Valor capturado​

Critérios de validação​

Etapa 12 — Configurar Acesso Seguro a Redes Virtuais​

Contexto da etapa​

Ambiente de execução​

Tarefas​

Ambiente Cumulativo de Implantação Real

Narrativa Central

A Empresa: Strivex Educação Digital Ltda.

Ambiente Inicial

Recursos necessários antes do início do laboratório

Credenciais fictícias do laboratório

Ferramentas necessárias

Diagrama de topologia inicial

Etapa 1 — Gerenciar Usuários e Grupos do Microsoft Entra ID

Contexto da etapa

Ambiente de execução

Tarefas

Valor capturado

Critérios de validação

Etapa 2 — Gerenciar Acesso a Recursos Azure

Contexto da etapa

Ambiente de execução

Tarefas

Valor capturado

Critérios de validação

Etapa 3 — Gerenciar Assinaturas e Governança

Contexto da etapa

Ambiente de execução

Tarefas

Valor capturado

Critérios de validação

Etapa 4 — Configurar Acesso ao Storage

Contexto da etapa

Ambiente de execução

Tarefas

Valor capturado

Critérios de validação

Etapa 5 — Configurar e Gerenciar Storage Accounts

Contexto da etapa

Ambiente de execução

Tarefas

Valor capturado

Critérios de validação

Etapa 6 — Configurar Azure Files e Azure Blob Storage

Contexto da etapa

Ambiente de execução

Tarefas

Valor capturado

Critérios de validação

Etapa 7 — Automatizar Implantação com ARM Templates

Contexto da etapa

Ambiente de execução

Tarefas

Valor capturado

Critérios de validação

Etapa 8 — Criar e Configurar Máquinas Virtuais

Contexto da etapa

Diagrama da etapa

Ambiente de execução

Tarefas

Valor capturado

Critérios de validação

Etapa 9 — Provisionar e Gerenciar Contêineres

Contexto da etapa

Ambiente de execução

Tarefas

Valor capturado

Critérios de validação

Etapa 10 — Criar e Configurar Azure App Service

Contexto da etapa

Ambiente de execução

Tarefas

Valor capturado

Critérios de validação

Etapa 11 — Configurar e Gerenciar Redes Virtuais no Azure

Contexto da etapa

Diagrama da etapa

Ambiente de execução

Tarefas

Valor capturado

Critérios de validação

Etapa 12 — Configurar Acesso Seguro a Redes Virtuais

Contexto da etapa

Ambiente de execução

Tarefas