[AZ-104] Grand Labs - OriginPay Soluções Financeiras

Ambiente Cumulativo de Implantação Real

Narrativa Central

OriginPay Soluções Financeiras é uma empresa brasileira de meios de pagamento que processa transferências PIX e boletos para pequenas e médias empresas. Com a aprovação de um aporte de capital, a diretoria de TI recebeu mandato para migrar toda a infraestrutura para o Azure, implementar governança, segurança de identidade e resiliência multi-região.

O projeto — chamado internamente de "Projeto Origem" — será executado em fases contínuas. Você é o Azure Administrator responsável pela implantação técnica completa. Todos os recursos seguem o prefixo opay e são distribuídos entre as regiões East US (produção) e Brazil South (DR e conformidade de dados).

Prefixo de recursos: opay

Tenant Microsoft Entra ID: originpay.onmicrosoft.com

Ambiente Inicial

Provisione ou confirme os itens abaixo antes de iniciar a Etapa 1.

Recursos Necessários

Nome	Tipo	Especificação Mínima	Como Provisionar/Simular
Subscription Azure	Assinatura Azure	Pay-As-You-Go ou Azure Free Trial / Visual Studio	Conta pessoal ou corporativa com permissão de Owner
Tenant Microsoft Entra ID	Tenant existente	Licença P1 ou P2 para SSPR e licenciamento	Criado automaticamente com a subscription
`opay-rg-identity`	Resource Group	East US	Criar manualmente antes da Etapa 1
`opay-rg-prod`	Resource Group	East US	Criar manualmente antes da Etapa 1
`opay-rg-dr`	Resource Group	Brazil South	Criar manualmente antes da Etapa 1
Azure Cloud Shell	Shell integrado	Bash ou PowerShell	Habilitar no Portal Azure
Azure CLI	CLI local (opcional)	2.50+	`az --version` para verificar
PowerShell Az module	Módulo PowerShell	Az 10.0+	`Get-Module Az -ListAvailable`

Credenciais de Simulação

Conta	Tipo	UPN / Senha	Observação
Conta de proprietário	Owner da subscription	Sua conta real	Necessária para operações de RBAC e Policy
`ana.souza@originpay.onmicrosoft.com`	Usuário Entra ID	`OriginP@y2024!`	Gerente de TI — criada na Etapa 1
`carlos.lima@originpay.onmicrosoft.com`	Usuário Entra ID	`OriginP@y2024!`	Desenvolvedor — criado na Etapa 1
`svc-devops@originpay.onmicrosoft.com`	Service Account	`Svc@DevOps2024!`	Conta de serviço — criada na Etapa 1
`guest-parceiro@contoso.com`	Usuário convidado (B2B)	N/A (convite)	Parceiro externo — convidado na Etapa 1
`opay-vm-admin`	Admin local das VMs	`VMAdm1n@Pay!`	Usado em todas as VMs do laboratório

Ferramentas de Cliente

Ferramenta	Versão Mínima	Observação
Azure Portal	Navegador moderno	`portal.azure.com`
Azure CLI	2.50+	`az login` antes de iniciar
PowerShell Az	10.0+	`Connect-AzAccount` antes de iniciar
Azure Storage Explorer	1.33+	Para tarefas de armazenamento (Etapa 5)
AzCopy	v10	Para transferência de blobs (Etapa 5)

Diagrama de Topologia Inicial

Azure Subscription: OriginPay
├── Microsoft Entra ID Tenant: originpay.onmicrosoft.com
│       └── (vazio — usuários e grupos serão criados)
│
├── opay-rg-identity (East US)   [pré-criado]
├── opay-rg-prod     (East US)   [pré-criado]
└── opay-rg-dr       (Brazil South) [pré-criado]

Regiões alvo:
  East US      → Produção, identidade, VMs, storage, App Service
  Brazil South → DR, replicação, Site Recovery

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

Contexto da Etapa

O primeiro passo do Projeto Origem é estruturar as identidades digitais da OriginPay no Microsoft Entra ID (anteriormente Azure Active Directory). Sem usuários e grupos organizados, nenhuma atribuição de acesso aos recursos Azure será possível nas etapas seguintes. Nesta etapa, serão criados os usuários internos, grupos de segurança, um usuário convidado externo e configurada a licença P1 para habilitar recursos avançados.

Ambiente de Execução

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

Tarefas

Tarefa 1.1 — [Portal / PowerShell] No Microsoft Entra ID > Users > New user, crie os seguintes usuários membros:

UPN	Display Name	Job Title	Department
`ana.souza@originpay.onmicrosoft.com`	Ana Souza	IT Manager	IT
`carlos.lima@originpay.onmicrosoft.com`	Carlos Lima	Developer	Engineering
`svc-devops@originpay.onmicrosoft.com`	SVC DevOps	Service Account	IT

Configure Usage location como Brazil em todos os usuários.

Tarefa 1.2 — [Portal / CLI] Crie dois grupos de segurança no Microsoft Entra ID > Groups > New group: opay-grp-admins (Membership type: Assigned) e opay-grp-devs (Membership type: Assigned). Adicione ana.souza ao opay-grp-admins e carlos.lima ao opay-grp-devs.

Tarefa 1.3 — [Portal] Convide o usuário externo guest-parceiro@contoso.com via Microsoft Entra ID > External Identities > All users > Invite external user. Configure a mensagem de convite informando acesso ao ambiente de homologação da OriginPay. Após o convite, adicione o guest ao grupo opay-grp-devs.

Tarefa 1.4 — [Portal] Atribua a licença Microsoft Entra ID P1 ao usuário ana.souza via Microsoft Entra ID > Users > ana.souza > Licenses > Assignments. Verifique que o plano Microsoft Entra ID P1 está habilitado.

Tarefa 1.5 — [Portal / PowerShell] Configure o Self-Service Password Reset (SSPR) para o grupo opay-grp-admins. Em Microsoft Entra ID > Password reset, habilite o SSPR apenas para o grupo opay-grp-admins. Configure os métodos de autenticação como Mobile app notification e Email. Defina o número de métodos necessários para reset como 1.

Valor Capturado

Valor	Onde encontrar	Usado na etapa
Object ID de `opay-grp-admins`	Entra ID > Groups > opay-grp-admins > Overview	Etapas 2, 3
Object ID de `opay-grp-devs`	Entra ID > Groups > opay-grp-devs > Overview	Etapas 2, 3
Object ID de `ana.souza`	Entra ID > Users > ana.souza > Overview	Etapa 2
Tenant ID	Entra ID > Overview	Etapas 6, 9, 14

Critérios de Validação

az ad user list --filter "startswith(userPrincipalName,'ana')" deve retornar o objeto de ana.souza com accountEnabled: true e usageLocation: BR.
az ad group member list --group opay-grp-admins deve listar ana.souza como membro.
O convite ao guest-parceiro@contoso.com deve aparecer em Microsoft Entra ID > Users com userType: Guest e status PendingAcceptance.
Em Microsoft Entra ID > Password reset > Properties, o escopo deve mostrar Selected group: opay-grp-admins.

Etapa 2 — Gerenciar Acesso a Recursos Azure (RBAC)

Contexto da Etapa

Com as identidades criadas na Etapa 1, o time de governança da OriginPay precisa aplicar o princípio de menor privilégio. ana.souza precisa gerenciar toda a assinatura, carlos.lima precisa apenas ler recursos em produção, e o grupo opay-grp-devs precisa permissão de Contributor no resource group de desenvolvimento. Esta etapa configura o RBAC usando roles built-in e avalia as atribuições efetivas.

Diagrama da Etapa

Subscription: OriginPay
├── ana.souza → Role: Contributor (escopo: subscription)
├── opay-grp-admins → Role: User Access Administrator (escopo: subscription)
│
├── opay-rg-prod (East US)
│       └── carlos.lima → Role: Reader
│
└── opay-rg-dr (Brazil South)
        └── opay-grp-devs → Role: Contributor

Ambiente de Execução

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

Tarefas

Tarefa 2.1 — [Portal / CLI] Atribua a role Contributor à usuária ana.souza no escopo da subscription. Navegue em Subscription > Access control (IAM) > Add role assignment. Selecione a role Contributor, atribua ao usuário ana.souza.

Tarefa 2.2 — [Portal / CLI] Atribua a role User Access Administrator ao grupo opay-grp-admins no escopo da subscription. Use o mesmo menu IAM > Add role assignment da subscription.

Tarefa 2.3 — [Portal / PowerShell] Atribua a role Reader ao usuário carlos.lima no escopo do resource group opay-rg-prod. Navegue em opay-rg-prod > Access control (IAM) > Add role assignment.

Tarefa 2.4 — [Portal / CLI] Atribua a role Contributor ao grupo opay-grp-devs no escopo do resource group opay-rg-dr.

Tarefa 2.5 — [Portal / PowerShell] Interprete as atribuições efetivas de carlos.lima. No menu opay-rg-prod > Access control (IAM) > Check access, pesquise por carlos.lima e verifique quais ações estão permitidas e negadas. Em seguida, verifique também o acesso efetivo de carlos.lima em opay-rg-dr e confirme que não há permissão de escrita.

Valor Capturado

Valor	Onde encontrar	Usado na etapa
Role Assignment ID de ana.souza (Contributor)	`az role assignment list --assignee ana.souza@...`	Etapa 3
Subscription ID	Portal > Subscriptions > Overview	Etapas 3, 6, 9, 14

Critérios de Validação

az role assignment list --assignee ana.souza@originpay.onmicrosoft.com --scope /subscriptions/<sub-id> deve retornar uma entrada com roleDefinitionName: Contributor.
az role assignment list --assignee carlos.lima@originpay.onmicrosoft.com --resource-group opay-rg-prod deve retornar roleDefinitionName: Reader.
Em opay-rg-dr > IAM > Check access > carlos.lima, o resultado deve mostrar No access para ações de escrita (ex: Microsoft.Compute/virtualMachines/write).

Etapa 3 — Governança: Policy, Locks, Tags e Management Groups

Contexto da Etapa

A OriginPay precisa garantir que todos os recursos criados na assinatura sejam rastreáveis por centro de custo, estejam na região correta e não possam ser excluídos acidentalmente. Esta etapa implementa Azure Policy, resource locks, tags e organiza a assinatura em management groups para suportar o crescimento futuro.

Diagrama da Etapa

Management Group: opay-mg-root
└── Management Group: opay-mg-prod
        └── Subscription: OriginPay
                ├── Policy: Allowed Locations (East US, Brazil South)
                ├── Policy: Require Tag "CostCenter"
                ├── opay-rg-prod → Lock: Delete (CanNotDelete)
                └── Todos os recursos → Tag: CostCenter=payments | Env=prod

Ambiente de Execução

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

Tarefas

Tarefa 3.1 — [Portal] Em Microsoft Entra ID > Management groups, crie a hierarquia de management groups: opay-mg-root como grupo raiz e opay-mg-prod como filho de opay-mg-root. Mova a subscription OriginPay para dentro de opay-mg-prod.

Tarefa 3.2 — [Portal / CLI] Em Policy > Assignments > Assign policy, atribua a policy built-in Allowed locations ao escopo da subscription com os valores ["eastus", "brazilsouth"]. Nomeie a atribuição opay-policy-allowed-locations. Em seguida, atribua a policy built-in Require a tag and its value on resources com tagName = CostCenter ao escopo da subscription, nomeando opay-policy-require-costcenter.

Tarefa 3.3 — [Portal / PowerShell] Teste as políticas: tente criar um resource group em West Europe diretamente pelo portal e confirme que a criação é bloqueada pela policy. Crie um recurso em East US sem a tag CostCenter e confirme o bloqueio (ou auditoria, dependendo do effect configurado).

Tarefa 3.4 — [Portal / CLI] Aplique as tags CostCenter=payments e Env=prod ao resource group opay-rg-prod e ao resource group opay-rg-dr (com Env=dr). Verifique a propagação usando Azure Resource Graph: az graph query -q "Resources | where resourceGroup == 'opay-rg-prod' | project name, tags".

Tarefa 3.5 — [Portal / PowerShell] Aplique um Resource Lock do tipo CanNotDelete ao resource group opay-rg-prod. Tente excluir o resource group e confirme que a operação falha. Em seguida, configure um segundo lock de ReadOnly no resource group opay-rg-dr.

Valor Capturado

Valor	Onde encontrar	Usado na etapa
ID da policy assignment (allowed-locations)	Portal > Policy > Assignments	Etapa 3 (validação)
ID do management group opay-mg-prod	Portal > Management Groups	Etapa 14

Critérios de Validação

az policy assignment list --scope /subscriptions/<sub-id> deve listar opay-policy-allowed-locations e opay-policy-require-costcenter.
Tentativa de criar um resource group em westeurope via portal deve ser bloqueada com mensagem referenciando a policy opay-policy-allowed-locations.
az lock list --resource-group opay-rg-prod deve retornar um lock com level: CanNotDelete.
az group show --name opay-rg-prod --query tags deve retornar um objeto JSON com as chaves CostCenter (valor payments) e Env (valor prod).

Etapa 4 — Gerenciar Subscriptions e Custos

Contexto da Etapa

A diretoria financeira da OriginPay exige visibilidade de custos e alertas automáticos antes que o budget mensal seja ultrapassado. O Azure Advisor também será consultado para identificar oportunidades de otimização nos recursos já criados. Esta etapa configura orçamentos, alertas de custo e valida as recomendações de governança.

Ambiente de Execução

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

Tarefas

Tarefa 4.1 — [Portal] Em Cost Management > Budgets, crie um budget chamado opay-budget-monthly com os seguintes parâmetros: escopo da subscription, período Monthly, data de reset Monthly, valor USD 500, período de análise de 12 meses. Configure dois alertas: um a 80% do budget (USD 400) e outro a 100% (USD 500), com notificação para ana.souza@originpay.onmicrosoft.com.

Tarefa 4.2 — [Portal] Em Cost Management > Cost alerts, configure um Credit alert (se a subscription for do tipo EA ou PAYG com créditos) ou um Department spending alert com threshold de USD 450. Se não disponível para o tipo de subscription, documente o tipo de alerta disponível e configure o existente.

Tarefa 4.3 — [Portal] Em Azure Advisor > Cost, revise as recomendações de custo disponíveis para a subscription. Identifique ao menos uma recomendação (ex: VMs undersized, recursos não utilizados) e registre a ação sugerida em C:\opay-docs\advisor-recommendations.txt (ou equivalente local). Marque a recomendação como Postponed com justificativa "Aguardando aprovação de arquitetura".

Tarefa 4.4 — [Portal] Em Subscriptions > opay-subscription > Resource providers, verifique que os seguintes providers estão registrados: Microsoft.Compute, Microsoft.Network, Microsoft.Storage, Microsoft.ContainerRegistry, Microsoft.Web, Microsoft.RecoveryServices. Registre qualquer provider não registrado usando o botão Register.

Valor Capturado

Valor	Onde encontrar	Usado na etapa
Nome do budget criado	Cost Management > Budgets	Etapa 19 (validação global)
Threshold de alerta (%)	Cost Management > Budgets > opay-budget-monthly	Etapa 19

Critérios de Validação

Em Cost Management > Budgets, o budget opay-budget-monthly deve aparecer com status Active e os dois alertas configurados (80% e 100%).
az consumption budget list --subscription <sub-id> deve retornar o budget opay-budget-monthly com amount: 500 e timeGrain: Monthly.
O provider Microsoft.RecoveryServices deve aparecer como Registered em Subscriptions > Resource providers.

Etapa 5 — Configurar Acesso ao Storage

Contexto da Etapa

O Projeto Origem exige uma camada de armazenamento segura para documentos financeiros e logs de transações PIX. Esta etapa configura um storage account com firewall de rede, SAS tokens com validade limitada, stored access policies e acesso baseado em identidade para Azure Files. Os recursos criados aqui serão usados pelas VMs e pelo App Service nas etapas seguintes.

Diagrama da Etapa

opay-rg-prod (East US)
└── opay-sa-prod (Storage Account)
        ├── Firewall: permitir apenas VNet opay-vnet-prod (criada na Etapa 9)
        ├── SAS Token: leitura em blobs de documentos (validade 24h)
        ├── Stored Access Policy: opay-sap-readonly (sem expiração fixa)
        └── Azure Files: opay-fileshare (autenticação via Entra ID)

Ambiente de Execução

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

Tarefas

Tarefa 5.1 — [Portal / CLI] No resource group opay-rg-prod, crie um storage account chamado opayprodSUFIXO (sufixo de 4 dígitos numéricos para garantir unicidade global, ex: opayprod1847) na região East US, SKU Standard_GRS, access tier Hot. Habilite Hierarchical Namespace (Azure Data Lake Storage Gen2) e configure Minimum TLS version: TLS 1.2. Desabilite Allow Blob public access.

Tarefa 5.2 — [Portal / PowerShell] No storage account criado, configure o Firewall e Virtual Networks: em Networking, mude o acesso de Enabled from all networks para Enabled from selected virtual networks and IP addresses. Adicione o IP público da sua máquina de gerenciamento para acesso temporário. Anote que a VNet opay-vnet-prod será adicionada na Etapa 9 após sua criação.

Tarefa 5.3 — [Portal / CLI] Crie um container de blobs chamado opay-docs com access level Private. Faça upload de um arquivo de teste transacao-teste.pdf para o container. Gere um SAS token com as permissões: Read, validade de 24 horas a partir de agora, protocolo HTTPS only, e serviço Blob. Copie a SAS URL completa e teste o acesso com curl ou browser.

Tarefa 5.4 — [Portal / CLI] Crie uma Stored Access Policy chamada opay-sap-readonly no container opay-docs com permissão de Read e sem data de expiração fixa. Gere um segundo SAS token vinculado a esta stored access policy.

Tarefa 5.5 — [Portal / PowerShell] No storage account, crie um Azure Files share chamado opay-fileshare com quota de 100 GiB e tier Transaction optimized. Configure o acesso baseado em identidade via Microsoft Entra Kerberos em File share > Settings > Identity-based access. Atribua a role Storage File Data SMB Share Contributor ao grupo opay-grp-admins no escopo do file share.

Valor Capturado

Valor	Onde encontrar	Usado na etapa
Nome exato do storage account	Portal > opay-rg-prod > Resources	Etapas 6, 9, 14
SAS URL do container opay-docs	Gerada no passo 5.3	Etapa 5 (validação)
Key1 do storage account	Storage account > Access keys	Etapas 5, 14
Connection string do storage	Storage account > Access keys	Etapa 14

Critérios de Validação

az storage account show --name opayprodSUFIXO --resource-group opay-rg-prod --query "minimumTlsVersion" deve retornar "TLS1_2".
A SAS URL gerada na Tarefa 5.3, testada com curl -I "<SAS_URL>", deve retornar HTTP 200 OK com o header Content-Type: application/octet-stream.
az storage share show --name opay-fileshare --account-name opayprodSUFIXO deve retornar o share com quota: 100.
az role assignment list --scope /subscriptions/<sub-id>/resourceGroups/opay-rg-prod/providers/Microsoft.Storage/storageAccounts/opayprodSUFIXO/fileServices/default/fileshares/opay-fileshare deve listar a role Storage File Data SMB Share Contributor para opay-grp-admins.

Etapa 6 — Configurar e Gerenciar Storage Accounts

Contexto da Etapa

Com o storage account de produção operacional (Etapa 5), a OriginPay precisa garantir resiliência dos dados, replicação entre regiões, criptografia gerenciada por chave própria e um storage secundário em Brazil South para conformidade regulatória de dados de residência no Brasil. O Azure Storage Explorer e o AzCopy serão usados para operações de gerenciamento de dados.

Ambiente de Execução

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

Tarefas

Tarefa 6.1 — [Portal / CLI] Crie um segundo storage account chamado opaydrSUFIXO no resource group opay-rg-dr, região Brazil South, SKU Standard_LRS. Este storage será o destino de replicação de objetos. Após criar, configure o Object Replication do storage opayprodSUFIXO (source) para opaydrSUFIXO (destination): em opay-rg-prod > opayprodSUFIXO > Object replication > Create replication rules, selecione o container opay-docs como source e crie um container opay-docs-replica no storage opaydrSUFIXO como destination.

Tarefa 6.2 — [Portal] Altere a redundância do storage account opayprodSUFIXO de GRS para RA-GRS (Read-access geo-redundant storage) em Storage account > Configuration > Replication. Verifique o secondary endpoint gerado em Properties e registre a URL de leitura secundária.

Tarefa 6.3 — [Portal] Configure a criptografia do storage opayprodSUFIXO usando Customer-managed keys (CMK). Para isso, é necessário criar primeiro um Azure Key Vault chamado opay-kv-prod no resource group opay-rg-prod com Soft delete e Purge protection habilitados. Dentro do Key Vault, gere uma chave RSA 2048 chamada opay-storage-key. Volte ao storage account em Encryption e configure CMK apontando para a chave recém-criada. Habilite a identidade gerenciada do storage account para o Key Vault.

Tarefa 6.4 — [Azure Storage Explorer / AzCopy] Conecte o Azure Storage Explorer ao storage account opayprodSUFIXO usando a connection string obtida na Etapa 5. Faça upload de 5 arquivos de teste com extensão .log para o container opay-docs. Em seguida, use o AzCopy com o comando base azcopy copy e o parâmetro SAS para copiar todos os arquivos .log do container opay-docs para um diretório local de destino.

Tarefa 6.5 — [Portal] Configure o Encryption scope no storage account opayprodSUFIXO: crie um scope chamado opay-scope-financeiro usando a chave do Key Vault opay-kv-prod. Associe este scope ao container opay-docs como scope padrão.

Valor Capturado

Valor	Onde encontrar	Usado na etapa
Nome do Key Vault	`opay-kv-prod`	Etapas 14, 19
Nome da chave CMK	`opay-storage-key`	Etapa 19
Secondary endpoint (RA-GRS)	Storage account > Properties	Etapa 19
Nome do storage DR	`opaydrSUFIXO`	Etapas 14, 19

Critérios de Validação

az storage account show --name opayprodSUFIXO --query "encryption.keySource" deve retornar "Microsoft.Keyvault".
Em opayprodSUFIXO > Object replication, deve existir uma regra de replicação listando opay-docs como source container e opay-docs-replica como destination container.
Os 5 arquivos .log devem aparecer localmente no diretório de destino após o comando AzCopy, e o exit code do AzCopy deve ser 0.

Etapa 7 — Configurar Azure Files e Azure Blob Storage

Contexto da Etapa

O time de engenharia da OriginPay precisa de políticas de ciclo de vida para blobs (mover logs antigos para tier frio) e proteção contra exclusão acidental dos arquivos financeiros. Esta etapa configura tiers, soft delete, snapshots, versionamento e lifecycle management no storage opayprodSUFIXO criado na Etapa 5.

Ambiente de Execução

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

Tarefas

Tarefa 7.1 — [Portal / CLI] Configure o Blob versioning no storage account opayprodSUFIXO: em Data protection > Versioning, habilite o versionamento. Faça upload de uma nova versão do arquivo transacao-teste.pdf (modifique o conteúdo) e confirme que ambas as versões são listadas em opay-docs > transacao-teste.pdf > Versions.

Tarefa 7.2 — [Portal] Configure o Soft delete para blobs e containers: em Data protection, habilite Soft delete for blobs com retenção de 14 dias e Soft delete for containers com retenção de 14 dias. Exclua o arquivo transacao-teste.pdf e verifique que ele ainda aparece na lista com o filtro Show deleted blobs.

Tarefa 7.3 — [Portal / PowerShell] No file share opay-fileshare, crie um snapshot manual: em opay-fileshare > Operations > Snapshots > Add snapshot. Adicione uma descrição before-update-2024. Em seguida, configure o Soft delete para Azure Files com retenção de 7 dias em Data protection > Soft delete for file shares.

Tarefa 7.4 — [Portal / CLI] Configure a Lifecycle management policy no storage opayprodSUFIXO: em Lifecycle management > Add a rule, crie uma regra chamada opay-lifecycle-logs. Configure as ações: mover blobs com prefixo logs/ para Cool tier após 30 dias sem modificação, mover para Archive tier após 90 dias, e excluir após 365 dias. Configure também a ação de expiração de versões antigas após 60 dias.

Tarefa 7.5 — [Portal] Configure os storage tiers do container opay-docs: mude o tier de acesso padrão do storage account de Hot para Cool em Storage account > Configuration > Access tier. Confirme o impacto nos blobs existentes (blobs que eram Hot passam a inferir o tier do account como Cool, mas o tier individual pode ser diferente).

Valor Capturado

Valor	Onde encontrar	Usado na etapa
Nome da lifecycle rule	`opay-lifecycle-logs`	Etapa 19
Data do snapshot do file share	File share > Snapshots	Etapa 19

Critérios de Validação

az storage blob list --container-name opay-docs --account-name opayprodSUFIXO --include v deve listar múltiplas versões do blob transacao-teste.pdf.
Após exclusão e com filtro de deleted blobs ativo, az storage blob list --container-name opay-docs --include d --account-name opayprodSUFIXO deve retornar o blob transacao-teste.pdf com deleted: true.
az storage account management-policy show --account-name opayprodSUFIXO --resource-group opay-rg-prod deve retornar a policy com a regra opay-lifecycle-logs.

Etapa 8 — Deploy de Recursos com ARM Templates e Bicep

Contexto da Etapa

A OriginPay quer padronizar o provisionamento de infraestrutura como código para garantir repeatability. Esta etapa usa ARM templates e Bicep para interpretar, modificar e implantar recursos de rede e compute que serão usados nas etapas de VMs (Etapa 9) e App Service (Etapa 13). O template de uma VM existente será exportado e modificado.

Ambiente de Execução

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

Tarefas

Tarefa 8.1 — [Portal] Exporte o ARM template do resource group opay-rg-prod navegando em opay-rg-prod > Export template. Baixe o arquivo template.json gerado. Abra o arquivo e identifique: o tipo de resource Microsoft.Storage/storageAccounts, os parâmetros exportados e os dependsOn existentes.

Tarefa 8.2 — [Portal / CLI] Modifique o ARM template exportado para adicionar um segundo container de blob chamado opay-logs ao storage account opayprodSUFIXO. Adicione o resource Microsoft.Storage/storageAccounts/blobServices/containers com o nome opay-logs e a dependência (dependsOn) no storage account. Faça o deploy do template modificado usando az deployment group create com o parâmetro --template-file.

Tarefa 8.3 — [CLI] Converta o ARM template do storage account para Bicep usando az bicep decompile --file template.json. Abra o arquivo .bicep gerado e modifique o valor do parâmetro sku.name para aceitar um parâmetro storageSkuName com valor padrão Standard_GRS. Valide o arquivo Bicep com az bicep build.

Tarefa 8.4 — [Portal / CLI] Faça deploy do arquivo Bicep modificado criando um novo storage account chamado opaystagingSUFIXO no resource group opay-rg-prod passando o parâmetro storageSkuName=Standard_LRS. Use az deployment group create com --template-file apontando para o arquivo .bicep.

Tarefa 8.5 — [Portal] Valide o deploy em opay-rg-prod > Deployments. Inspecione o deployment bem-sucedido e veja o Deployment template completo renderizado. Verifique que o container opay-logs existe no storage opayprodSUFIXO e que o storage opaystagingSUFIXO foi criado com o SKU Standard_LRS.

Valor Capturado

Valor	Onde encontrar	Usado na etapa
Nome do storage staging	`opaystagingSUFIXO`	Etapa 19
Arquivo Bicep gerado	Local ou Cloud Shell	Etapa 19

Critérios de Validação

az storage container list --account-name opayprodSUFIXO deve listar os containers opay-docs, opay-docs-replica e opay-logs.
az storage account show --name opaystagingSUFIXO --query sku.name deve retornar "Standard_LRS".
Em opay-rg-prod > Deployments, deve existir um deployment com status Succeeded contendo o template Bicep implantado.

Etapa 9 — Criar e Configurar Máquinas Virtuais

Contexto da Etapa

Com a infraestrutura de identidade, storage e templates prontos, o Projeto Origem inicia o deploy das VMs de processamento de pagamentos. Serão criadas duas VMs: uma Linux (Ubuntu) para o backend de processamento e uma Windows Server para o portal administrativo. Esta etapa também configura discos gerenciados, availability zones e encryption at host.

Diagrama da Etapa

opay-rg-prod (East US)
├── opay-vnet-prod (10.10.0.0/16)
│       ├── opay-subnet-app (10.10.1.0/24)
│       └── opay-subnet-mgmt (10.10.2.0/24)
│
├── opay-vm-linux01 (Ubuntu 22.04 LTS)
│       ├── Zone: 1
│       ├── Size: Standard_D2s_v3
│       ├── Disk OS: Premium SSD (encryption at host)
│       └── NIC: opay-subnet-app
│
└── opay-vm-win01 (Windows Server 2022)
        ├── Zone: 2
        ├── Size: Standard_D2s_v3
        ├── Disk OS: Premium SSD (encryption at host)
        └── NIC: opay-subnet-mgmt

Ambiente de Execução

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

Tarefas

Tarefa 9.1 — [Portal / CLI] No resource group opay-rg-prod, crie a VNet opay-vnet-prod com address space 10.10.0.0/16. Crie as subnets opay-subnet-app (10.10.1.0/24) e opay-subnet-mgmt (10.10.2.0/24). Após criar a VNet, adicione a sub-rede opay-subnet-app como Service Endpoint para o storage account opayprodSUFIXO (navegue ao storage > Networking > Virtual networks > Add existing virtual network).

Tarefa 9.2 — [Portal / CLI] Crie a VM opay-vm-linux01 no resource group opay-rg-prod, região East US, Availability Zone 1, imagem Ubuntu Server 22.04 LTS, tamanho Standard_D2s_v3, autenticação por SSH public key (gere um par de chaves opay-linux-key). Configure a NIC na subnet opay-subnet-app. Habilite Encryption at host nas configurações de disco. Adicione a tag CostCenter=payments.

Tarefa 9.3 — [Portal / PowerShell] Crie a VM opay-vm-win01 no resource group opay-rg-prod, East US, Availability Zone 2, imagem Windows Server 2022 Datacenter, tamanho Standard_D2s_v3, credenciais: usuário opay-vm-admin, senha VMAdm1n@Pay!. Configure a NIC na subnet opay-subnet-mgmt. Habilite Encryption at host. Adicione a tag CostCenter=payments.

Tarefa 9.4 — [Portal / CLI] Adicione um data disk gerenciado de 128 GiB, tipo Premium SSD, à VM opay-vm-linux01. Use opay-vm-linux01 > Disks > Add data disk, crie o disco com nome opay-disk-linux01-data. Após adicionar, conecte via SSH à VM e formate e monte o disco em /data usando fdisk, mkfs.ext4 e mount.

Tarefa 9.5 — [Portal / CLI] Mova a VM opay-vm-win01 para o resource group opay-rg-dr e depois mova de volta para opay-rg-prod, usando opay-vm-win01 > Overview > Move > Move to another resource group. Observe os recursos vinculados que são movidos juntos (NIC, IP público, disco). Registre quais recursos foram e não foram movidos automaticamente.

Valor Capturado

Valor	Onde encontrar	Usado na etapa
IP privado de opay-vm-linux01	VM > Networking > NIC	Etapas 10, 11, 12
IP privado de opay-vm-win01	VM > Networking > NIC	Etapas 10, 11, 12
Nome da VNet	`opay-vnet-prod`	Etapas 10, 11, 12, 13
Resource ID de opay-vm-linux01	VM > Overview > JSON View	Etapa 14
Chave SSH gerada	Par de chaves baixado	Etapa 9 (acesso SSH)

Critérios de Validação

az vm show --name opay-vm-linux01 --resource-group opay-rg-prod --query "zones" deve retornar ["1"].
az vm show --name opay-vm-linux01 --resource-group opay-rg-prod --query "storageProfile.osDisk.managedDisk.securityProfile.securityEncryptionType" ou verificação de Encryption at host via portal deve confirmar a criptografia habilitada.
SSH para o IP público de opay-vm-linux01 com a chave opay-linux-key deve estabelecer conexão e lsblk dentro da VM deve listar o data disk de 128 GiB montado em /data.
az vm list --resource-group opay-rg-prod --query "[].name" deve listar ambas as VMs após a reversão do move.

Etapa 10 — Configurar Redes Virtuais no Azure

Contexto da Etapa

Com as VMs em execução na VNet opay-vnet-prod, o time de rede da OriginPay precisa expandir a topologia: criar uma VNet secundária para o ambiente DR em Brazil South, configurar o peering entre as duas VNets, adicionar UDRs para controlar o fluxo de tráfego e configurar endereços IP públicos estáticos para os serviços expostos. Esta etapa usa os recursos de rede criados na Etapa 9.

Diagrama da Etapa

East US                              Brazil South
opay-vnet-prod (10.10.0.0/16)  ←──peering──→  opay-vnet-dr (10.20.0.0/16)
├── opay-subnet-app (10.10.1.0/24)               └── opay-subnet-dr (10.20.1.0/24)
└── opay-subnet-mgmt (10.10.2.0/24)

UDR: opay-rt-app
└── 0.0.0.0/0 → Next hop: opay-vm-linux01 (NVA simulada)

IP Público Estático: opay-pip-linux01 (SKU Standard)

Ambiente de Execução

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

Tarefas

Tarefa 10.1 — [Portal / CLI] No resource group opay-rg-dr, crie a VNet opay-vnet-dr com address space 10.20.0.0/16 na região Brazil South. Crie a subnet opay-subnet-dr com o prefixo 10.20.1.0/24.

Tarefa 10.2 — [Portal / CLI] Configure o VNet Peering bidirecional entre opay-vnet-prod (East US) e opay-vnet-dr (Brazil South). Em opay-vnet-prod > Peerings > Add, crie o peering opay-peer-prod-to-dr com o remote VNet opay-vnet-dr. Configure a opção Allow forwarded traffic como habilitada em ambas as direções.

Tarefa 10.3 — [Portal / CLI] Crie uma Route Table chamada opay-rt-app no resource group opay-rg-prod, região East US. Adicione uma rota chamada opay-route-default com address prefix 0.0.0.0/0, next hop type Virtual appliance, e next hop address igual ao IP privado de opay-vm-linux01 (obtido na Etapa 9). Associe a route table à subnet opay-subnet-app.

Tarefa 10.4 — [Portal / CLI] Configure um Public IP estático SKU Standard chamado opay-pip-linux01 no resource group opay-rg-prod. Associe este IP público à NIC de opay-vm-linux01. Confirme o IP atribuído e teste a conectividade SSH via o novo IP estático.

Tarefa 10.5 — [Portal / PowerShell] Simule um problema de conectividade: remova temporariamente a associação da route table opay-rt-app da subnet opay-subnet-app. Tente pingar de opay-vm-linux01 para o IP privado de opay-vm-win01. Documente o resultado. Re-associe a route table e retest. Use Network Watcher > Connection troubleshoot para diagnosticar a conectividade entre as duas VMs.

Valor Capturado

Valor	Onde encontrar	Usado na etapa
IP público estático de opay-vm-linux01	Portal > opay-pip-linux01 > Overview	Etapas 11, 12
Nome do VNet peering	`opay-peer-prod-to-dr`	Etapas 12, 19
Address space da VNet DR	`10.20.0.0/16`	Etapa 12

Critérios de Validação

az network vnet peering show --name opay-peer-prod-to-dr --vnet-name opay-vnet-prod --resource-group opay-rg-prod --query peeringState deve retornar "Connected".
Ping entre opay-vm-linux01 e opay-vm-win01 (IP privados) deve funcionar via o peering (testar com ping <ip-privado-win01> dentro da VM Linux via SSH).
az network route-table route list --route-table-name opay-rt-app --resource-group opay-rg-prod deve listar a rota opay-route-default com nextHopType: VirtualAppliance.

Etapa 11 — Acesso Seguro a Redes Virtuais

Contexto da Etapa

O ambiente de produção da OriginPay precisa de controles de segurança de rede em múltiplas camadas. Esta etapa configura NSGs e ASGs, implementa o Azure Bastion para acesso seguro às VMs sem expor RDP/SSH à internet, e configura Private Endpoints para o storage account opayprodSUFIXO eliminar o tráfego público. Os Service Endpoints criados na Etapa 9 serão complementados.

Diagrama da Etapa

Internet
    │
    │ (sem RDP/SSH direto)
    ▼
Azure Bastion (opay-bastion) → opay-vm-linux01, opay-vm-win01
    │                                   (acesso interno seguro)
    ▼
NSG: opay-nsg-app
    ├── Inbound: Allow HTTPS 443 from Internet
    ├── Inbound: Allow SSH 22 from opay-bastion-subnet only
    ├── Inbound: Deny all other
    └── Outbound: Allow to opay-sa (via Private Endpoint)

Private Endpoint: opay-pe-storage → opayprodSUFIXO
    └── DNS: opayprodSUFIXO.blob.core.windows.net → 10.10.1.x (IP privado)

Ambiente de Execução

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

Tarefas

Tarefa 11.1 — [Portal / CLI] Crie um Application Security Group (ASG) chamado opay-asg-webservers no resource group opay-rg-prod. Associe a NIC de opay-vm-linux01 ao ASG opay-asg-webservers via opay-vm-linux01 > Networking > NIC > Application security groups.

Tarefa 11.2 — [Portal / CLI] Crie um NSG chamado opay-nsg-app no resource group opay-rg-prod. Adicione as seguintes regras inbound: prioridade 100 — Allow HTTPS (TCP 443) de Any para opay-asg-webservers; prioridade 200 — Allow SSH (TCP 22) de source AzureBastionSubnet para opay-asg-webservers; prioridade 4000 — Deny all inbound. Associe o NSG à subnet opay-subnet-app.

Tarefa 11.3 — [Portal] Demonstração do estado inseguro: antes de configurar o Bastion, verifique se o IP público de opay-vm-linux01 responde a SSH diretamente da internet (via NSG atual). Documente o resultado. Em seguida, crie o Azure Bastion chamado opay-bastion no resource group opay-rg-prod: o portal criará automaticamente a subnet AzureBastionSubnet (adicione com prefixo /26 na VNet opay-vnet-prod, CIDR 10.10.3.0/26). Use o SKU Standard e habilite Native client support. Remova o IP público de opay-vm-linux01 após o Bastion estar ativo.

Tarefa 11.4 — [Portal / CLI] Crie um Private Endpoint chamado opay-pe-storage para o storage account opayprodSUFIXO, recurso alvo blob, na subnet opay-subnet-app. Configure a Private DNS Zone privatelink.blob.core.windows.net para integração DNS automática.

Tarefa 11.5 — [PowerShell / CLI] Dentro de opay-vm-linux01 (via Azure Bastion), execute nslookup opayprodSUFIXO.blob.core.windows.net e confirme que o hostname resolve para o IP privado do Private Endpoint (ex: 10.10.1.x) em vez do IP público do storage. Em seguida, tente acessar o blob transacao-teste.pdf via curl com a SAS URL, confirmando o acesso pelo caminho privado.

Valor Capturado

Valor	Onde encontrar	Usado na etapa
IP privado do Private Endpoint	Portal > opay-pe-storage > Network interface	Etapa 19
Nome do NSG	`opay-nsg-app`	Etapas 12, 19
Nome do Bastion	`opay-bastion`	Etapas 12, 19

Critérios de Validação

nslookup opayprodSUFIXO.blob.core.windows.net dentro de opay-vm-linux01 deve retornar um IP no range 10.10.1.0/24 (IP privado do Private Endpoint).
az network nsg rule list --nsg-name opay-nsg-app --resource-group opay-rg-prod --query "[].name" deve listar as 3 regras criadas (use o portal para ver prioridade e acesso completo).
Conexão SSH direta ao IP público de opay-vm-linux01 (após remoção do IP público) deve falhar com timeout, enquanto o acesso via Azure Bastion deve funcionar.

Etapa 12 — DNS, Load Balancer e Troubleshooting de Rede

Contexto da Etapa

O portal administrativo da OriginPay (opay-vm-win01) e o backend Linux (opay-vm-linux01) precisam ser acessados via nomes DNS amigáveis e distribuição de carga. Esta etapa configura uma Azure DNS Zone, um Internal Load Balancer para o backend, e inclui um cenário de troubleshooting de conectividade usando Network Watcher.

Diagrama da Etapa

Internet
    │ DNS: pagamentos.originpay.com.br → IP do Load Balancer
    ▼
opay-lb-prod (Internal Load Balancer, 10.10.1.100)
    ├── Backend Pool: opay-vm-linux01 (port 80)
    └── Health Probe: TCP 80

Azure DNS Zone: originpay.com.br (zona pública)
    ├── A record: pagamentos → IP público do LB (se público) ou alias
    └── CNAME: www → pagamentos.originpay.com.br

Private DNS Zone: originpay.internal
    ├── A: linux01.originpay.internal → 10.10.1.x
    └── A: win01.originpay.internal → 10.10.2.x

Ambiente de Execução

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

Tarefas

Tarefa 12.1 — [Portal / CLI] Crie uma Azure DNS Public Zone chamada originpay.com.br no resource group opay-rg-prod. Adicione um A record chamado pagamentos com TTL 300 apontando para o IP público de opay-pip-linux01. Adicione um CNAME record www com TTL 300 apontando para pagamentos.originpay.com.br. Anote os Name Servers da zona (serão 4 servidores ns*.azure-dns.*).

Tarefa 12.2 — [Portal / CLI] Crie uma Azure Private DNS Zone chamada originpay.internal no resource group opay-rg-prod. Associe a Private DNS Zone à VNet opay-vnet-prod (Virtual network link, nome: opay-vnet-link-prod, habilite auto-registration). Adicione manualmente registros A: linux01.originpay.internal → IP privado de opay-vm-linux01 e win01.originpay.internal → IP privado de opay-vm-win01.

Tarefa 12.3 — [Portal / CLI] Crie um Internal Load Balancer chamado opay-lb-prod no resource group opay-rg-prod, SKU Standard, região East US, subnet opay-subnet-app, IP frontend estático 10.10.1.100. Configure: Backend Pool opay-bp-linux com opay-vm-linux01, Health Probe opay-probe-http (TCP, porta 80, intervalo 15s), e Load Balancing Rule na porta 80 para o backend pool.

Tarefa 12.4 — [Portal / PowerShell] Dentro de opay-vm-win01 (via Bastion), teste a resolução DNS interna: nslookup linux01.originpay.internal deve retornar o IP privado de opay-vm-linux01. Em seguida, teste a conectividade HTTP ao Load Balancer: curl http://10.10.1.100 (instale curl se necessário via PowerShell ou habilite um servidor HTTP simples no Linux via python3 -m http.server 80).

Tarefa 12.5 — [Portal] Simule um cenário de troubleshooting: remova opay-vm-linux01 do backend pool do LB temporariamente e tente acessar http://10.10.1.100 a partir de opay-vm-win01. A requisição deve falhar (503 ou timeout). Use Network Watcher > Connection troubleshoot com source opay-vm-win01 e destination IP 10.10.1.100 porta 80 para diagnosticar. Re-adicione a VM ao backend pool e confirme a recuperação.

Valor Capturado

Valor	Onde encontrar	Usado na etapa
IP frontend do LB	`opay-lb-prod > Frontend IP configurations`	Etapas 13, 19
Name Servers da DNS Zone	DNS Zone > Overview	Etapa 12 (validação)
Nome da Private DNS Zone	`originpay.internal`	Etapa 19

Critérios de Validação

az network dns record-set a show --zone-name originpay.com.br --resource-group opay-rg-prod --name pagamentos deve retornar o IP de opay-pip-linux01.
nslookup linux01.originpay.internal dentro de opay-vm-win01 deve retornar o IP privado correto de opay-vm-linux01.
az network lb show --name opay-lb-prod --resource-group opay-rg-prod --query "loadBalancingRules[0].frontendPort" deve retornar 80.

Etapa 13 — Virtual Machine Scale Sets

Contexto da Etapa

O backend de processamento PIX da OriginPay tem picos de carga durante horário comercial. O opay-vm-linux01 isolado não suporta escalonamento automático. Esta etapa cria um VM Scale Set (VMSS) para o backend, configurado com autoscaling baseado em CPU, integrado ao Load Balancer criado na Etapa 12.

Ambiente de Execução

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

Tarefas

Tarefa 13.1 — [Portal / CLI] Crie um VM Scale Set chamado opay-vmss-backend no resource group opay-rg-prod, East US, imagem Ubuntu Server 22.04 LTS, tamanho Standard_D2s_v3, modo de orquestração Flexible, autenticação por SSH, credenciais com a chave opay-linux-key. Configure o VMSS com 2 instâncias iniciais, número mínimo 1, máximo 5. Conecte ao Load Balancer opay-lb-prod e ao backend pool opay-bp-linux.

Tarefa 13.2 — [Portal] Configure o Autoscale no VMSS opay-vmss-backend: em opay-vmss-backend > Scaling, habilite o Custom autoscale. Adicione uma regra de scale out quando CPU média > 70% por 5 minutos (aumente 2 instâncias), e uma regra de scale in quando CPU média < 30% por 10 minutos (remova 1 instância). Configure o período de cooldown como 5 minutos para scale out e 10 minutos para scale in.

Tarefa 13.3 — [CLI / PowerShell] Verifique as instâncias do VMSS com az vmss list-instances --name opay-vmss-backend --resource-group opay-rg-prod. Escale manualmente para 3 instâncias usando az vmss scale com o parâmetro --new-capacity 3. Confirme as 3 instâncias no portal.

Tarefa 13.4 — [Portal / CLI] Configure a política de upgrade do VMSS para Rolling com batch size de 25% e pause entre batches de 5 minutos. Aplique uma atualização de imagem de SO (ou extensão de VM simples) para testar o rolling upgrade sem downtime.

Valor Capturado

Valor	Onde encontrar	Usado na etapa
Nome do VMSS	`opay-vmss-backend`	Etapas 14, 19
Política de autoscale	Portal > VMSS > Scaling	Etapa 19

Critérios de Validação

az vmss list-instances --name opay-vmss-backend --resource-group opay-rg-prod --query "[].instanceId" deve retornar 3 IDs após o scale manual.
Em opay-vmss-backend > Scaling > Autoscale, devem existir pelo menos 2 regras (scale out e scale in) com os thresholds de CPU configurados.
az vmss show --name opay-vmss-backend --resource-group opay-rg-prod --query "upgradePolicy.mode" deve retornar "Rolling".

Etapa 14 — Containers: ACR, ACI e Azure Container Apps

Contexto da Etapa

O time de desenvolvimento da OriginPay quer containerizar o serviço de consulta de status de transações PIX. Esta etapa cria um Azure Container Registry (ACR), faz push de uma imagem de container, provisiona um container via Azure Container Instances (ACI) para testes rápidos, e implanta a versão produtiva via Azure Container Apps.

Diagrama da Etapa

opay-rg-prod (East US)
├── opay-acr-prod (Azure Container Registry)
│       └── opay-pix-status:v1.0 (imagem de container)
│
├── opay-aci-test (Azure Container Instances)
│       └── Teste rápido da imagem: porta 80, 1 CPU, 1.5 GB RAM
│
└── opay-capp-env-prod (Container Apps Environment)
        └── opay-capp-pix (Azure Container App)
                ├── Imagem: opay-acr-prod.azurecr.io/opay-pix-status:v1.0
                ├── Ingress: External, porta 80
                └── Scale: min 1, max 5 réplicas

Ambiente de Execução

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

Tarefas

Tarefa 14.1 — [Portal / CLI] Crie um Azure Container Registry chamado opayprodSUFIXOacr (sem hífens, max 50 chars) no resource group opay-rg-prod, SKU Standard, região East US. Habilite o Admin user para acesso inicial. Anote o login server (opayprodSUFIXOacr.azurecr.io).

Tarefa 14.2 — [CLI] Faça login no ACR com az acr login --name opayprodSUFIXOacr. Crie uma imagem Docker simples localmente (ou use Cloud Shell): crie um Dockerfile com base nginx:alpine e adicione um arquivo index.html com o texto OriginPay PIX Status v1.0. Faça build com docker build, tag como opayprodSUFIXOacr.azurecr.io/opay-pix-status:v1.0 e push para o ACR com docker push. Verifique a imagem em ACR > Repositories.

Tarefa 14.3 — [Portal / CLI] Provisionei um Azure Container Instance chamado opay-aci-test no resource group opay-rg-prod, imagem opayprodSUFIXOacr.azurecr.io/opay-pix-status:v1.0, 1 CPU, 1.5 GB RAM, OS Linux, porta 80, IP público. Use as credenciais do Admin user do ACR para pull da imagem. Acesse o IP público gerado e confirme o conteúdo HTML OriginPay PIX Status v1.0.

Tarefa 14.4 — [Portal / CLI] Crie um Container Apps Environment chamado opay-capp-env-prod no resource group opay-rg-prod. Dentro do environment, crie um Container App chamado opay-capp-pix usando a imagem opay-pix-status:v1.0 do ACR opayprodSUFIXOacr. Configure: Ingress External, porta de destino 80, número mínimo de réplicas 1, máximo 5. Anote a URL FQDN gerada.

Tarefa 14.5 — [Portal / CLI] Escale o Container App opay-capp-pix manualmente para 3 réplicas via opay-capp-pix > Scale and replicas > Edit and deploy > Scale. Configure também uma regra de scale automático baseada em HTTP requests: scale out quando concurrent requests > 100, scale in quando < 20. Verifique a URL FQDN do Container App retorna o conteúdo correto.

Valor Capturado

Valor	Onde encontrar	Usado na etapa
Login server do ACR	ACR > Overview	Etapa 19
FQDN do Container App	Portal > opay-capp-pix > Overview	Etapa 15, 19
IP público do ACI	Portal > opay-aci-test > Overview	Etapa 19

Critérios de Validação

az acr repository list --name opayprodSUFIXOacr deve listar opay-pix-status.
curl http://<ip-aci-test> deve retornar HTML contendo OriginPay PIX Status v1.0.
az containerapp show --name opay-capp-pix --resource-group opay-rg-prod --query "properties.latestRevisionFqdn" deve retornar a URL FQDN acessível.

Etapa 15 — Azure App Service

Contexto da Etapa

O portal web da OriginPay para consulta de extratos será hospedado no Azure App Service (em vez de VMs), aproveitando o PaaS gerenciado. O App Service usará o domínio originpay.com.br (configurado na Etapa 12), certificado TLS, slots de deployment e integração com a VNet opay-vnet-prod.

Ambiente de Execução

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

Tarefas

Tarefa 15.1 — [Portal / CLI] Crie um App Service Plan chamado opay-asp-prod no resource group opay-rg-prod, região East US, OS Linux, SKU P1v3 (ou B2 para reduzir custo no lab). Configure o autoscale: mínimo 1 instância, máximo 3, regra de scale out baseada em CPU > 75%.

Tarefa 15.2 — [Portal / CLI] Crie um App Service (Web App) chamado opay-webapp-extratos no App Service Plan opay-asp-prod, runtime Node.js 20 LTS (ou Python 3.11). Faça o deploy de um app simples de teste (use az webapp up ou zip deploy via az webapp deployment source config-zip) que retorne um JSON com status: ok e service: OriginPay Extratos em GET /.

Tarefa 15.3 — [Portal] Configure o custom domain extratos.originpay.com.br no App Service opay-webapp-extratos: em Custom domains > Add custom domain, adicione o domínio e siga as instruções para criar um registro TXT e CNAME na DNS Zone originpay.com.br (criada na Etapa 12). Configure um Managed Certificate gratuito via Certificates > Managed certificates > Add certificate para o domínio.

Tarefa 15.4 — [Portal] Configure um deployment slot chamado staging no App Service opay-webapp-extratos: em Deployment slots > Add slot, crie o slot staging sem clonar configurações. Faça o deploy de uma versão modificada do app (ex: resposta JSON com service: OriginPay Extratos v2 STAGING) no slot staging. Execute um slot swap para promover o staging para produção.

Tarefa 15.5 — [Portal / CLI] Configure o VNet Integration do App Service opay-webapp-extratos para a VNet opay-vnet-prod, subnet opay-subnet-app: em Networking > VNet Integration > Add VNet. Após a integração, configure um backup do App Service: em Backups > Configure, use o storage account opayprodSUFIXO e container opay-logs como destino, schedule diário às 02:00 com retenção de 7 dias.

Valor Capturado

Valor	Onde encontrar	Usado na etapa
URL padrão do App Service	`opay-webapp-extratos.azurewebsites.net`	Etapa 19
Nome do deployment slot	`staging`	Etapa 19
URL do custom domain	`extratos.originpay.com.br`	Etapa 19

Critérios de Validação

curl https://opay-webapp-extratos.azurewebsites.net/ deve retornar HTTP 200 com corpo JSON contendo status: ok e service: OriginPay Extratos.
Após o slot swap, curl https://opay-webapp-extratos.azurewebsites.net/ deve retornar a versão v2 (com texto STAGING promovido).
az webapp show --name opay-webapp-extratos --resource-group opay-rg-prod --query "siteConfig.vnetRouteAllEnabled" deve retornar true após a VNet integration.

Etapa 16 — Monitoramento com Azure Monitor

Contexto da Etapa

O SLA da OriginPay exige visibilidade de performance e alertas proativos para os sistemas de pagamento. Esta etapa configura o Azure Monitor para coletar métricas e logs das VMs, storage e rede, cria alertas com action groups e usa o Network Watcher para monitoramento de conectividade. Todas as resources criadas nas etapas anteriores serão cobertas.

Ambiente de Execução

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

Tarefas

Tarefa 16.1 — [Portal] Crie um Log Analytics Workspace chamado opay-law-prod no resource group opay-rg-prod, região East US, SKU PerGB2018. Em VM Insights, habilite o monitoramento para opay-vm-linux01 e opay-vm-win01: navegue em Monitor > Virtual Machines > opay-vm-linux01 > Enable e selecione o workspace opay-law-prod. Repita para a Windows VM.

Tarefa 16.2 — [Portal] Configure Diagnostic settings para o storage account opayprodSUFIXO: em Monitoring > Diagnostic settings, adicione uma configuração chamada opay-diag-storage. Envie as categorias StorageRead, StorageWrite e a métrica Transaction para o workspace opay-law-prod.

Tarefa 16.3 — [Portal / CLI] Crie um Action Group chamado opay-ag-infra no resource group opay-rg-prod. Adicione as ações: Email para ana.souza@originpay.onmicrosoft.com com nome Email-TI, e SMS para um número simulado (ex: +55 11 99999-0000) com nome SMS-Oncall. Em seguida, crie um Alert Rule chamado opay-alert-cpu-linux para a VM opay-vm-linux01: métrica Percentage CPU, threshold estático > 80%, período de avaliação 5 minutos, action group opay-ag-infra.

Tarefa 16.4 — [Portal] Em Monitor > Logs, execute as seguintes queries KQL no workspace opay-law-prod:

Query 1 — Eventos de performance das VMs:

Perf
| where ObjectName == "Processor"
| where CounterName == "% Processor Time"
| summarize AvgCPU = avg(CounterValue) by Computer, bin(TimeGenerated, 5m)
| order by TimeGenerated desc

Query 2 — Operações no storage account:

StorageBlobLogs
| where OperationName == "GetBlob"
| project TimeGenerated, AccountName, CallerIpAddress, DurationMs
| limit 50

Tarefa 16.5 — [Portal] Configure o Network Watcher na região East US: em Network Watcher > Connection monitor, crie um monitor chamado opay-cm-linux-to-storage com source opay-vm-linux01 e destination FQDN opayprodSUFIXO.blob.core.windows.net, porta 443, protocolo TCP, frequência de teste 60 segundos. Verifique os resultados após 5 minutos de coleta.

Valor Capturado

Valor	Onde encontrar	Usado na etapa
Resource ID do Log Analytics Workspace	Portal > opay-law-prod > Properties	Etapa 17
Nome do Action Group	`opay-ag-infra`	Etapa 19
Nome da Alert Rule	`opay-alert-cpu-linux`	Etapa 19

Critérios de Validação

Em Monitor > Alerts > Alert rules, a regra opay-alert-cpu-linux deve aparecer com status Enabled e o action group opay-ag-infra associado.
A query KQL da Tarefa 16.4 (Query 1) executada no workspace opay-law-prod deve retornar dados de CPU para opay-vm-linux01 e opay-vm-win01 (após alguns minutos de coleta).
az monitor connection-monitor show --name opay-cm-linux-to-storage --network-watcher-name NetworkWatcher_eastus --resource-group NetworkWatcherRG deve retornar o monitor com status Running.

Etapa 17 — Backup e Recuperação

Contexto da Etapa

A regulação de meios de pagamento exige RPO de 1 hora e RTO de 4 horas para os sistemas críticos da OriginPay. Esta etapa configura o Azure Backup para as VMs e o Azure Site Recovery para replicação da VM Linux para Brazil South. É a etapa que integra o maior número de recursos criados anteriormente: VMs (Etapa 9), storage (Etapas 5-6), a VNet DR (Etapa 10) e o Monitor (Etapa 16).

Diagrama da Etapa

East US (Primary)                    Brazil South (DR)
opay-vm-linux01                  →   opay-vm-linux01-replica
    │ Azure Site Recovery (ASR)         (failover target)
    ▼
opay-rsv-prod (Recovery Services Vault)
    ├── Backup: opay-vm-linux01 (diário, 7 dias retenção)
    ├── Backup: opay-vm-win01 (diário, 30 dias retenção)
    └── Site Recovery: replicação para Brazil South

opay-abv-prod (Azure Backup Vault)
    └── Backup policy: Azure Blobs (opay-docs, 30 dias)

Ambiente de Execução

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

Tarefas

Tarefa 17.1 — [Portal / CLI] Crie um Recovery Services Vault chamado opay-rsv-prod no resource group opay-rg-prod, região East US, redundância GRS. Navegue em opay-rsv-prod > Backup > Azure Virtual Machine e configure backup para opay-vm-linux01 com a policy padrão (diário, retenção 7 dias). Crie uma nova backup policy chamada opay-bp-win com schedule diário às 23:00, retenção diária 30 dias, semanal 4 semanas, e aplique em opay-vm-win01.

Tarefa 17.2 — [Portal] Crie um Azure Backup Vault chamado opay-abv-prod no resource group opay-rg-prod. Configure uma backup policy para Azure Blobs com retenção de 30 dias. Associe a policy ao storage account opayprodSUFIXO em opay-abv-prod > Backup > Azure Blobs.

Tarefa 17.3 — [Portal] Inicie um backup on-demand de opay-vm-linux01: em opay-rsv-prod > Protected items > Backup items > Azure Virtual Machine > opay-vm-linux01 > Backup now. Aguarde a conclusão (pode levar 10-30 minutos) e confirme o status em Backup jobs.

Tarefa 17.4 — [Portal] Configure o Azure Site Recovery para opay-vm-linux01: em opay-rsv-prod > Site Recovery > Azure virtual machines > Enable replication. Configure: região de origem East US, região de destino Brazil South, resource group de destino opay-rg-dr, VNet de destino opay-vnet-dr. Aguarde que a replicação inicial complete (pode levar 30-60 minutos) e verifique o estado em Replicated items.

Tarefa 17.5 — [Portal] Execute um failover de teste (Test Failover): em opay-rsv-prod > Replicated items > opay-vm-linux01 > Test Failover. Selecione o ponto de recuperação mais recente, VNet de destino opay-vnet-dr. Após o teste, navegue em opay-rg-dr e confirme que a VM de teste foi criada com sucesso. Limpe o failover de teste em Cleanup test failover. Configure e revise os alertas de backup integrados ao action group opay-ag-infra criado na Etapa 16.

Valor Capturado

Valor	Onde encontrar	Usado na etapa
Nome do RSV	`opay-rsv-prod`	Etapa 19
Status de replicação ASR	RSV > Replicated items	Etapa 19
Último ponto de restauração	RSV > Backup items > opay-vm-linux01	Etapa 19

Critérios de Validação

Em opay-rsv-prod > Backup items > Azure Virtual Machine, opay-vm-linux01 deve aparecer com status Backup succeeded após o backup on-demand.
Em opay-rsv-prod > Replicated items, opay-vm-linux01 deve aparecer com Replication health: Healthy e RPO within target.
O Test Failover deve criar uma VM em opay-rg-dr com estado Running e ser limpado com sucesso (status Cleanup succeeded em Backup jobs).
az backup item list --vault-name opay-rsv-prod --resource-group opay-rg-prod --backup-management-type AzureIaasVM deve listar opay-vm-linux01 e opay-vm-win01 com properties.lastBackupStatus: Completed.

Validação Global do Ambiente

Checklist de Recursos

Recurso	Etapa	Estado Esperado
Usuários: ana.souza, carlos.lima, svc-devops	1	Enabled, usageLocation: BR
Grupo opay-grp-admins	1	Criado, ana.souza como membro
Grupo opay-grp-devs	1	Criado, carlos.lima e guest como membros
SSPR habilitado para opay-grp-admins	1	Scope: Selected (opay-grp-admins)
RBAC: ana.souza = Contributor na subscription	2	Role assignment ativo
RBAC: carlos.lima = Reader em opay-rg-prod	2	Role assignment ativo
RBAC: opay-grp-devs = Contributor em opay-rg-dr	2	Role assignment ativo
Management groups opay-mg-root e opay-mg-prod	3	Hierarquia configurada
Policy: opay-policy-allowed-locations	3	Aplicada na subscription
Policy: opay-policy-require-costcenter	3	Aplicada na subscription
Lock: CanNotDelete em opay-rg-prod	3	Ativo
Budget: opay-budget-monthly (USD 500)	4	Ativo, alertas 80% e 100%
Storage account: opayprodSUFIXO	5	Standard_GRS → RA-GRS, TLS 1.2, CMK
Container: opay-docs	5	Private, com SAS e stored access policy
File share: opay-fileshare (100 GiB)	5	Entra ID Kerberos habilitado
Key Vault: opay-kv-prod	6	Soft delete + purge protection, chave CMK
Storage DR: opaydrSUFIXO	6	LRS, object replication configurada
Lifecycle policy: opay-lifecycle-logs	7	Cool 30d, Archive 90d, Delete 365d
Blob versioning habilitado	7	Ativo em opayprodSUFIXO
Soft delete (blobs e containers): 14 dias	7	Ativo
Storage staging: opaystagingSUFIXO	8	Standard_LRS, criado via Bicep
Container opay-logs	8	Criado via ARM template modificado
VNet: opay-vnet-prod (10.10.0.0/16)	9	East US, 3 subnets
VM: opay-vm-linux01	9	Running, Zone 1, encryption at host
VM: opay-vm-win01	9	Running, Zone 2, encryption at host
Data disk opay-disk-linux01-data (128 GiB)	9	Attached, montado em /data
VNet DR: opay-vnet-dr (10.20.0.0/16)	10	Brazil South
VNet Peering: opay-peer-prod-to-dr	10	Status: Connected
Route Table: opay-rt-app	10	Associada a opay-subnet-app
Public IP: opay-pip-linux01 (Static, Standard)	10	Associado a opay-vm-linux01
ASG: opay-asg-webservers	11	opay-vm-linux01 como membro
NSG: opay-nsg-app	11	3 regras, associado a opay-subnet-app
Azure Bastion: opay-bastion	11	Running, SKU Standard
Private Endpoint: opay-pe-storage	11	Conectado a opayprodSUFIXO.blob
DNS Zone pública: originpay.com.br	12	A record pagamentos, CNAME www
Private DNS Zone: originpay.internal	12	Linked a opay-vnet-prod, auto-registration
Internal Load Balancer: opay-lb-prod	12	Frontend 10.10.1.100, regra porta 80
VMSS: opay-vmss-backend	13	Flexible, autoscale CPU 70%/30%
ACR: opayprodSUFIXOacr	14	Standard, imagem opay-pix-status:v1.0
ACI: opay-aci-test	14	Running, porta 80
Container App: opay-capp-pix	14	External ingress, min 1 réplica
App Service Plan: opay-asp-prod	15	P1v3, Linux, autoscale 3 instâncias
App Service: opay-webapp-extratos	15	Running, slot staging, VNet integration
Log Analytics Workspace: opay-law-prod	16	VM Insights habilitado
Alert Rule: opay-alert-cpu-linux	16	Enabled, CPU > 80%
Action Group: opay-ag-infra	16	Email + SMS configurados
Connection Monitor: opay-cm-linux-to-storage	16	Running
Recovery Services Vault: opay-rsv-prod	17	GRS, backup de ambas as VMs
Azure Backup Vault: opay-abv-prod	17	Backup de blobs configurado
ASR replication: opay-vm-linux01 → Brazil South	17	Health: Healthy

Testes de Integração End-to-End

Teste 1 — Identidade, RBAC e acesso ao storage

# Como carlos.lima (Reader em opay-rg-prod), tente listar blobs no storage:
az login --username carlos.lima@originpay.onmicrosoft.com
az storage blob list \
  --container-name opay-docs \
  --account-name opayprodSUFIXO \
  --auth-mode login

# Resultado esperado: AuthorizationPermissionMismatch (carlos.lima não tem
# papel de acesso a dados de storage, apenas Reader no resource group)
# Resultado com SAS URL: HTTP 200 (acesso pelo token SAS independe do RBAC)

Teste 2 — Conectividade privada end-to-end

# Via Azure Bastion, dentro de opay-vm-linux01:

# Resolução DNS privada para o storage (via Private Endpoint):
nslookup opayprodSUFIXO.blob.core.windows.net
# Esperado: IP no range 10.10.1.x (não um IP público da Microsoft)

# Resolução DNS interna:
nslookup win01.originpay.internal
# Esperado: IP privado de opay-vm-win01 (10.10.2.x)

# Conectividade ao Load Balancer interno:
curl -s http://10.10.1.100
# Esperado: resposta HTTP da página nginx do VMSS (status 200)

Teste 3 — Failover e recuperação

# Verifique o status do ASR para opay-vm-linux01:
az site-recovery replication-protected-item list \
  --vault-name opay-rsv-prod \
  --resource-group opay-rg-prod \
  --query "[].{VM:name, Health:properties.replicationHealth, RPO:properties.rpoInSeconds}"

# Resultado esperado:
# [{"VM": "opay-vm-linux01", "Health": "Normal", "RPO": <valor em segundos <= 3600}]

# Verifique o último backup bem-sucedido:
az backup item list \
  --vault-name opay-rsv-prod \
  --resource-group opay-rg-prod \
  --backup-management-type AzureIaasVM \
  --query "[].{VM:properties.friendlyName, LastBackup:properties.lastBackupTime, Status:properties.lastBackupStatus}"

# Resultado esperado: lastBackupStatus = "Completed" para ambas as VMs

Teste 4 — App Service e domínio customizado

# Teste o endpoint principal:
curl -s https://opay-webapp-extratos.azurewebsites.net/ | python3 -m json.tool
# Resultado esperado:
# {
#   "status": "ok",
#   "service": "OriginPay Extratos v2 STAGING"
# }

# Teste o Container App:
curl -s https://<fqdn-opay-capp-pix>
# Resultado esperado: página nginx com "OriginPay PIX Status v1.0"

Teste 5 — Policy e governança

# Tente criar um resource group em westeurope (deve ser bloqueado pela policy):
az group create --name opay-rg-test-policy --location westeurope

# Resultado esperado:
# (ResourceGroupNotAllowedByPolicy) Resource 'opay-rg-test-policy' was disallowed
# by policy 'opay-policy-allowed-locations'.

# Verifique tags em opay-rg-prod:
az group show --name opay-rg-prod --query tags
# Resultado esperado:
# {"CostCenter": "payments", "Env": "prod"}

O Que Pode Dar Errado

Etapa	Erro Comum	Causa Provável
1	SSPR não disponível para configuração	Licença P1 não atribuída ao usuário ou ao tenant
2	Role assignment falha com "insufficient privileges"	Conta não tem Owner ou User Access Administrator na subscription
3	Policy não bloqueia criação em westeurope	Effect da policy configurado como Audit em vez de Deny
3	Resource Lock não permite exclusão do RG	Comportamento esperado — remova o lock antes de excluir no lab
4	Budget alerts não chegam por email	Conta de email não verificada ou período de entrega de até 8 horas
5	Storage account name indisponível	Nome deve ser globalmente único; adicione sufixo diferente
5	SAS URL retorna 403	Token expirado ou permissões insuficientes; regenere o SAS
6	Object Replication falha	Blob versioning deve estar habilitado em ambos os storage accounts
6	CMK não aceita a chave do Key Vault	Identidade gerenciada do storage não tem permissão no Key Vault
7	Lifecycle policy não move blobs	Política leva até 24h para ser executada; simule com blobs com last-modified antigo
8	Bicep decompile gera erros	Alguns recursos têm propriedades que não decompilam perfeitamente; corrigir manualmente
9	Encryption at host falha	Feature não registrada na subscription; registre `EncryptionAtHost` com `az feature register`
9	Move da VM falha	Recursos vinculados (ex: Key Vault, disco criptografado) podem bloquear o move
10	VNet Peering fica em "Disconnected"	Endereços CIDR sobrepostos entre as VNets; verificar address spaces
10	UDR redireciona tráfego incorretamente	IP Forwarding não habilitado na NIC da VM usada como NVA
11	Bastion não conecta à VM	AzureBastionSubnet com prefixo menor que /26 ou NSG bloqueando portas
11	Private Endpoint não resolve DNS privado	Private DNS Zone não linkada à VNet correta
12	Load Balancer não distribui tráfego	Health probe falhando (app não respondendo na porta monitorada)
13	VMSS instances não escalam	Autoscale não habilitado ou cooldown period muito longo
14	Docker push falha no ACR	`az acr login` não executado ou Admin user não habilitado
15	Custom domain validation falha	Registro TXT ou CNAME ainda não propagou; aguardar TTL
15	Slot swap falha	App Service Plan tier não suporta slots (mínimo Standard)
16	Logs não aparecem no workspace	Diagnostic settings recém-criados levam até 15 minutos para popular
17	ASR replication falha	Cache storage account não criado na região de origem ou permissões insuficientes
17	Test Failover não cria VM no DR	VNet de destino não configurada corretamente ou subnet sem capacidade

Diagrama Final do Ambiente Completo

Microsoft Entra ID (originpay.onmicrosoft.com)
├── Users: ana.souza, carlos.lima, svc-devops, guest-parceiro
├── Groups: opay-grp-admins (Contributor/sub), opay-grp-devs (Contributor/dr)
└── SSPR: habilitado para opay-grp-admins

Azure Subscription: OriginPay
├── Management Groups: opay-mg-root > opay-mg-prod > [subscription]
├── Policies: allowed-locations (eastus, brazilsouth), require-costcenter
├── Budget: opay-budget-monthly (USD 500, alertas 80%/100%)
│
├── opay-rg-identity (East US)
│       └── [identidade gerenciada pelo Entra ID]
│
├── opay-rg-prod (East US) [Lock: CanNotDelete]
│     Tags: CostCenter=payments, Env=prod
│     │
│     ├── Networking
│     │     ├── opay-vnet-prod (10.10.0.0/16)
│     │     │     ├── opay-subnet-app (10.10.1.0/24) [NSG: opay-nsg-app] [RT: opay-rt-app]
│     │     │     ├── opay-subnet-mgmt (10.10.2.0/24)
│     │     │     └── AzureBastionSubnet (10.10.3.0/26)
│     │     ├── opay-pip-linux01 (Static Public IP)
│     │     ├── opay-bastion (Azure Bastion, Standard)
│     │     ├── opay-lb-prod (Internal LB, 10.10.1.100, porta 80)
│     │     ├── opay-nsg-app (Allow HTTPS/SSH/Bastion, Deny all)
│     │     ├── opay-rt-app (UDR → opay-vm-linux01 como NVA)
│     │     └── opay-peer-prod-to-dr ←→ opay-vnet-dr
│     │
│     ├── Compute
│     │     ├── opay-vm-linux01 (Ubuntu 22.04, Zone 1, D2s_v3, disk 128GiB /data)
│     │     ├── opay-vm-win01 (WS2022, Zone 2, D2s_v3)
│     │     ├── opay-vmss-backend (Ubuntu, Flexible, autoscale 1-5)
│     │     └── opay-aci-test (nginx, 1CPU/1.5GB, porta 80)
│     │
│     ├── Storage
│     │     ├── opayprodSUFIXO (RA-GRS, CMK, Private Endpoint, versioning)
│     │     │     ├── opay-docs (blobs, SAS, stored access policy, lifecycle)
│     │     │     └── opay-logs (blobs)
│     │     ├── opaystagingSUFIXO (LRS, criado via Bicep)
│     │     └── opay-kv-prod (Key Vault, CMK key: opay-storage-key)
│     │
│     ├── App & Containers
│     │     ├── opay-asp-prod (P1v3 Linux, autoscale 1-3)
│     │     ├── opay-webapp-extratos (Node.js, custom domain, slot staging)
│     │     ├── opayprodSUFIXOacr (ACR Standard, imagem pix-status:v1.0)
│     │     └── opay-capp-env-prod > opay-capp-pix (Container App, External)
│     │
│     ├── Governance & Monitor
│     │     ├── opay-law-prod (Log Analytics, VM Insights)
│     │     ├── opay-ag-infra (Action Group: email + SMS)
│     │     ├── opay-alert-cpu-linux (CPU > 80%)
│     │     └── opay-cm-linux-to-storage (Connection Monitor)
│     │
│     └── Backup & Recovery
│           ├── opay-rsv-prod (Recovery Services Vault, GRS)
│           │     ├── Backup: opay-vm-linux01, opay-vm-win01
│           │     └── ASR: opay-vm-linux01 → Brazil South
│           └── opay-abv-prod (Backup Vault, Azure Blobs)
│
└── opay-rg-dr (Brazil South) [Lock: ReadOnly]
      Tags: CostCenter=payments, Env=dr
      ├── opay-vnet-dr (10.20.0.0/16) ←peering→ opay-vnet-prod
      │     └── opay-subnet-dr (10.20.1.0/24)
      └── opaydrSUFIXO (Storage LRS, object replication dest.)
            └── opay-docs-replica (container replicado de opay-docs)

DNS
├── Public Zone: originpay.com.br
│     ├── A: pagamentos → opay-pip-linux01
│     └── CNAME: www → pagamentos.originpay.com.br
└── Private Zone: originpay.internal (linked: opay-vnet-prod)
      ├── A: linux01 → 10.10.1.x
      └── A: win01 → 10.10.2.x

Fim do Laboratório — Projeto Origem

Ao concluir todas as 17 etapas e os testes de validação global, o ambiente OriginPay reflete uma infraestrutura Azure de produção completa cobrindo todos os domínios do exame AZ-104: identidade, storage, compute, redes, monitoramento e recuperação.

Ambiente Cumulativo de Implantação Real​

Narrativa Central​

Ambiente Inicial​

Recursos Necessários​

Credenciais de Simulação​

Ferramentas de Cliente​

Diagrama de Topologia Inicial​

Etapa 1 — Gerenciar Usuários e Grupos no 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 (RBAC)​

Contexto da Etapa​

Diagrama da Etapa​

Ambiente de Execução​

Tarefas​

Valor Capturado​

Critérios de Validação​

Etapa 3 — Governança: Policy, Locks, Tags e Management Groups​

Contexto da Etapa​

Diagrama da Etapa​

Ambiente de Execução​

Tarefas​

Valor Capturado​

Critérios de Validação​

Etapa 4 — Gerenciar Subscriptions e Custos​

Contexto da Etapa​

Ambiente de Execução​

Tarefas​

Valor Capturado​

Critérios de Validação​

Etapa 5 — Configurar Acesso ao Storage​

Contexto da Etapa​

Diagrama da Etapa​

Ambiente de Execução​

Tarefas​

Valor Capturado​

Critérios de Validação​

Etapa 6 — Configurar e Gerenciar Storage Accounts​

Contexto da Etapa​

Ambiente de Execução​

Tarefas​

Valor Capturado​

Critérios de Validação​

Etapa 7 — Configurar Azure Files e Azure Blob Storage​

Contexto da Etapa​

Ambiente de Execução​

Tarefas​

Valor Capturado​

Critérios de Validação​

Etapa 8 — Deploy de Recursos com ARM Templates e Bicep​

Contexto da Etapa​

Ambiente de Execução​

Tarefas​

Valor Capturado​

Critérios de Validação​

Etapa 9 — 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 10 — Configurar Redes Virtuais no Azure​

Contexto da Etapa​

Diagrama da Etapa​

Ambiente de Execução​

Tarefas​

Valor Capturado​

Critérios de Validação​

Etapa 11 — Acesso Seguro a Redes Virtuais​

Contexto da Etapa​

Diagrama da Etapa​

Ambiente de Execução​

Tarefas​

Valor Capturado​

Critérios de Validação​

Etapa 12 — DNS, Load Balancer e Troubleshooting de Rede​

Ambiente Cumulativo de Implantação Real

Narrativa Central

Ambiente Inicial

Recursos Necessários

Credenciais de Simulação

Ferramentas de Cliente

Diagrama de Topologia Inicial

Etapa 1 — Gerenciar Usuários e Grupos no 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 (RBAC)

Contexto da Etapa

Diagrama da Etapa

Ambiente de Execução

Tarefas

Valor Capturado

Critérios de Validação

Etapa 3 — Governança: Policy, Locks, Tags e Management Groups

Contexto da Etapa

Diagrama da Etapa

Ambiente de Execução

Tarefas

Valor Capturado

Critérios de Validação

Etapa 4 — Gerenciar Subscriptions e Custos

Contexto da Etapa

Ambiente de Execução

Tarefas

Valor Capturado

Critérios de Validação

Etapa 5 — Configurar Acesso ao Storage

Contexto da Etapa

Diagrama da Etapa

Ambiente de Execução

Tarefas

Valor Capturado

Critérios de Validação

Etapa 6 — Configurar e Gerenciar Storage Accounts

Contexto da Etapa

Ambiente de Execução

Tarefas

Valor Capturado

Critérios de Validação

Etapa 7 — Configurar Azure Files e Azure Blob Storage

Contexto da Etapa

Ambiente de Execução

Tarefas

Valor Capturado

Critérios de Validação

Etapa 8 — Deploy de Recursos com ARM Templates e Bicep

Contexto da Etapa

Ambiente de Execução

Tarefas

Valor Capturado

Critérios de Validação

Etapa 9 — 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 10 — Configurar Redes Virtuais no Azure

Contexto da Etapa

Diagrama da Etapa

Ambiente de Execução

Tarefas

Valor Capturado

Critérios de Validação

Etapa 11 — Acesso Seguro a Redes Virtuais

Contexto da Etapa

Diagrama da Etapa

Ambiente de Execução

Tarefas

Valor Capturado

Critérios de Validação

Etapa 12 — DNS, Load Balancer e Troubleshooting de Rede