[AZ-104] Grand Labs - NovaTech Solutions

Ambiente Cumulativo de Implantação Real

Narrativa Central

Empresa: NovaTech Solutions | Setor: Consultoria e desenvolvimento de software para o setor financeiro | Sede: Belo Horizonte, Brasil

A NovaTech Solutions é uma consultoria brasileira de software com sede em Belo Horizonte que atende bancos regionais e corretoras de valores. Com o crescimento acelerado dos últimos dois anos, a empresa decidiu migrar toda a sua infraestrutura para o Azure, saindo de um ambiente on-premises legado e de um provedor de nuvem menor.

A migração exige a implantação de uma plataforma completa: identidade e governança centralizadas, armazenamento seguro para dados financeiros, computação escalável para as aplicações dos clientes, rede isolada e monitorada, e um plano de continuidade de negócios robusto. Cada etapa deste laboratório representa uma fase real dessa migração, executada pela equipe de engenharia de nuvem da NovaTech.

Os recursos serão distribuídos entre as regiões East US e Brazil South, respeitando os requisitos de residência de dados dos clientes financeiros. O prefixo de todos os recursos é nvt. Capture os IDs, IPs e nomes de objetos produzidos em cada etapa — eles serão exigidos nas etapas seguintes.

Pré-requisitos

Instale antes de começar

Valide todas as ferramentas abaixo antes de iniciar a Etapa 1.

Ferramenta	Versão Mínima	Necessária nas Etapas	Verificação
Azure CLI	2.50+	Todas	`az --version`
Bicep CLI	Qualquer	31–32	`az bicep install && az bicep version`
AzCopy	v10+	23, 30	`azcopy --version`
Docker Desktop	24+	38–39	`docker --version`
curl	Qualquer	40	`curl --version`

Estimativa de custo e tempo

💰 Custo estimado para execução completa: USD 15–30
⏱️ Tempo estimado total: 12–16 horas distribuídas em múltiplas sessões
🔋 Desligue e desaloque VMs, VMSS e o Bastion ao encerrar cada sessão
📍 Região principal: East US | Região de DR: Brazil South

Recurso	Custo estimado	Observação
Azure Bastion (Standard)	~USD 0,19/h	Desligue após uso
VM Standard_B2s	~USD 0,08/h	Desaloque entre sessões
VMSS (2x B1s)	~USD 0,04/h	Reduza para 0 instâncias entre sessões
App Service P1v3	~USD 0,16/h	Scale down para F1 entre sessões
Site Recovery	~USD 0,16/VM/h	Desabilite após Etapa 68
Load Balancer Standard	~USD 0,008/h	Custo baixo, pode manter

Convenção de Nomenclatura

Tipo de Recurso	Exemplo
Resource group	nvt-rg-main
Rede virtual	nvt-vnet-main
VM	nvt-vm-app01
Storage account	nvtprodsa<sufixo> (sem hífens, máx 24 chars)
NSG	nvt-nsg-compute
Key Vault	nvt-kv-prod
Container Registry	nvtregistry<sufixo>

Sufixos únicos

Recursos como storage accounts e container registries exigem nomes globalmente únicos. Use um sufixo de 4–6 caracteres (ex: suas iniciais + número) e mantenha o mesmo sufixo ao longo de todo o laboratório.

Índice por Domínio do Exame

Domínio	Etapas
Domínio 1 — Identidade e Governança	1–13
Domínio 2 — Storage	14–30
Domínio 3 — Infraestrutura como Código	31–32
Domínio 4 — Compute e Contêineres	33–41
Domínio 5 — App Service	42–47
Domínio 6 — Redes	48–58
Domínio 7 — Monitoramento	59–64
Domínio 8 — Backup e DR	65–69

Domínio 1 — Identidade e Governança

Etapa 1 — Criar usuários e grupos no Microsoft Entra ID

Contexto: A NovaTech precisa estruturar as identidades da equipe antes de qualquer recurso Azure ser provisionado. O time de engenharia de nuvem e os administradores financeiros precisam de identidades separadas, organizadas em grupos que reflitam suas responsabilidades. Esta é a fundação de toda a governança que virá nas etapas seguintes.

Tarefas:

[CLI] Crie dois usuários membros no Microsoft Entra ID usando az ad user create:

Display Name	User Principal Name	Habilitado
NVT Cloud Engineer	nvt-cloud-eng@<seu-dominio>.onmicrosoft.com	true
NVT Finance Admin	nvt-finance-admin@<seu-dominio>.onmicrosoft.com	true

Para cada usuário, defina senha temporária e accountEnabled: true.

[CLI] Crie dois grupos de segurança usando az ad group create:

Nome	Tipo	Membership Type
nvt-cloud-engineers	Security	Assigned
nvt-finance-admins	Security	Assigned

[CLI] Adicione cada usuário ao grupo correspondente usando az ad group member add:

nvt-cloud-eng → nvt-cloud-engineers
nvt-finance-admin → nvt-finance-admins

[CLI] Capture e armazene o Object ID de cada grupo usando az ad group show --query id. Esses valores serão usados nas atribuições de roles nas etapas seguintes.

Critérios de Validação:

# Deve retornar 2 objetos com Enabled = true:
az ad user list --filter "startswith(displayName,'NVT')" \
  --query "[].{Name:displayName,UPN:userPrincipalName,Enabled:accountEnabled}"

# Cada comando deve retornar um array com um único nome:
az ad group member list --group nvt-cloud-engineers --query "[].displayName"
az ad group member list --group nvt-finance-admins --query "[].displayName"

Etapa 2 — Gerenciar propriedades de usuários e grupos

Contexto: Com as identidades criadas, a equipe de RH solicitou que os perfis dos usuários reflitam a estrutura organizacional: departamento, cargo e localização de trabalho. Além disso, o grupo de administradores financeiros precisa de uma descrição clara para fins de conformidade regulatória.

Tarefas:

[CLI] Atualize as propriedades de cada usuário usando az ad user update:

Usuário	jobTitle	department	usageLocation
nvt-cloud-eng	Cloud Engineer	Technology	BR
nvt-finance-admin	Finance Administrator	Finance	BR

[CLI] Atualize a descrição do grupo nvt-finance-admins para Grupo de administradores financeiros com acesso a recursos de dados regulados usando az ad group update --description.

Critérios de Validação:

# Deve retornar Title = Cloud Engineer, Dept = Technology, Location = BR:
az ad user show --id nvt-cloud-eng@<dominio> \
  --query "{Title:jobTitle,Dept:department,Location:usageLocation}"

# Deve retornar a string de descrição definida:
az ad group show --group nvt-finance-admins --query "description"

Etapa 3 — Gerenciar licenças no Microsoft Entra ID

Contexto: A NovaTech adquiriu licenças Microsoft 365 para os membros da equipe. O usuário nvt-cloud-eng precisa de uma licença atribuída para acessar os serviços associados. A usageLocation definida na Etapa 2 é pré-requisito obrigatório para essa atribuição.

Tarefas:

[Portal] Navegue até: Microsoft Entra ID → Users → nvt-cloud-eng → Licenses → Assignments. Atribua uma licença disponível no tenant (ex: Microsoft Entra ID P2 ou Microsoft 365 trial). Confirme que o campo usageLocation está preenchido antes de salvar.

[CLI] Verifique as licenças atribuídas ao usuário nvt-cloud-eng:

az ad user show --id nvt-cloud-eng@<dominio> --query "assignedLicenses"

Critérios de Validação:

# Deve retornar array com pelo menos 1 objeto com skuId não nulo:
az ad user show --id nvt-cloud-eng@<dominio> --query "assignedLicenses"

Etapa 4 — Gerenciar usuários externos

Contexto: Um auditor externo de uma firma regulatória precisa de acesso temporário ao ambiente Azure da NovaTech para revisar os controles de conformidade. A política de segurança exige que usuários externos sejam tratados como convidados com acesso limitado, nunca como membros do tenant.

Tarefas:

[CLI] Envie um convite de colaboração para um endereço de e-mail externo usando az ad invitation create:

Parâmetro	Valor
--invited-user-display-name	NVT External Auditor
--invite-redirect-url	https://portal.azure.com
--invited-user-email-address	<e-mail externo de teste>

[CLI] Liste os usuários convidados no tenant e capture o Object ID do auditor externo:

az ad user list --filter "userType eq 'Guest'" \
  --query "[?displayName=='NVT External Auditor'].id"

Critérios de Validação:

# Deve retornar ao menos 1 objeto com Type = Guest e Name = NVT External Auditor:
az ad user list --filter "userType eq 'Guest'" \
  --query "[].{Name:displayName,Type:userType}"

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

Contexto: O helpdesk da NovaTech está sobrecarregado com solicitações de redefinição de senha. A liderança decidiu habilitar o SSPR para o grupo nvt-cloud-engineers, permitindo que os engenheiros redefinam suas próprias senhas sem intervenção do suporte.

Tarefas:

[Portal] Habilite o SSPR para o grupo nvt-cloud-engineers em: Microsoft Entra ID → Protection → Password reset → Properties. Altere o escopo de None para Selected e selecione o grupo.

[Portal] Configure os métodos de autenticação em: Microsoft Entra ID → Protection → Password reset → Authentication methods

Parâmetro	Valor
Number of methods required to reset	1
Methods available	Email, Mobile phone

[Portal] Configure o registro em: Microsoft Entra ID → Protection → Password reset → Registration

Parâmetro	Valor
Require users to register when signing in	Yes
Days before users are asked to re-confirm	180

Critérios de Validação:

dica

Password reset → Properties: escopo exibe Selected com nvt-cloud-engineers listado.
Password reset → Authentication methods: número de métodos = 1 e pelo menos dois métodos habilitados.

Etapa 6 — Gerenciar roles integradas do Azure

Contexto: Com as identidades organizadas, é hora de conceder acesso aos recursos Azure. O grupo nvt-cloud-engineers precisará de acesso para criar e gerenciar recursos, enquanto o grupo nvt-finance-admins deve apenas visualizar os custos. As atribuições devem seguir o princípio de menor privilégio.

Tarefas:

[CLI] Crie o resource group principal nvt-rg-main na região East US usando az group create. Este grupo será o contêiner principal de todos os recursos do laboratório.

[CLI] Atribua o role Contributor ao grupo nvt-cloud-engineers no escopo do resource group nvt-rg-main usando az role assignment create. Use o Object ID do grupo capturado na Etapa 1.

[CLI] Atribua o role Cost Management Reader ao grupo nvt-finance-admins no escopo da subscription atual. Capture o subscription ID com az account show --query id.

Critérios de Validação:

# Deve retornar objeto com Role = Contributor:
az role assignment list --resource-group nvt-rg-main \
  --query "[?principalName=='nvt-cloud-engineers'].{Role:roleDefinitionName,Scope:scope}"

# Deve retornar objeto com Role = Cost Management Reader:
az role assignment list --scope /subscriptions/<id> \
  --query "[?contains(roleDefinitionName,'Cost Management')].{Role:roleDefinitionName}"

Etapa 7 — Atribuir roles em diferentes escopos e interpretar atribuições

Contexto: A NovaTech possui um segundo ambiente de staging para testes das aplicações financeiras. É necessário criar um resource group de staging e atribuir permissões específicas apenas para esse ambiente, demonstrando como o Azure RBAC funciona em múltiplos escopos.

Tarefas:

[CLI] Crie o resource group nvt-rg-staging na região Brazil South usando az group create.

[CLI] Atribua o role Reader ao usuário nvt-cloud-eng com escopo apenas no resource group nvt-rg-staging usando az role assignment create com o Object ID do usuário.

[CLI] Liste todas as atribuições de role efetivas para o usuário nvt-cloud-eng e identifique a diferença de escopo entre os dois resource groups:

az role assignment list --assignee <object-id> --all

Critérios de Validação:

# Deve retornar ao menos 2 entradas com escopos distintos:
az role assignment list --assignee <nvt-cloud-eng-object-id> --all \
  --query "[].{Role:roleDefinitionName,Scope:scope}"

Etapa 8 — Implementar e gerenciar Azure Policy

Contexto: A equipe de compliance identificou que recursos sem tags estão sendo criados de forma descontrolada, dificultando a alocação de custos por cliente. Uma política de governança deve exigir que todos os recursos no resource group de produção tenham a tag CostCenter.

Tarefas:

[CLI] Atribua a Azure Policy built-in Require a tag on resources (ID: 871b6d14-10aa-478d-b590-94f262ecfa99) no escopo do resource group nvt-rg-main usando az policy assignment create:

Parâmetro	Valor
--name	nvt-require-costcenter
--policy	871b6d14-10aa-478d-b590-94f262ecfa99
--scope	Resource ID do nvt-rg-main
--params	`{"tagName": {"value": "CostCenter"}}`

[CLI] Verifique o estado da policy assignment e confirme que enforcementMode está como Default:

az policy assignment show --name "nvt-require-costcenter"

Critérios de Validação:

# Deve retornar EnfMode = Default e Scope contendo nvt-rg-main:
az policy assignment show --name "nvt-require-costcenter" \
  --query "{Name:name,Scope:scope,EnfMode:enforcementMode}"

Etapa 9 — Configurar resource locks

Contexto: O resource group de produção da NovaTech não pode ser excluído acidentalmente. A política de proteção de ativos define que o resource group nvt-rg-main deve ter um lock de exclusão antes que qualquer recurso de produção seja implantado.

Tarefas:

[CLI] Aplique um lock do tipo CanNotDelete no resource group nvt-rg-main usando az lock create:

Parâmetro	Valor
--name	nvt-lock-prod
--resource-group	nvt-rg-main
--lock-type	CanNotDelete
--notes	Protecao de producao NovaTech

[CLI] Tente excluir o resource group nvt-rg-main com az group delete --name nvt-rg-main --yes e observe o erro retornado. Não confirme a exclusão se ela não for bloqueada automaticamente.

Critérios de Validação:

# Deve retornar Name = nvt-lock-prod, Type = CanNotDelete:
az lock list --resource-group nvt-rg-main \
  --query "[].{Name:name,Type:level}"

# A tentativa de exclusão deve falhar com código ScopeLocked

Etapa 10 — Aplicar e gerenciar tags em recursos

Contexto: A NovaTech precisa rastrear custos por cliente e por ambiente. Todos os recursos do laboratório devem receber tags padronizadas que permitam filtrar relatórios de custo por Environment, CostCenter e Owner.

Tarefas:

[CLI] Aplique as tags abaixo ao resource group nvt-rg-main usando az tag update --operation Merge. Capture o resource ID do RG com az group show --query id:

Tag	Valor
Environment	Production
CostCenter	NVT-CORE
Owner	cloud-team

[CLI] Aplique as tags ao resource group nvt-rg-staging:

Tag	Valor
Environment	Staging
CostCenter	NVT-CORE
Owner	cloud-team

[CLI] Liste todos os resource groups que possuem a tag CostCenter=NVT-CORE:

az group list --tag CostCenter=NVT-CORE

Critérios de Validação:

# Deve retornar 2 objetos, um com Env = Production e outro com Env = Staging:
az group list --tag CostCenter=NVT-CORE \
  --query "[].{Name:name,Env:tags.Environment}"

Etapa 11 — Gerenciar resource groups

Contexto: A NovaTech decidiu criar um terceiro resource group dedicado exclusivamente aos recursos de rede compartilhados entre produção e staging. Recursos existentes precisam ser movidos conforme a reorganização da arquitetura avança.

Tarefas:

[CLI] Crie o resource group nvt-rg-network na região East US com as tags Environment: Shared e CostCenter: NVT-CORE usando az group create --tags.

[CLI] Execute o comando de validação de movimentação (dry run) sem efetivar a movimentação real para verificar a viabilidade da operação:

az resource invoke-action --action validateMoveResources

Critérios de Validação:

# Deve retornar Cost = NVT-CORE, Env = Shared, Location = eastus:
az group show --name nvt-rg-network \
  --query "{Name:name,Env:tags.Environment,Cost:tags.CostCenter,Location:location}"

Etapa 12 — Gerenciar subscriptions e management groups

Contexto: A NovaTech antecipa crescimento e precisará organizar futuras subscriptions por unidade de negócio. O time de arquitetura deve configurar management groups para preparar essa estrutura de governança hierárquica antes que novas subscriptions sejam adicionadas.

Tarefas:

[CLI] Crie o management group nvt-mg-root com display name NovaTech Root usando az account management-group create.

[CLI] Crie o management group filho nvt-mg-technology com display name NovaTech Technology subordinado ao nvt-mg-root usando o parâmetro --parent nvt-mg-root.

[CLI] Exiba a hierarquia de management groups para confirmar a estrutura pai-filho:

az account management-group show --name nvt-mg-root --expand --recurse

Critérios de Validação:

# Deve retornar Children = ["nvt-mg-technology"], Parent = nvt-mg-root:
az account management-group show --name nvt-mg-root --expand --recurse \
  --query "{Parent:name,Children:children[].name}"

Etapa 13 — Gerenciar custos com alertas, budgets e Azure Advisor

Contexto: O CFO da NovaTech definiu um orçamento mensal máximo para a subscription de laboratório. A equipe deve configurar um budget com alertas automáticos para evitar gastos inesperados.

Tarefas:

[Portal] Crie o budget em: Cost Management + Billing → Budgets

Parâmetro	Valor
Name	nvt-monthly-budget
Reset period	Monthly
Amount	100 USD
Alert condition	Actual cost at 80%
Alert email	nvt-finance-admin@<dominio>.onmicrosoft.com

[Portal] Registre ao menos uma recomendação de custo em: Azure Advisor → Cost. Se não houver recomendações, registre que a aba exibe No recommendations.

Critérios de Validação:

dica

Budget nvt-monthly-budget aparece na lista com status Active e valor 100 USD.
Ao menos um alerta configurado com threshold 80 e tipo Actual.

Domínio 2 — Storage

Etapa 14 — Configurar firewalls e virtual networks do Azure Storage

Contexto: A NovaTech vai armazenar documentos financeiros sensíveis no Azure Storage. Por política de segurança, o storage account de produção deve rejeitar conexões públicas por padrão e aceitar apenas conexões originadas da rede virtual da empresa.

Tarefas:

[CLI] Crie a VNet nvt-vnet-main no resource group nvt-rg-network, região East US, com address space 10.10.0.0/16 usando az network vnet create.

[CLI] Crie a subnet nvt-snet-storage com prefix 10.10.1.0/24 dentro da VNet. Habilite o service endpoint para Microsoft.Storage com o parâmetro --service-endpoints Microsoft.Storage.

[CLI] Crie o storage account nvtprodsa<sufixo> no resource group nvt-rg-main, região East US, SKU Standard_LRS, com --default-action Deny e --bypass AzureServices usando az storage account create.

[CLI] Adicione uma regra de VNet no storage account para permitir tráfego da subnet nvt-snet-storage usando az storage account network-rule add --vnet-name nvt-vnet-main --subnet nvt-snet-storage.

Critérios de Validação:

# Deve retornar "Deny":
az storage account show --name <nome-sa> --resource-group nvt-rg-main \
  --query "networkRuleSet.defaultAction"

# Deve retornar array com o Resource ID da subnet:
az storage account network-rule list --account-name <nome-sa> --resource-group nvt-rg-main \
  --query "virtualNetworkRules[].virtualNetworkResourceId"

Etapa 15 — Criar e usar SAS tokens

Contexto: A NovaTech precisa compartilhar relatórios financeiros com parceiros externos sem expor as chaves de acesso do storage account. Os parceiros devem ter acesso de leitura a um container específico por um período limitado de 24 horas.

Tarefas:

[CLI] Crie o container nvt-reports no storage account nvtprodsa<sufixo> com acesso private usando az storage container create --public-access off.

[CLI] Gere um SAS token de nível de conta com permissões rl (read, list) para o serviço b (blob), válido por 24 horas, usando az storage account generate-sas:

Parâmetro	Valor
--permissions	rl
--services	b
--resource-types	co
--expiry	data/hora ISO 8601 em +24h

[CLI] Use o SAS token gerado para listar o conteúdo do container nvt-reports via az storage blob list --sas-token. Não use a account key.

Critérios de Validação:

# Deve retornar sem erro de autenticação (container vazio é aceitável):
az storage blob list --container-name nvt-reports \
  --account-name <nome-sa> --sas-token "<token>" --output table

Etapa 16 — Configurar stored access policies

Contexto: O time de segurança da NovaTech quer centralizar o controle dos SAS tokens. Em vez de tokens ad hoc, os acessos ao container nvt-reports devem ser governados por stored access policies, permitindo revogação imediata quando necessário.

Tarefas:

[CLI] Crie a stored access policy nvt-read-policy no container nvt-reports com permissões rl e expiração em 7 dias usando az storage container policy create:

Parâmetro	Valor
--name	nvt-read-policy
--container-name	nvt-reports
--permissions	rl
--expiry	data/hora ISO 8601 em +7d

[CLI] Gere um SAS token associado à stored access policy usando az storage container generate-sas --policy-name nvt-read-policy.

Critérios de Validação:

# Deve retornar objeto com nvt-read-policy listada e permissions = rl:
az storage container policy list \
  --container-name nvt-reports --account-name <nome-sa>

Etapa 17 — Gerenciar access keys

Contexto: A política de segurança da NovaTech exige rotação periódica das access keys do storage account de produção. O time deve realizar a rotação da key secundária e verificar que o acesso continua funcionando com a key primária.

Tarefas:

[CLI] Liste as access keys do storage account de produção e registre o valor atual de key2:

az storage account keys list --account-name <nome-sa> \
  --query "[].{KeyName:keyName,Value:value}"

[CLI] Regenere a key2 do storage account usando az storage account keys renew --key key2.

[CLI] Liste as keys novamente e compare o novo valor de key2 com o registrado antes da rotação.

Critérios de Validação:

dica

Após a regeneração, o valor de key2 deve ser diferente do valor registrado antes da rotação. Execute az storage account keys list antes e depois e compare os valores de key2.

Etapa 18 — Configurar acesso baseado em identidade para Azure Files

Contexto: A NovaTech vai usar Azure Files para compartilhar arquivos entre os servidores de aplicação. O acesso deve ser controlado via Microsoft Entra Kerberos, sem depender de access keys.

Tarefas:

[CLI] Habilite a autenticação Microsoft Entra Kerberos no storage account de produção para Azure Files:

az storage account update --enable-files-aadkerb true \
  --name <nome-sa> --resource-group nvt-rg-main

[Portal] Confirme a configuração em: Storage accounts → <nome-sa> → File shares → Active Directory. O método de autenticação deve exibir Microsoft Entra Kerberos como Configured.

Critérios de Validação:

# Deve retornar directoryServiceOptions = AADKERB:
az storage account show --name <nome-sa> \
  --query "azureFilesIdentityBasedAuthentication"

Etapa 19 — Criar e configurar storage accounts

Contexto: Além do storage account de produção, a NovaTech precisa de um storage account separado para o ambiente de staging em Brazil South. Este account deve usar redundância geográfica para garantir durabilidade dos dados dos clientes brasileiros.

Tarefas:

[CLI] Crie o storage account nvtstagingsa<sufixo> no resource group nvt-rg-staging, região Brazil South, com os parâmetros:

Parâmetro	Valor
--sku	Standard_GRS
--kind	StorageV2
--location	brazilsouth
--access-tier	Cool
--https-only	true

Critérios de Validação:

# Deve retornar HTTPS = true, Location = brazilsouth, SKU = Standard_GRS, Tier = Cool:
az storage account show --name <nome-staging-sa> \
  --query "{SKU:sku.name,Tier:accessTier,HTTPS:enableHttpsTrafficOnly,Location:primaryLocation}"

Etapa 20 — Configurar redundância do Azure Storage

Contexto: O storage account de produção foi criado com LRS, mas o regulador financeiro exige que os dados críticos tenham pelo menos replicação zona-redundante. O time deve alterar a redundância.

Tarefas:

[CLI] Altere a redundância do storage account de produção de Standard_LRS para Standard_ZRS usando az storage account update --sku Standard_ZRS.

[CLI] Confirme a mudança de SKU:

az storage account show --name <nome-sa> --query "sku.name"

Critérios de Validação:

# Deve retornar "Standard_ZRS":
az storage account show --name <nome-sa> --query "sku.name"

Etapa 21 — Configurar object replication

Contexto: Para atender ao requisito de continuidade de negócios dos clientes financeiros, os blobs do container nvt-reports em produção (East US) devem ser replicados automaticamente para o storage account de staging em Brazil South.

Tarefas:

[CLI] Habilite o blob versioning nos dois storage accounts — pré-requisito obrigatório para object replication. Use az storage account blob-service-properties update --enable-versioning true para cada um.

[CLI] Crie o container de destino nvt-reports-replica no storage account de staging usando az storage container create.

[CLI] Crie a object replication policy mapeando nvt-reports (source) para nvt-reports-replica (destination):

az storage account or-policy create \
  --source-account <prod-sa> \
  --destination-account <staging-sa> \
  --source-container nvt-reports \
  --destination-container nvt-reports-replica

Critérios de Validação:

# Deve retornar ao menos 1 objeto com PolicyId preenchido:
az storage account or-policy list --account-name <prod-sa> \
  --query "[].{PolicyId:policyId,Dest:destinationAccount}"

Etapa 22 — Configurar criptografia do storage account

Contexto: A auditoria de segurança exige que os dados do storage account de produção sejam criptografados com chave gerenciada pelo cliente (CMK) armazenada em um Azure Key Vault dedicado.

Tarefas:

[CLI] Crie o Azure Key Vault nvt-kv-prod no resource group nvt-rg-main, região East US, com --enable-soft-delete true e --enable-purge-protection true usando az keyvault create.

[CLI] Habilite a managed identity system-assigned no storage account de produção:

az storage account update --name <nome-sa> --assign-identity

[CLI] Conceda à managed identity do storage account a permissão Key Vault Crypto Service Encryption User no Key Vault. O principal ID é o identity.principalId do storage account.

[CLI] Crie a chave nvt-storage-key no Key Vault e configure o storage account para usar CMK:

az keyvault key create --name nvt-storage-key --vault-name nvt-kv-prod --kty RSA --size 2048

az storage account update --name <nome-sa> \
  --encryption-key-source Microsoft.Keyvault \
  --encryption-key-vault <vault-uri> \
  --encryption-key-name nvt-storage-key

Critérios de Validação:

# Deve retornar "Microsoft.Keyvault":
az storage account show --name <nome-sa> --query "encryption.keySource"

Etapa 23 — Gerenciar dados com Azure Storage Explorer e AzCopy

Contexto: A equipe de TI precisa fazer upload de um conjunto de arquivos de relatório para o container nvt-reports em produção usando AzCopy, que é a ferramenta padrão para transferências em lote na empresa.

Pré-requisito

AzCopy v10+ instalado localmente. Verifique com: azcopy --version

Tarefas:

[CLI] Crie um arquivo de teste local:

echo "Relatorio financeiro NovaTech - $(date)" > nvt-report-sample.txt

[CLI] Autentique o AzCopy com Microsoft Entra ID:

azcopy login

[CLI] Faça upload do arquivo para o container nvt-reports usando autenticação via token Microsoft Entra (sem SAS, sem access key):

azcopy copy nvt-report-sample.txt \
  "https://<nome-sa>.blob.core.windows.net/nvt-reports/"

Critérios de Validação:

# Deve retornar objeto JSON com name = nvt-report-sample.txt sem erro:
az storage blob show --name nvt-report-sample.txt \
  --container-name nvt-reports \
  --account-name <nome-sa> --auth-mode login

Contexto: Os servidores de aplicação da NovaTech precisam de um compartilhamento de arquivos SMB para armazenar arquivos de configuração compartilhados.

Tarefas:

[CLI] Crie o file share nvt-appconfig no storage account de produção com quota de 100 GiB usando az storage share-rm create:

Parâmetro	Valor
--name	nvt-appconfig
--quota	100
--storage-account	<nome-sa>
--resource-group	nvt-rg-main

[CLI] Crie o diretório configs dentro do file share usando az storage directory create --share-name nvt-appconfig --name configs.

Critérios de Validação:

# Deve retornar Name = nvt-appconfig, Quota = 100:
az storage share-rm show --name nvt-appconfig \
  --storage-account <nome-sa> --resource-group nvt-rg-main \
  --query "{Name:name,Quota:shareQuota}"

Etapa 25 — Criar e configurar containers no Azure Blob Storage

Contexto: Além dos relatórios financeiros, a NovaTech armazenará logs de aplicação e artefatos de build no Azure Blob Storage. Cada tipo de dado exige um container separado com configurações de acesso distintas.

Tarefas:

[CLI] Crie o container nvt-applogs no storage account de produção com acesso private:

az storage container create --name nvt-applogs \
  --account-name <nome-sa> --public-access off

[CLI] Crie o container nvt-artifacts com acesso blob (leitura anônima de blobs apenas):

az storage container create --name nvt-artifacts \
  --account-name <nome-sa> --public-access blob

Critérios de Validação:

# Deve retornar nvt-applogs com null e nvt-artifacts com "blob":
az storage container list --account-name <nome-sa> \
  --query "[?name=='nvt-applogs' || name=='nvt-artifacts'].{Name:name,Access:properties.publicAccess}"

Etapa 26 — Configurar storage tiers

Contexto: Os logs de aplicação com mais de 30 dias raramente são acessados e devem ser movidos para camadas de custo menor. O blob nvt-report-sample.txt criado na Etapa 23 será movido manualmente para a camada Cool como validação do processo.

Tarefas:

[CLI] Altere o access tier do blob nvt-report-sample.txt no container nvt-reports para Cool:

az storage blob set-tier \
  --name nvt-report-sample.txt \
  --container-name nvt-reports \
  --account-name <nome-sa> \
  --tier Cool

[CLI] Confirme o tier atual do blob:

az storage blob show --name nvt-report-sample.txt \
  --container-name nvt-reports --account-name <nome-sa> \
  --query "properties.blobTier"

Critérios de Validação:

# Deve retornar "Cool":
az storage blob show --name nvt-report-sample.txt \
  --container-name nvt-reports --account-name <nome-sa> \
  --query "properties.blobTier"

Etapa 27 — Configurar soft delete para blobs e containers

Contexto: Um incidente recente em outro projeto da NovaTech resultou na exclusão acidental de blobs críticos. O regulador financeiro exige proteção contra exclusão acidental com retenção mínima de 7 dias.

Tarefas:

[CLI] Habilite soft delete para blobs no storage account de produção com retenção de 7 dias:

az storage account blob-service-properties update \
  --account-name <nome-sa> \
  --enable-delete-retention true \
  --delete-retention-days 7

[CLI] Habilite soft delete para containers com retenção de 7 dias:

az storage account blob-service-properties update \
  --account-name <nome-sa> \
  --enable-container-delete-retention true \
  --container-delete-retention-days 7

Critérios de Validação:

# Ambos devem retornar enabled = true e days = 7:
az storage account blob-service-properties show --account-name <nome-sa> \
  --query "{BlobDelete:deleteRetentionPolicy,ContainerDelete:containerDeleteRetentionPolicy}"

Etapa 28 — Configurar snapshots e soft delete para Azure Files

Contexto: O file share nvt-appconfig contém arquivos de configuração críticos que devem ser protegidos com snapshots e soft delete, garantindo a capacidade de recuperação de versões anteriores.

Tarefas:

[CLI] Habilite soft delete para o file share nvt-appconfig com retenção de 7 dias:

az storage account file-service-properties update \
  --account-name <nome-sa> \
  --enable-delete-retention true \
  --delete-retention-days 7

[CLI] Crie um snapshot manual do file share nvt-appconfig usando az storage share snapshot --name nvt-appconfig --account-name <nome-sa>.

Critérios de Validação:

# Deve retornar enabled = true, days = 7:
az storage account file-service-properties show --account-name <nome-sa> \
  --query "shareDeleteRetentionPolicy"

# Deve retornar array com ao menos 1 timestamp de snapshot:
az storage share list --account-name <nome-sa> \
  --include-snapshots \
  --query "[?name=='nvt-appconfig' && snapshot!=null].snapshot"

Etapa 29 — Configurar blob lifecycle management

Contexto: Para controlar custos de armazenamento automaticamente, a NovaTech define uma política de ciclo de vida: blobs no container nvt-applogs devem ser movidos para Cool após 30 dias, para Archive após 90 dias e excluídos após 365 dias.

Tarefas:

[CLI] Crie a lifecycle management policy no storage account de produção. O parâmetro --policy aceita um JSON com a estrutura de rules:

{
  "rules": [
    {
      "name": "nvt-logs-lifecycle",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["nvt-applogs/"]
        },
        "actions": {
          "baseBlob": {
            "tierToCool": { "daysAfterModificationGreaterThan": 30 },
            "tierToArchive": { "daysAfterModificationGreaterThan": 90 },
            "delete": { "daysAfterModificationGreaterThan": 365 }
          }
        }
      }
    }
  ]
}

Use az storage account management-policy create com --policy @nvt-lifecycle-policy.json.

Critérios de Validação:

# Deve retornar ["nvt-logs-lifecycle"]:
az storage account management-policy show \
  --account-name <nome-sa> --resource-group nvt-rg-main \
  --query "policy.rules[?name=='nvt-logs-lifecycle'].name"

Etapa 30 — Configurar blob versioning

Contexto: O versionamento de blobs foi habilitado na Etapa 21 como pré-requisito para object replication. Nesta etapa, o time valida o comportamento fazendo uma segunda versão do blob nvt-report-sample.txt e confirmando que ambas as versões coexistem.

Tarefas:

[CLI] Modifique o conteúdo do arquivo local e faça upload novamente para o container nvt-reports, sobrescrevendo o blob existente com --overwrite true via az storage blob upload ou azcopy copy.

[CLI] Liste as versões do blob nvt-report-sample.txt usando o parâmetro --include v:

az storage blob list --container-name nvt-reports \
  --account-name <nome-sa> --include v \
  --query "[?name=='nvt-report-sample.txt'].{Name:name,Version:versionId}" \
  --auth-mode login

Critérios de Validação:

# Deve retornar 2 ou mais objetos com o mesmo nome e versionId distintos:
az storage blob list --container-name nvt-reports \
  --account-name <nome-sa> --include v \
  --query "[?name=='nvt-report-sample.txt'].{Name:name,Version:versionId}" \
  --auth-mode login

Domínio 3 — Infraestrutura como Código (IaC)

Pré-requisito

az bicep install && az bicep version — Instale o Bicep CLI antes de iniciar esta seção.

Etapa 31 — Interpretar e modificar ARM templates e arquivos Bicep

Contexto: A NovaTech adota IaC como padrão para todos os recursos de produção. O time vai exportar o resource group de produção como template ARM, convertê-lo para Bicep e modificá-lo para incluir um novo recurso de Public IP.

Tarefas:

[CLI] Exporte o template ARM do resource group nvt-rg-main:

az group export --name nvt-rg-main --output-file nvt-rg-main-template.json

[CLI] Converta o template ARM para Bicep:

az bicep decompile --file nvt-rg-main-template.json

[IaC] No arquivo Bicep gerado nvt-rg-main-template.bicep, adicione o bloco de recurso abaixo preenchendo os campos indicados:

resource nvtPublicIP 'Microsoft.Network/publicIPAddresses@2023-04-01' = {
  name: // PREENCHER: 'nvt-pip-main'
  location: // PREENCHER: região East US
  sku: {
    name: // PREENCHER: SKU Standard
  }
  properties: {
    publicIPAllocationMethod: // PREENCHER: Static
  }
}

[CLI] Valide a sintaxe do arquivo Bicep modificado:

az bicep build --file nvt-rg-main-template.bicep

Critérios de Validação:

# Deve retornar número maior que 0:
grep -c "^resource " nvt-rg-main-template.bicep

# Deve concluir sem erros de sintaxe:
az bicep build --file nvt-rg-main-template.bicep

Etapa 32 — Fazer deploy de recursos com template Bicep

Contexto: Com o arquivo Bicep validado, o time executa o deploy da Public IP no resource group nvt-rg-main. Este é o primeiro recurso de rede provisionado via IaC, e o IP resultante será usado pela VM nas etapas seguintes.

Tarefas:

[CLI] Faça o deploy do arquivo Bicep no resource group nvt-rg-main no modo Incremental:

az deployment group create \
  --resource-group nvt-rg-main \
  --template-file nvt-rg-main-template.bicep \
  --mode Incremental

[CLI] Capture o endereço IP público alocado após o deploy:

az network public-ip show --name nvt-pip-main \
  --resource-group nvt-rg-main --query "ipAddress"

Critérios de Validação:

# Deve retornar Method = Static, SKU = Standard e IP preenchido:
az network public-ip show --name nvt-pip-main \
  --resource-group nvt-rg-main \
  --query "{IP:ipAddress,Method:publicIPAllocationMethod,SKU:sku.name}"

Domínio 4 — Compute e Contêineres

Etapa 33 — Criar e configurar Virtual Machines

Contexto: A NovaTech vai implantar o primeiro servidor de aplicação Windows no resource group nvt-rg-main. A VM deve estar na VNet criada na Etapa 14, em uma subnet dedicada para compute, usando a Public IP criada na Etapa 32.

Tarefas:

[CLI] Crie a subnet nvt-snet-compute com prefix 10.10.2.0/24 na VNet nvt-vnet-main usando az network vnet subnet create.

[CLI] Crie a VM nvt-vm-app01 no resource group nvt-rg-main, região East US, com os parâmetros:

Parâmetro	Valor
--image	Win2022Datacenter
--size	Standard_B2s
--vnet-name	nvt-vnet-main
--subnet	nvt-snet-compute
--admin-username	nvtadmin
--public-ip-address	nvt-pip-main

Aguarde a conclusão com --no-wait false. Capture o Resource ID da VM ao final.

Critérios de Validação:

# Deve retornar ["VM running"]:
az vm get-instance-view --name nvt-vm-app01 --resource-group nvt-rg-main \
  --query "instanceView.statuses[?starts_with(code,'PowerState/')].displayStatus"

Etapa 34 — Configurar encryption at host para VMs

Contexto: O regulador financeiro exige que todos os discos temporários e caches de disco das VMs de produção sejam criptografados no host. O time deve habilitar essa feature na VM nvt-vm-app01.

Tarefas:

[CLI] Registre o feature provider necessário e aguarde o estado Registered:

az feature register --namespace Microsoft.Compute --name EncryptionAtHost
az feature show --namespace Microsoft.Compute --name EncryptionAtHost

[CLI] Pare (deallocate) a VM nvt-vm-app01:

az vm deallocate --name nvt-vm-app01 --resource-group nvt-rg-main

[CLI] Habilite encryption at host na VM e reinicie-a:

az vm update --name nvt-vm-app01 --resource-group nvt-rg-main \
  --set securityProfile.encryptionAtHost=true

az vm start --name nvt-vm-app01 --resource-group nvt-rg-main

Critérios de Validação:

# Deve retornar true:
az vm show --name nvt-vm-app01 --resource-group nvt-rg-main \
  --query "securityProfile.encryptionAtHost"

Etapa 35 — Gerenciar discos de VMs

Contexto: A VM nvt-vm-app01 precisa de um disco de dados adicional para armazenar os arquivos de aplicação separadamente do disco do sistema operacional, seguindo a prática de segregação de dados da NovaTech.

Tarefas:

[CLI] Crie o managed disk nvt-disk-appdata no resource group nvt-rg-main, região East US, com SKU Premium_LRS e tamanho de 128 GiB usando az disk create.

[CLI] Anexe o disco à VM nvt-vm-app01 usando az vm disk attach --vm-name nvt-vm-app01 --name nvt-disk-appdata.

Critérios de Validação:

# Deve retornar objeto com Name = nvt-disk-appdata e Size = 128:
az vm show --name nvt-vm-app01 --resource-group nvt-rg-main \
  --query "storageProfile.dataDisks[].{Name:name,Size:diskSizeGb,SKU:managedDisk.storageAccountType}"

Etapa 36 — Deploy de VMs em Availability Zones e Availability Sets

Contexto: Para garantir alta disponibilidade do serviço de aplicação, a NovaTech exige que haja uma segunda VM em uma Availability Zone diferente.

Tarefas:

[CLI] Crie a VM nvt-vm-app02 na zona 2 no resource group nvt-rg-main, com a mesma imagem, tamanho e VNet/subnet da nvt-vm-app01, mas sem Public IP:

az vm create --name nvt-vm-app02 \
  --resource-group nvt-rg-main \
  --zone 2 \
  --image Win2022Datacenter \
  --size Standard_B2s \
  --vnet-name nvt-vnet-main \
  --subnet nvt-snet-compute \
  --admin-username nvtadmin \
  --public-ip-address ""

[CLI] Crie o Availability Set nvt-avset-app no resource group nvt-rg-main para documentar a intenção de agrupamento:

az vm availability-set create --name nvt-avset-app \
  --resource-group nvt-rg-main \
  --platform-fault-domain-count 2 \
  --platform-update-domain-count 5

Critérios de Validação:

# Deve retornar ["2"]:
az vm show --name nvt-vm-app02 --resource-group nvt-rg-main --query "zones"

# Deve retornar FaultDomains = 2, UpdateDomains = 5:
az vm availability-set show --name nvt-avset-app --resource-group nvt-rg-main \
  --query "{FaultDomains:platformFaultDomainCount,UpdateDomains:platformUpdateDomainCount}"

Etapa 37 — Deploy e configuração de Azure Virtual Machine Scale Sets

Contexto: O serviço de processamento de transações da NovaTech tem picos de carga previsíveis. Para este componente, um VMSS com autoscaling é mais adequado do que VMs individuais.

Tarefas:

[CLI] Crie o VMSS nvt-vmss-proc no resource group nvt-rg-main, região East US, com os parâmetros:

Parâmetro	Valor
--image	Ubuntu2204
--vm-sku	Standard_B1s
--instance-count	2
--vnet-name	nvt-vnet-main
--subnet	nvt-snet-compute
--upgrade-policy-mode	Automatic

Use az vmss create.

[CLI] Configure a política de autoscaling usando az monitor autoscale create seguido de az monitor autoscale rule create:

Scale-out: CPU média > 70% por 5 min → adicionar 1 instância
Scale-in: CPU média < 30% por 5 min → remover 1 instância
Mínimo: 2, Máximo: 5 instâncias

Critérios de Validação:

# Deve retornar Capacity = 2, UpgradePolicy = Automatic:
az vmss show --name nvt-vmss-proc --resource-group nvt-rg-main \
  --query "{Name:name,Capacity:sku.capacity,UpgradePolicy:upgradePolicy.mode}"

# Deve retornar array com o nome do perfil de autoscale:
az monitor autoscale list --resource-group nvt-rg-main \
  --query "[?contains(targetResourceUri,'nvt-vmss-proc')].name"

Etapa 38 — Criar e gerenciar Azure Container Registry

Contexto: A NovaTech adota containers para as aplicações modernas dos clientes. O time de DevOps precisa de um registry privado para armazenar as imagens Docker das aplicações.

Pré-requisito

Docker Desktop instalado e em execução. Verifique com: docker --version

Tarefas:

[CLI] Crie o Azure Container Registry nvtregistry<sufixo> no resource group nvt-rg-main, região East US, SKU Standard, admin desabilitado:

az acr create --name nvtregistry<sufixo> \
  --resource-group nvt-rg-main \
  --sku Standard \
  --admin-enabled false

[CLI] Faça build de uma imagem simples usando ACR Tasks com um Dockerfile mínimo (FROM mcr.microsoft.com/hello-world:latest):

az acr build --registry <nome-registry> \
  --image nvt-hello:v1 .

[CLI] Liste as imagens disponíveis no registry:

az acr repository list --name <nome-registry>

Critérios de Validação:

# Deve retornar objeto com name = nvt-hello e tags listadas:
az acr repository show --name <nome-registry> --repository nvt-hello

Etapa 39 — Provisionar containers com Azure Container Instances

Contexto: Para um serviço auxiliar de relatórios sem estado, a NovaTech vai usar Azure Container Instances para execuções sob demanda sem gerenciar infraestrutura de cluster.

Tarefas:

[CLI] Habilite o admin user no registry e capture as credenciais:

az acr update --name <nome-registry> --admin-enabled true
az acr credential show --name <nome-registry>

[CLI] Crie o Container Instance nvt-aci-report no resource group nvt-rg-main, região East US, usando a imagem nvt-hello:v1 do registry:

az container create \
  --name nvt-aci-report \
  --resource-group nvt-rg-main \
  --image <login-server>/nvt-hello:v1 \
  --cpu 1 --memory 1 \
  --registry-login-server <login-server> \
  --registry-username <username> \
  --registry-password <password>

Critérios de Validação:

# Deve retornar Status = Succeeded (ou Running) com Image correto:
az container show --name nvt-aci-report --resource-group nvt-rg-main \
  --query "{Status:instanceView.state,Image:containers[0].image}"

Etapa 40 — Provisionar containers com Azure Container Apps

Contexto: Para o serviço de API principal das aplicações financeiras dos clientes, a NovaTech adota Azure Container Apps, que oferece escalonamento automático e gerenciamento de revisões.

Tarefas:

[CLI] Crie o Container Apps Environment nvt-cae-main no resource group nvt-rg-main, região East US:

az containerapp env create --name nvt-cae-main \
  --resource-group nvt-rg-main --location eastus

[CLI] Crie o Container App nvt-ca-api no ambiente nvt-cae-main usando a imagem pública mcr.microsoft.com/azuredocs/containerapps-helloworld:latest:

az containerapp create --name nvt-ca-api \
  --resource-group nvt-rg-main \
  --environment nvt-cae-main \
  --image mcr.microsoft.com/azuredocs/containerapps-helloworld:latest \
  --target-port 80 --ingress external \
  --min-replicas 1 --max-replicas 3

[CLI] Obtenha a URL pública e valide com curl -I https://<fqdn>:

az containerapp show --name nvt-ca-api --resource-group nvt-rg-main \
  --query "properties.configuration.ingress.fqdn"

Critérios de Validação:

# Deve retornar Status = Running com FQDN preenchido:
az containerapp show --name nvt-ca-api --resource-group nvt-rg-main \
  --query "{Status:properties.runningStatus,FQDN:properties.configuration.ingress.fqdn}"

Etapa 41 — Gerenciar sizing e scaling para containers

Contexto: O time de operações identificou que o Container App nvt-ca-api precisa de mais CPU em horários de pico. O perfil de recursos deve ser ajustado e o range de scaling modificado para suportar até 5 réplicas.

Tarefas:

[CLI] Atualize o Container App nvt-ca-api para usar 0.5 CPUs, 1.0Gi de memória por réplica e max-replicas de 5:

az containerapp update --name nvt-ca-api \
  --resource-group nvt-rg-main \
  --cpu 0.5 --memory 1.0Gi \
  --min-replicas 1 --max-replicas 5

[CLI] Atualize o Container Instance nvt-aci-report para usar 2 CPUs (ACI não tem update — recrie com os mesmos parâmetros e --cpu 2).

Critérios de Validação:

# Deve retornar cpu = "0.5" e memory = "1Gi":
az containerapp show --name nvt-ca-api --resource-group nvt-rg-main \
  --query "properties.template.containers[0].resources"

Domínio 5 — App Service

Etapa 42 — Criar e configurar Azure App Service

Contexto: O portal web da NovaTech para acesso dos clientes financeiros será hospedado no Azure App Service. O time deve provisionar o plano, o App Service e um slot de staging com as configurações de produção exigidas pela empresa.

Custo

App Service P1v3 gera ~USD 0,16/h. Reduza para F1 entre sessões se necessário.

Tarefas:

[CLI] Crie o App Service Plan nvt-asp-main no resource group nvt-rg-main, região East US, SKU P1v3, Linux:

az appservice plan create --name nvt-asp-main \
  --resource-group nvt-rg-main \
  --is-linux --sku P1v3

[CLI] Crie o Web App nvt-webapp-portal<sufixo> no plano nvt-asp-main, runtime NODE:18-lts:

az webapp create --name nvt-webapp-portal<sufixo> \
  --resource-group nvt-rg-main \
  --plan nvt-asp-main \
  --runtime "NODE:18-lts"

[CLI] Crie o deployment slot staging:

az webapp deployment slot create \
  --name <nome-webapp> \
  --resource-group nvt-rg-main \
  --slot staging

Critérios de Validação:

# Deve retornar State = Running:
az webapp show --name <nome-webapp> --resource-group nvt-rg-main \
  --query "{State:state,Plan:appServicePlanId}"

# Deve retornar ["staging"]:
az webapp deployment slot list --name <nome-webapp> \
  --resource-group nvt-rg-main --query "[].name"

Etapa 43 — Configurar scaling para App Service Plan

Contexto: O portal web da NovaTech tem picos de tráfego no final do mês, quando os clientes consultam relatórios financeiros. O App Service Plan deve escalar automaticamente com base na utilização de CPU.

Tarefas:

[CLI] Configure autoscaling no App Service Plan nvt-asp-main usando az monitor autoscale create:

Mínimo: 1 instância, Máximo: 3 instâncias, Padrão: 1
Scale-out: CPU > 70% por 10 min → adicionar 1 instância
Scale-in: CPU < 30% por 10 min → remover 1 instância

O parâmetro --resource deve apontar para o Resource ID do App Service Plan.

Critérios de Validação:

# Deve retornar Min = "1" e Max = "3":
az monitor autoscale list --resource-group nvt-rg-main \
  --query "[?contains(targetResourceUri,'nvt-asp-main')].{Name:name,Min:profiles[0].capacity.minimum,Max:profiles[0].capacity.maximum}"

Etapa 44 — Configurar TLS e certificados para App Service

Contexto: O portal web da NovaTech deve ser acessado exclusivamente via HTTPS. O time deve habilitar o redirecionamento forçado de HTTP para HTTPS e configurar a versão mínima de TLS conforme os requisitos de segurança financeira.

Tarefas:

[CLI] Habilite o redirecionamento forçado de HTTP para HTTPS:

az webapp update --name <nome-webapp> \
  --resource-group nvt-rg-main --https-only true

[CLI] Configure a versão mínima de TLS como 1.2:

az webapp config set --name <nome-webapp> \
  --resource-group nvt-rg-main --min-tls-version 1.2

Critérios de Validação:

# Deve retornar true:
az webapp show --name <nome-webapp> \
  --resource-group nvt-rg-main --query "httpsOnly"

# Deve retornar "1.2":
az webapp config show --name <nome-webapp> \
  --resource-group nvt-rg-main --query "minTlsVersion"

Etapa 45 — Configurar backup para App Service

Contexto: O regulador financeiro exige que o Web App tenha backups automáticos diários retidos por 30 dias. O backup deve ser armazenado no storage account de produção criado anteriormente.

Tarefas:

[Portal] Configure o backup automático em: App Services → <nome-webapp> → Backup

Parâmetro	Valor
Storage account	nvtprodsa<sufixo>
Container	nvt-webapp-backup (criar novo)
Frequency	Daily
Retention	30 dias

[CLI] Verifique a configuração de backup do Web App:

az webapp config backup show \
  --resource-group nvt-rg-main --webapp-name <nome-webapp>

Critérios de Validação:

# Deve retornar objeto com frequência e retenção configurados:
az webapp config backup show \
  --resource-group nvt-rg-main --webapp-name <nome-webapp> \
  --query "backupSchedule"

Etapa 46 — Configurar deployment slots para App Service

Contexto: O processo de deploy da NovaTech usa a estratégia de slot swap: o código é implantado no slot staging e, após validação, promovido para produção com zero downtime.

Tarefas:

[CLI] Implante uma aplicação de teste no slot staging usando az webapp up --slot staging com uma aplicação Node.js simples, ou configure source control no slot via az webapp deployment source config.

[CLI] Execute o slot swap do slot staging para produção:

az webapp deployment slot swap \
  --name <nome-webapp> \
  --resource-group nvt-rg-main \
  --slot staging \
  --target-slot production

Critérios de Validação:

# Deve retornar slot staging em estado Running:
az webapp deployment slot list --name <nome-webapp> \
  --resource-group nvt-rg-main \
  --query "[].{Slot:name,State:state}"

Etapa 47 — Configurar networking settings para App Service

Contexto: Para garantir que o Web App acesse os recursos internos da NovaTech sem expor tráfego à internet pública, o time deve configurar VNet Integration para a subnet de compute.

Tarefas:

[CLI] Crie a subnet nvt-snet-webapp com prefix 10.10.3.0/24 na VNet nvt-vnet-main, com delegation para Microsoft.Web/serverFarms:

az network vnet subnet create \
  --name nvt-snet-webapp \
  --vnet-name nvt-vnet-main \
  --resource-group nvt-rg-network \
  --address-prefix 10.10.3.0/24 \
  --delegations Microsoft.Web/serverFarms

[CLI] Configure a VNet Integration do Web App:

az webapp vnet-integration add \
  --name <nome-webapp> \
  --resource-group nvt-rg-main \
  --vnet nvt-vnet-main \
  --subnet nvt-snet-webapp

Critérios de Validação:

# Deve retornar objeto com a VNet e subnet corretas:
az webapp vnet-integration list --name <nome-webapp> \
  --resource-group nvt-rg-main \
  --query "[].{VNet:vnetResourceId,Subnet:subnet}"

Domínio 6 — Redes

Etapa 48 — Criar e configurar Virtual Networks e subnets

Contexto: A NovaTech precisa de uma segunda VNet em Brazil South para os recursos do ambiente de staging. Esta VNet terá subnets específicas para compute e storage, seguindo o mesmo padrão de endereçamento da VNet principal.

Tarefas:

[CLI] Crie a VNet nvt-vnet-staging no resource group nvt-rg-network, região Brazil South, com address space 10.20.0.0/16 usando az network vnet create.

[CLI] Crie as subnets abaixo dentro da VNet de staging:

Nome	Prefix
nvt-snet-stg-compute	10.20.1.0/24
nvt-snet-stg-storage	10.20.2.0/24

Critérios de Validação:

# Deve retornar 2 objetos com os prefixes corretos:
az network vnet subnet list --vnet-name nvt-vnet-staging \
  --resource-group nvt-rg-network \
  --query "[].{Name:name,Prefix:addressPrefix}"

Etapa 49 — Configurar Virtual Network Peering

Contexto: O ambiente de staging precisa acessar serviços compartilhados no resource group de produção (como o Key Vault e o storage account). O peering entre nvt-vnet-main e nvt-vnet-staging habilitará essa conectividade.

Tarefas:

[CLI] Crie o peering de nvt-vnet-main para nvt-vnet-staging:

az network vnet peering create \
  --name nvt-peer-main-to-staging \
  --vnet-name nvt-vnet-main \
  --resource-group nvt-rg-network \
  --remote-vnet <resource-id-da-nvt-vnet-staging> \
  --allow-vnet-access

[CLI] Crie o peering recíproco de nvt-vnet-staging para nvt-vnet-main (o peering requer criação em ambos os lados).

Critérios de Validação:

# Ambos devem retornar "Connected":
az network vnet peering show --name nvt-peer-main-to-staging \
  --vnet-name nvt-vnet-main \
  --resource-group nvt-rg-network --query "peeringState"

az network vnet peering show --name nvt-peer-staging-to-main \
  --vnet-name nvt-vnet-staging \
  --resource-group nvt-rg-network --query "peeringState"

Etapa 50 — Configurar Public IP Addresses

Contexto: A Public IP nvt-pip-main foi criada via Bicep na Etapa 32. O time deve criar uma segunda Public IP para o Load Balancer que será implantado na Etapa 57, configurando-a com DNS label para acesso pelo nome.

Tarefas:

[CLI] Crie a Public IP nvt-pip-lb no resource group nvt-rg-network, região East US, SKU Standard, allocation method Static, com DNS label globalmente único:

az network public-ip create \
  --name nvt-pip-lb \
  --resource-group nvt-rg-network \
  --sku Standard \
  --allocation-method Static \
  --dns-name nvt-lb-<sufixo-unico>

[CLI] Confirme o FQDN atribuído:

az network public-ip show --name nvt-pip-lb \
  --resource-group nvt-rg-network --query "dnsSettings.fqdn"

Critérios de Validação:

# Deve retornar SKU = Standard e FQDN no formato *.eastus.cloudapp.azure.com:
az network public-ip show --name nvt-pip-lb \
  --resource-group nvt-rg-network \
  --query "{IP:ipAddress,FQDN:dnsSettings.fqdn,SKU:sku.name}"

Etapa 51 — Configurar user-defined routes

Contexto: A política de segurança da NovaTech exige que todo o tráfego de saída das VMs de aplicação passe por uma Network Virtual Appliance (simulada). O tráfego da subnet nvt-snet-compute para a internet deve ser roteado através de um IP interno específico.

Tarefas:

[CLI] Crie a Route Table nvt-rt-compute no resource group nvt-rg-network, região East US, com BGP route propagation desabilitada:

az network route-table create \
  --name nvt-rt-compute \
  --resource-group nvt-rg-network \
  --disable-bgp-route-propagation true

[CLI] Adicione a rota para o prefixo 0.0.0.0/0 com next hop VirtualAppliance e IP 10.10.0.4 (IP simulado do NVA):

az network route-table route create \
  --route-table-name nvt-rt-compute \
  --resource-group nvt-rg-network \
  --name nvt-route-internet \
  --address-prefix 0.0.0.0/0 \
  --next-hop-type VirtualAppliance \
  --next-hop-ip-address 10.10.0.4

[CLI] Associe a Route Table à subnet nvt-snet-compute:

az network vnet subnet update \
  --name nvt-snet-compute \
  --vnet-name nvt-vnet-main \
  --resource-group nvt-rg-network \
  --route-table nvt-rt-compute

Critérios de Validação:

# Deve retornar Resource ID contendo nvt-rt-compute:
az network vnet subnet show --name nvt-snet-compute \
  --vnet-name nvt-vnet-main \
  --resource-group nvt-rg-network --query "routeTable.id"

Etapa 52 — Criar e configurar NSGs e Application Security Groups

Contexto: A NovaTech precisa controlar o tráfego de rede entre as camadas da aplicação. Um NSG deve proteger a subnet de compute, e Application Security Groups (ASG) permitirão regras lógicas baseadas em função dos servidores.

Tarefas:

[CLI] Crie o ASG nvt-asg-appservers no resource group nvt-rg-network, região East US:

az network asg create --name nvt-asg-appservers \
  --resource-group nvt-rg-network

[CLI] Crie o NSG nvt-nsg-compute no resource group nvt-rg-network e adicione as regras:

Prioridade	Nome	Direção	Source	Dest	Porta	Ação
100	Allow-HTTP-Inbound	Inbound	*	ASG nvt-asg-appservers	80	Allow
110	Allow-HTTPS-Inbound	Inbound	*	ASG nvt-asg-appservers	443	Allow
4000	Deny-All-Inbound	Inbound	*	*	*	Deny

Use az network nsg rule create para cada regra.

[CLI] Associe o NSG nvt-nsg-compute à subnet nvt-snet-compute:

az network vnet subnet update --name nvt-snet-compute \
  --vnet-name nvt-vnet-main \
  --resource-group nvt-rg-network \
  --network-security-group nvt-nsg-compute

Critérios de Validação:

# Deve retornar 3 linhas com prioridades 100, 110 e 4000:
az network nsg rule list --nsg-name nvt-nsg-compute \
  --resource-group nvt-rg-network \
  --query "[].{Name:name,Priority:priority,Action:access}" --output table

Etapa 53 — Avaliar effective security rules em NSGs

Contexto: Após a configuração do NSG, o time de segurança precisa verificar as regras efetivas aplicadas à NIC da VM nvt-vm-app01, confirmando que as regras do NSG e as default rules do Azure estão combinando corretamente.

Tarefas:

[CLI] Obtenha o nome da NIC da VM nvt-vm-app01:

az vm show --name nvt-vm-app01 --resource-group nvt-rg-main \
  --query "networkProfile.networkInterfaces[0].id"

[CLI] Liste as effective security rules aplicadas à NIC:

az network nic list-effective-nsg \
  --name <nome-nic> --resource-group nvt-rg-main

[CLI] Identifique na saída quais regras são provenientes do NSG nvt-nsg-compute e quais são default rules do Azure. Registre o resultado.

Critérios de Validação:

# Deve retornar objeto com Name = Allow-HTTP-Inbound e Priority = 100:
az network nic list-effective-nsg --name <nome-nic> \
  --resource-group nvt-rg-main \
  --query "effectiveSecurityRules[?name=='Allow-HTTP-Inbound'].{Name:name,Priority:priority}"

Etapa 54 — Implementar Azure Bastion

Contexto: A NovaTech eliminou o acesso RDP/SSH direto via internet para as VMs de produção. O Azure Bastion será implantado para fornecer acesso seguro via navegador sem exposição de portas públicas.

Custo

Azure Bastion gera ~USD 0,19/h. Delete o recurso após uso durante o laboratório.

Tarefas:

[CLI] Crie a subnet AzureBastionSubnet na VNet nvt-vnet-main com prefix 10.10.254.0/27. O nome da subnet deve ser exatamente AzureBastionSubnet.

[CLI] Crie a Public IP nvt-pip-bastion no resource group nvt-rg-network, região East US, SKU Standard, allocation method Static.

[CLI] Crie o Azure Bastion nvt-bastion-main no resource group nvt-rg-network. O deploy leva aproximadamente 10 minutos:

az network bastion create \
  --name nvt-bastion-main \
  --resource-group nvt-rg-network \
  --vnet-name nvt-vnet-main \
  --public-ip-address nvt-pip-bastion

Critérios de Validação:

# Deve retornar State = Succeeded:
az network bastion show --name nvt-bastion-main \
  --resource-group nvt-rg-network \
  --query "{State:provisioningState,SKU:sku.name}"

Etapa 55 — Configurar service endpoints e private endpoints

Contexto: Para reforçar a segurança do acesso ao storage account e ao Key Vault, o time deve configurar private endpoints para ambos os serviços dentro da VNet principal, eliminando o tráfego de dados via internet pública.

Tarefas:

[CLI] Crie a subnet nvt-snet-privatelink com prefix 10.10.4.0/24 na VNet nvt-vnet-main, com network policies desabilitadas:

az network vnet subnet create \
  --name nvt-snet-privatelink \
  --vnet-name nvt-vnet-main \
  --resource-group nvt-rg-network \
  --address-prefix 10.10.4.0/24 \
  --disable-private-endpoint-network-policies true

[CLI] Crie o private endpoint para o storage account de produção na subnet nvt-snet-privatelink:

az network private-endpoint create \
  --name nvt-pe-storage \
  --resource-group nvt-rg-main \
  --vnet-name nvt-vnet-main \
  --subnet nvt-snet-privatelink \
  --private-connection-resource-id <resource-id-do-storage> \
  --group-id blob \
  --connection-name nvt-pe-storage-conn

[CLI] Crie a Private DNS Zone privatelink.blob.core.windows.net e vincule-a à VNet nvt-vnet-main:

az network private-dns zone create \
  --name privatelink.blob.core.windows.net \
  --resource-group nvt-rg-network

az network private-dns link vnet create \
  --name nvt-dns-link-storage \
  --zone-name privatelink.blob.core.windows.net \
  --resource-group nvt-rg-network \
  --virtual-network nvt-vnet-main \
  --registration-enabled false

[CLI] Crie o DNS zone group para o private endpoint:

az network private-endpoint dns-zone-group create \
  --endpoint-name nvt-pe-storage \
  --resource-group nvt-rg-main \
  --name nvt-pe-storage-dns \
  --private-dns-zone privatelink.blob.core.windows.net \
  --zone-name blob

Critérios de Validação:

# Deve retornar ConnState = Approved, State = Succeeded:
az network private-endpoint show --name nvt-pe-storage \
  --resource-group nvt-rg-main \
  --query "{State:provisioningState,ConnState:privateLinkServiceConnections[0].privateLinkServiceConnectionState.status}"

Etapa 56 — Configurar Azure DNS

Contexto: A NovaTech usa o domínio fictício novatech.local para resolução de nomes interna entre os recursos. O Azure DNS Private Zone deve ser configurado com registros A para as VMs e um registro CNAME para o Web App.

Tarefas:

[CLI] Crie a Private DNS Zone novatech.local no resource group nvt-rg-network:

az network private-dns zone create \
  --name novatech.local \
  --resource-group nvt-rg-network

[CLI] Vincule a zona novatech.local à VNet nvt-vnet-main com auto-registration habilitado:

az network private-dns link vnet create \
  --name nvt-dns-link-main \
  --zone-name novatech.local \
  --resource-group nvt-rg-network \
  --virtual-network nvt-vnet-main \
  --registration-enabled true

[CLI] Crie um registro A apontando app01.novatech.local para o IP privado da VM nvt-vm-app01. Capture o IP com az vm show --query "privateIps" -d:

az network private-dns record-set a add-record \
  --zone-name novatech.local \
  --resource-group nvt-rg-network \
  --record-set-name app01 \
  --ipv4-address <ip-privado-da-vm>

Critérios de Validação:

# Deve retornar array com o IP privado da VM nvt-vm-app01:
az network private-dns record-set a show \
  --zone-name novatech.local \
  --resource-group nvt-rg-network \
  --name app01 --query "aRecords"

Etapa 57 — Configurar Load Balancer interno e público

Contexto: As duas VMs de aplicação (nvt-vm-app01 e nvt-vm-app02) devem receber tráfego HTTP balanceado. O Load Balancer público usará a Public IP nvt-pip-lb criada na Etapa 50 e distribuirá o tráfego na porta 80 entre as duas VMs.

Tarefas:

[CLI] Crie o Load Balancer público nvt-lb-public no resource group nvt-rg-network, SKU Standard, com frontend IP usando nvt-pip-lb:

az network lb create \
  --name nvt-lb-public \
  --resource-group nvt-rg-network \
  --sku Standard \
  --public-ip-address nvt-pip-lb \
  --frontend-ip-name nvt-lb-frontend

[CLI] Crie o backend pool nvt-lb-backendpool e adicione as NICs das VMs nvt-vm-app01 e nvt-vm-app02 ao pool usando az network lb address-pool create e az network nic ip-config address-pool add.

[CLI] Crie o health probe HTTP na porta 80 com path / e intervalo de 15 segundos, e a load balancing rule para a porta 80:

az network lb probe create \
  --lb-name nvt-lb-public \
  --resource-group nvt-rg-network \
  --name nvt-lb-probe --protocol Http --port 80 --path / --interval 15

az network lb rule create \
  --lb-name nvt-lb-public \
  --resource-group nvt-rg-network \
  --name nvt-lb-rule-http \
  --frontend-ip-name nvt-lb-frontend \
  --backend-pool-name nvt-lb-backendpool \
  --probe-name nvt-lb-probe \
  --protocol Tcp --frontend-port 80 --backend-port 80

Critérios de Validação:

# Deve retornar FE, BE e Probe preenchidos com os nomes definidos:
az network lb show --name nvt-lb-public --resource-group nvt-rg-network \
  --query "{FE:frontendIpConfigurations[0].name,BE:backendAddressPools[0].name,Probe:probes[0].name}"

Etapa 58 — Troubleshoot network connectivity

Contexto: O time de operações reportou que a VM nvt-vm-app02 não consegue alcançar o storage account de produção via private endpoint. O Azure Network Watcher deve ser usado para diagnosticar o problema de conectividade.

Tarefas:

[CLI] Verifique se o Network Watcher está habilitado na região East US. Se não estiver, habilite-o:

az network watcher list
az network watcher configure --resource-group nvt-rg-network --locations eastus --enabled true

[CLI] Execute um teste de conectividade da VM nvt-vm-app02 para o private endpoint do storage account:

az network watcher test-connectivity \
  --source-resource <resource-id-da-vm-app02> \
  --dest-address <ip-do-private-endpoint> \
  --dest-port 443

[CLI] Analise o resultado e identifique o componente que bloqueia ou permite a conexão.

Critérios de Validação:

# Deve retornar connectionStatus preenchido (Reachable ou Unreachable) com lista de hops:
az network watcher test-connectivity \
  --source-resource <vm-app02-id> \
  --dest-address <private-endpoint-ip> \
  --dest-port 443 \
  --query "{Status:connectionStatus,Hops:hops[*].type}"

Domínio 7 — Monitoramento

Etapa 59 — Interpretar métricas no Azure Monitor

Contexto: A equipe de operações da NovaTech precisa de visibilidade sobre o desempenho da VM nvt-vm-app01. As métricas de CPU e memória devem ser consultadas via CLI para estabelecer uma baseline de desempenho.

Tarefas:

[CLI] Consulte a métrica Percentage CPU da VM nvt-vm-app01 para o intervalo das últimas 1 hora, com granularidade de 5 minutos e aggregation Average:

az monitor metrics list \
  --resource <resource-id-da-vm> \
  --metric "Percentage CPU" \
  --interval PT5M \
  --aggregation Average

[CLI] Consulte a métrica Available Memory Bytes da mesma VM para o mesmo período.

Critérios de Validação:

# Deve retornar array com timeStamp e average (pode ser 0 se VM ociosa):
az monitor metrics list --resource <vm-id> \
  --metric "Percentage CPU" \
  --interval PT5M --aggregation Average \
  --query "value[0].timeseries[0].data[-3:].{Time:timeStamp,Avg:average}"

Etapa 60 — Configurar log settings no Azure Monitor

Contexto: Para atender aos requisitos de auditoria financeira, todos os eventos administrativos e de diagnóstico das VMs e do storage account devem ser enviados a um Log Analytics Workspace centralizado.

Tarefas:

[CLI] Crie o Log Analytics Workspace nvt-law-main no resource group nvt-rg-main, região East US, retenção de 30 dias:

az monitor log-analytics workspace create \
  --name nvt-law-main \
  --resource-group nvt-rg-main \
  --retention-time 30

[CLI] Habilite Diagnostic Settings na VM nvt-vm-app01 para enviar logs ao workspace nvt-law-main:

az monitor diagnostic-settings create \
  --resource <resource-id-da-vm> \
  --workspace <resource-id-do-workspace> \
  --name "nvt-diag-vm"

[CLI] Habilite Diagnostic Settings no storage account de produção, enviando métricas de Transaction e logs de StorageRead, StorageWrite ao workspace. O --resource aponta para o blob service endpoint do storage account (adicione /blobServices/default ao Resource ID do SA).

Critérios de Validação:

# Deve retornar objeto com Workspace preenchido com o Resource ID do workspace:
az monitor diagnostic-settings show \
  --resource <vm-id> --name "nvt-diag-vm" \
  --query "{Name:name,Workspace:workspaceId}"

Etapa 61 — Consultar e analisar logs no Azure Monitor

Contexto: Com os logs sendo coletados no workspace nvt-law-main, o time de segurança precisa executar queries KQL para verificar se há erros de autenticação registrados e monitorar a atividade das VMs.

Tarefas:

[CLI] Execute a query KQL no workspace nvt-law-main para listar os últimos 10 heartbeats:

az monitor log-analytics query \
  --workspace <workspace-id> \
  --analytics-query "Heartbeat | top 10 by TimeGenerated desc"

[CLI] Execute a query de contagem de eventos por Computer nas últimas 24 horas:

az monitor log-analytics query \
  --workspace <workspace-id> \
  --analytics-query "Heartbeat | summarize count() by Computer | order by count_ desc"

Critérios de Validação:

# Deve retornar array (vazio ou com dados) sem erro de API:
az monitor log-analytics query \
  --workspace <workspace-id> \
  --analytics-query "Heartbeat | take 1" \
  --query "tables[0].rows"

Etapa 62 — Configurar alert rules, action groups e alert processing rules

Contexto: O time de operações deve ser notificado imediatamente quando a CPU de qualquer VM de produção ultrapassar 85% por mais de 5 minutos. Um action group com e-mail deve ser configurado e vinculado a uma alert rule.

Tarefas:

[CLI] Crie o Action Group nvt-ag-ops no resource group nvt-rg-main com um receiver de e-mail:

az monitor action-group create \
  --name nvt-ag-ops \
  --resource-group nvt-rg-main \
  --short-name nvtops \
  --action email nvt-alert-email <seu-email>

[CLI] Crie a Metric Alert Rule nvt-alert-cpu-high que dispara quando Percentage CPU > 85 por 5 minutos:

az monitor metrics alert create \
  --name nvt-alert-cpu-high \
  --resource-group nvt-rg-main \
  --scopes <resource-id-da-vm-app01> \
  --condition "avg Percentage CPU > 85" \
  --window-size 5m \
  --evaluation-frequency 1m \
  --action <resource-id-do-action-group>

Critérios de Validação:

# Deve retornar Condition = 85.0, Enabled = true:
az monitor metrics alert show --name nvt-alert-cpu-high \
  --resource-group nvt-rg-main \
  --query "{Name:name,Enabled:enabled,Condition:criteria.allOf[0].threshold}"

Etapa 63 — Monitorar VMs, storage accounts e redes com Azure Monitor Insights

Contexto: O dashboard de operações da NovaTech deve consolidar insights das VMs, do storage account e da rede em um único ponto de visibilidade. O VM Insights deve ser habilitado na VM nvt-vm-app01.

Tarefas:

[CLI] Habilite VM Insights na VM nvt-vm-app01 associando ao workspace nvt-law-main. Instale a extensão de monitoramento:

az vm extension set \
  --vm-name nvt-vm-app01 \
  --resource-group nvt-rg-main \
  --name MicrosoftMonitoringAgent \
  --publisher Microsoft.EnterpriseCloud.Monitoring \
  --settings '{"workspaceId": "<workspace-id>"}' \
  --protected-settings '{"workspaceKey": "<workspace-key>"}'

Obtenha workspace ID e key com az monitor log-analytics workspace get-shared-keys.

[Portal] Confirme que o estado exibe Monitored em: Azure Monitor → Virtual Machines → nvt-vm-app01 → Insights.

Critérios de Validação:

# Deve retornar objeto com State = Succeeded:
az vm extension list --vm-name nvt-vm-app01 --resource-group nvt-rg-main \
  --query "[?name=='MicrosoftMonitoringAgent' || name=='AzureMonitorWindowsAgent'].{Name:name,State:provisioningState}"

Etapa 64 — Usar Azure Network Watcher e Connection Monitor

Contexto: Para monitoramento contínuo da conectividade entre as VMs e o storage account de produção, o time configura um Connection Monitor que executará testes automáticos de conectividade a cada 30 segundos.

Tarefas:

[CLI] Crie o Connection Monitor nvt-cm-vm-to-storage no Network Watcher da região East US:

az network watcher connection-monitor create \
  --name nvt-cm-vm-to-storage \
  --location eastus \
  --source-resource <resource-id-da-vm-app01> \
  --dest-address <ip-do-private-endpoint-storage> \
  --dest-port 443 \
  --monitoring-interval 30

[CLI] Consulte o estado atual do Connection Monitor:

az network watcher connection-monitor query \
  --name nvt-cm-vm-to-storage --location eastus

Critérios de Validação:

# Deve retornar State = Running ou Monitoring:
az network watcher connection-monitor show \
  --name nvt-cm-vm-to-storage --location eastus \
  --query "{Name:name,State:monitoringStatus}"

Domínio 8 — Backup e Recuperação de Desastres

Etapa 65 — Criar Recovery Services Vault e Backup Vault

Contexto: O plano de continuidade de negócios da NovaTech exige cofres de backup dedicados para as VMs e para o storage account. Um Recovery Services Vault cobrirá as VMs, e um Backup Vault cobrirá os workloads modernos.

Tarefas:

[CLI] Crie o Recovery Services Vault nvt-rsv-main no resource group nvt-rg-main, região East US:

az backup vault create \
  --name nvt-rsv-main \
  --resource-group nvt-rg-main \
  --location eastus

[CLI] Defina a redundância de armazenamento do vault como GeoRedundant:

az backup vault backup-properties set \
  --name nvt-rsv-main \
  --resource-group nvt-rg-main \
  --backup-storage-redundancy GeoRedundant

[CLI] Crie o Backup Vault nvt-bv-main no resource group nvt-rg-main, região East US:

az dataprotection backup-vault create \
  --vault-name nvt-bv-main \
  --resource-group nvt-rg-main \
  --location eastus \
  --storage-setting "[{type:'LocallyRedundant',datastore-type:'VaultStore'}]"

Critérios de Validação:

# Deve retornar Name = nvt-rsv-main, Location = eastus:
az backup vault show --name nvt-rsv-main --resource-group nvt-rg-main \
  --query "{Name:name,Location:location,SKU:sku.name}"

# Deve retornar "nvt-bv-main":
az dataprotection backup-vault show \
  --vault-name nvt-bv-main --resource-group nvt-rg-main --query "name"

Etapa 66 — Criar e configurar backup policy

Contexto: Com os vaults criados, o time deve configurar políticas de backup para as VMs de produção. A política define frequência diária, horário e período de retenção de 30 dias, alinhados aos requisitos regulatórios.

Tarefas:

[CLI] Obtenha o template padrão de backup policy para VMs Azure e salve em arquivo:

az backup policy get-default-for-vm \
  --vault-name nvt-rsv-main \
  --resource-group nvt-rg-main > nvt-backup-policy.json

[CLI] Modifique o arquivo nvt-backup-policy.json para ajustar a retenção diária para 30 dias e o horário de backup para 02:00 UTC. Em seguida, crie a policy no vault:

az backup policy create \
  --policy @nvt-backup-policy.json \
  --vault-name nvt-rsv-main \
  --resource-group nvt-rg-main \
  --name "nvt-vm-backup-policy" \
  --backup-management-type AzureIaasVM

Critérios de Validação:

# Deve retornar Name = nvt-vm-backup-policy, Type = AzureIaasVM:
az backup policy show --vault-name nvt-rsv-main \
  --resource-group nvt-rg-main \
  --name "nvt-vm-backup-policy" \
  --query "{Name:name,Type:backupManagementType}"

Etapa 67 — Realizar operações de backup e restore com Azure Backup

Contexto: A VM nvt-vm-app01 deve ser protegida imediatamente. O time habilita o backup, executa um backup sob demanda e verifica os pontos de recuperação disponíveis.

Tarefas:

[CLI] Habilite o backup da VM nvt-vm-app01 no vault nvt-rsv-main usando a política nvt-vm-backup-policy:

az backup protection enable-for-vm \
  --vault-name nvt-rsv-main \
  --resource-group nvt-rg-main \
  --vm nvt-vm-app01 \
  --policy-name "nvt-vm-backup-policy"

[CLI] Execute um backup imediato (on-demand) e monitore o status até a conclusão:

# Obtenha o container name primeiro:
az backup container list --vault-name nvt-rsv-main \
  --resource-group nvt-rg-main --backup-management-type AzureIaasVM

az backup protection backup-now \
  --vault-name nvt-rsv-main \
  --resource-group nvt-rg-main \
  --container-name <container-name> \
  --item-name nvt-vm-app01 \
  --retain-until <data-7-dias-a-frente>

# Monitore:
az backup job list --vault-name nvt-rsv-main \
  --resource-group nvt-rg-main --status InProgress

[Portal] Após a conclusão, confirme em: Recovery Services vaults → nvt-rsv-main → Backup items → Azure Virtual Machine. A VM nvt-vm-app01 deve aparecer com status Backup succeeded.

Critérios de Validação:

# Deve retornar objeto com Name preenchido e Type indicando o tipo de recovery point:
az backup recoverypoint list --vault-name nvt-rsv-main \
  --resource-group nvt-rg-main \
  --container-name <container-name> \
  --item-name nvt-vm-app01 \
  --backup-management-type AzureIaasVM \
  --query "[0].{Name:name,Type:properties.recoveryPointType}"

Etapa 68 — Configurar Azure Site Recovery e realizar failover

Contexto: Para garantir continuidade de negócios em caso de desastre regional, a VM nvt-vm-app01 deve ser replicada para a região Brazil South usando Azure Site Recovery.

Custo

Site Recovery gera ~USD 0,16/VM/h enquanto ativo. Desabilite a replicação após validar o test failover.

Tarefas:

[Portal] Configure a replicação em: Virtual machines → nvt-vm-app01 → Disaster recovery

Parâmetro	Valor
Target region	Brazil South
Target resource group	nvt-rg-staging
Recovery Services Vault	nvt-rsv-dr (criar novo em Brazil South)
Target VNet	nvt-vnet-staging

Deixe as demais configurações no padrão e inicie a replicação.

[Portal] Após a replicação inicial completar, execute o test failover em: Recovery Services vaults → nvt-rsv-dr → Replicated items → nvt-vm-app01 → Test failover

Recovery point: Latest processed
Azure network: nvt-vnet-staging

[Portal] Após validar o test failover, execute Cleanup test failover para remover a VM de teste criada durante o processo.

Critérios de Validação:

dica

Item replicado nvt-vm-app01 exibe Replication health: Healthy e Status: Protected no vault de DR.
Test failover completa sem erros, criando VM temporária em Brazil South.
Cleanup remove a VM temporária com sucesso e status retorna a Protected.

Etapa 69 — Configurar e interpretar reports e alertas para backups

Contexto: Para fechar o ciclo de governança de backup da NovaTech, o time deve configurar um alerta para falhas de backup e verificar os relatórios de conformidade do vault nvt-rsv-main.

Tarefas:

[Portal] Configure a alert rule de falha de backup em: Recovery Services vaults → nvt-rsv-main → Alerts → Create alert rule. Use signal Backup Jobs com condição Status = Failed. Vincule ao Action Group nvt-ag-ops criado na Etapa 62.

[Portal] Conecte o vault ao workspace nvt-law-main em: Recovery Services vaults → nvt-rsv-main → Reports. Navegue até Backup center → Reports e verifique o painel Backup Summary.

[CLI] Liste todos os jobs de backup do vault nvt-rsv-main das últimas 24 horas:

az backup job list \
  --vault-name nvt-rsv-main \
  --resource-group nvt-rg-main \
  --output table

Critérios de Validação:

# Deve retornar ao menos 1 linha com Status = Completed referenciando nvt-vm-app01:
az backup job list --vault-name nvt-rsv-main \
  --resource-group nvt-rg-main \
  --query "[?properties.status=='Completed'].{Job:name,VM:properties.entityFriendlyName,Status:properties.status}" \
  --output table

# Deve retornar array com nome da alert rule criada:
az monitor activity-log alert list --resource-group nvt-rg-main \
  --query "[?contains(name,'backup')].name"

Validação Final do Ambiente

Ao concluir todas as 69 etapas, execute os comandos abaixo para confirmar que o ambiente NovaTech está completo e todos os componentes principais estão no estado esperado.

# Verificar todos os resource groups criados com a tag NVT-CORE:
az group list --tag CostCenter=NVT-CORE \
  --query "[].{Name:name,Location:location,Env:tags.Environment}" --output table

# Verificar VMs em estado running:
az vm list --resource-group nvt-rg-main --show-details \
  --query "[].{Name:name,State:powerState,Zone:zones[0]}" --output table

# Verificar storage accounts:
az storage account list --resource-group nvt-rg-main \
  --query "[].{Name:name,SKU:sku.name,Encryption:encryption.keySource}" --output table

# Verificar containers em execução:
az containerapp list --resource-group nvt-rg-main \
  --query "[].{Name:name,Status:properties.runningStatus}" --output table

# Verificar backup jobs concluídos:
az backup job list --vault-name nvt-rsv-main --resource-group nvt-rg-main \
  --query "[?properties.status=='Completed'].{Job:name,Status:properties.status}" --output table

Categoria	Recursos	Resource Group
Identidade	2 usuários, 2 grupos, 1 convidado, SSPR	Microsoft Entra ID
Governança	1 policy, 1 lock, budget, 2 management groups	nvt-rg-main
Storage	nvtprodsa (ZRS + CMK), nvtstagingsa (GRS)	nvt-rg-main / nvt-rg-staging
Compute	nvt-vm-app01 (B2s), nvt-vm-app02 (B2s), nvt-vmss-proc	nvt-rg-main
Contêineres	nvtregistry, nvt-aci-report, nvt-ca-api	nvt-rg-main
App Service	nvt-webapp-portal (P1v3, slot staging)	nvt-rg-main
Rede	nvt-vnet-main, nvt-vnet-staging, NSG, ASG, LB, Bastion, DNS, UDR, Private Endpoints	nvt-rg-network
Monitoramento	nvt-law-main, alertas, Connection Monitor, VM Insights	nvt-rg-main
Backup e DR	nvt-rsv-main, nvt-bv-main, Site Recovery (Brazil South)	nvt-rg-main

Laboratório AZ-104 — NovaTech Solutions | Prefixo: nvt | Modo: Azure CLI | 69 etapas | 8 domínios

Ambiente Cumulativo de Implantação Real​

Narrativa Central​

Pré-requisitos​

Convenção de Nomenclatura​

Índice por Domínio do Exame​

Domínio 1 — Identidade e Governança​

Etapa 1 — Criar usuários e grupos no Microsoft Entra ID​

Etapa 2 — Gerenciar propriedades de usuários e grupos​

Etapa 3 — Gerenciar licenças no Microsoft Entra ID​

Etapa 4 — Gerenciar usuários externos​

Etapa 5 — Configurar Self-Service Password Reset (SSPR)​

Etapa 6 — Gerenciar roles integradas do Azure​

Etapa 7 — Atribuir roles em diferentes escopos e interpretar atribuições​

Etapa 8 — Implementar e gerenciar Azure Policy​

Etapa 9 — Configurar resource locks​

Etapa 10 — Aplicar e gerenciar tags em recursos​

Etapa 11 — Gerenciar resource groups​

Etapa 12 — Gerenciar subscriptions e management groups​

Etapa 13 — Gerenciar custos com alertas, budgets e Azure Advisor​

Domínio 2 — Storage​

Etapa 14 — Configurar firewalls e virtual networks do Azure Storage​

Etapa 15 — Criar e usar SAS tokens​

Etapa 16 — Configurar stored access policies​

Etapa 17 — Gerenciar access keys​

Etapa 18 — Configurar acesso baseado em identidade para Azure Files​

Etapa 19 — Criar e configurar storage accounts​

Etapa 20 — Configurar redundância do Azure Storage​

Etapa 21 — Configurar object replication​

Etapa 22 — Configurar criptografia do storage account​

Etapa 23 — Gerenciar dados com Azure Storage Explorer e AzCopy​

Etapa 24 — Criar e configurar um file share no Azure Files​

Etapa 25 — Criar e configurar containers no Azure Blob Storage​

Etapa 26 — Configurar storage tiers​

Etapa 27 — Configurar soft delete para blobs e containers​

Etapa 28 — Configurar snapshots e soft delete para Azure Files​

Etapa 29 — Configurar blob lifecycle management​

Etapa 30 — Configurar blob versioning​

Domínio 3 — Infraestrutura como Código (IaC)​

Etapa 31 — Interpretar e modificar ARM templates e arquivos Bicep​

Etapa 32 — Fazer deploy de recursos com template Bicep​

Domínio 4 — Compute e Contêineres​

Etapa 33 — Criar e configurar Virtual Machines​

Etapa 34 — Configurar encryption at host para VMs​

Etapa 35 — Gerenciar discos de VMs​

Etapa 36 — Deploy de VMs em Availability Zones e Availability Sets​

Etapa 37 — Deploy e configuração de Azure Virtual Machine Scale Sets​

Etapa 38 — Criar e gerenciar Azure Container Registry​

Etapa 39 — Provisionar containers com Azure Container Instances​

Etapa 40 — Provisionar containers com Azure Container Apps​

Etapa 41 — Gerenciar sizing e scaling para containers​

Domínio 5 — App Service​

Etapa 42 — Criar e configurar Azure App Service​

Etapa 43 — Configurar scaling para App Service Plan​

Etapa 44 — Configurar TLS e certificados para App Service​

Etapa 45 — Configurar backup para App Service​

Etapa 46 — Configurar deployment slots para App Service​

Etapa 47 — Configurar networking settings para App Service​

Domínio 6 — Redes​

Etapa 48 — Criar e configurar Virtual Networks e subnets​

Etapa 49 — Configurar Virtual Network Peering​

Etapa 50 — Configurar Public IP Addresses​

Etapa 51 — Configurar user-defined routes​

Etapa 52 — Criar e configurar NSGs e Application Security Groups​

Etapa 53 — Avaliar effective security rules em NSGs​

Etapa 54 — Implementar Azure Bastion​

Etapa 55 — Configurar service endpoints e private endpoints​

Etapa 56 — Configurar Azure DNS​

Etapa 57 — Configurar Load Balancer interno e público​

Etapa 58 — Troubleshoot network connectivity​

Domínio 7 — Monitoramento​

Etapa 59 — Interpretar métricas no Azure Monitor​

Etapa 60 — Configurar log settings no Azure Monitor​

Etapa 61 — Consultar e analisar logs no Azure Monitor​

Etapa 62 — Configurar alert rules, action groups e alert processing rules​

Etapa 63 — Monitorar VMs, storage accounts e redes com Azure Monitor Insights​

Etapa 64 — Usar Azure Network Watcher e Connection Monitor​

Domínio 8 — Backup e Recuperação de Desastres​

Etapa 65 — Criar Recovery Services Vault e Backup Vault​

Etapa 66 — Criar e configurar backup policy​

Etapa 67 — Realizar operações de backup e restore com Azure Backup​

Ambiente Cumulativo de Implantação Real

Narrativa Central

Pré-requisitos

Convenção de Nomenclatura

Índice por Domínio do Exame

Domínio 1 — Identidade e Governança

Etapa 1 — Criar usuários e grupos no Microsoft Entra ID

Etapa 2 — Gerenciar propriedades de usuários e grupos

Etapa 3 — Gerenciar licenças no Microsoft Entra ID

Etapa 4 — Gerenciar usuários externos

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

Etapa 6 — Gerenciar roles integradas do Azure

Etapa 7 — Atribuir roles em diferentes escopos e interpretar atribuições

Etapa 8 — Implementar e gerenciar Azure Policy

Etapa 9 — Configurar resource locks

Etapa 10 — Aplicar e gerenciar tags em recursos

Etapa 11 — Gerenciar resource groups

Etapa 12 — Gerenciar subscriptions e management groups

Etapa 13 — Gerenciar custos com alertas, budgets e Azure Advisor

Domínio 2 — Storage

Etapa 14 — Configurar firewalls e virtual networks do Azure Storage

Etapa 15 — Criar e usar SAS tokens

Etapa 16 — Configurar stored access policies

Etapa 17 — Gerenciar access keys

Etapa 18 — Configurar acesso baseado em identidade para Azure Files

Etapa 19 — Criar e configurar storage accounts

Etapa 20 — Configurar redundância do Azure Storage

Etapa 21 — Configurar object replication

Etapa 22 — Configurar criptografia do storage account

Etapa 23 — Gerenciar dados com Azure Storage Explorer e AzCopy

Etapa 24 — Criar e configurar um file share no Azure Files

Etapa 25 — Criar e configurar containers no Azure Blob Storage

Etapa 26 — Configurar storage tiers

Etapa 27 — Configurar soft delete para blobs e containers

Etapa 28 — Configurar snapshots e soft delete para Azure Files

Etapa 29 — Configurar blob lifecycle management

Etapa 30 — Configurar blob versioning

Domínio 3 — Infraestrutura como Código (IaC)

Etapa 31 — Interpretar e modificar ARM templates e arquivos Bicep

Etapa 32 — Fazer deploy de recursos com template Bicep

Domínio 4 — Compute e Contêineres

Etapa 33 — Criar e configurar Virtual Machines

Etapa 34 — Configurar encryption at host para VMs

Etapa 35 — Gerenciar discos de VMs

Etapa 36 — Deploy de VMs em Availability Zones e Availability Sets

Etapa 37 — Deploy e configuração de Azure Virtual Machine Scale Sets

Etapa 38 — Criar e gerenciar Azure Container Registry

Etapa 39 — Provisionar containers com Azure Container Instances

Etapa 40 — Provisionar containers com Azure Container Apps

Etapa 41 — Gerenciar sizing e scaling para containers

Domínio 5 — App Service

Etapa 42 — Criar e configurar Azure App Service

Etapa 43 — Configurar scaling para App Service Plan

Etapa 44 — Configurar TLS e certificados para App Service

Etapa 45 — Configurar backup para App Service

Etapa 46 — Configurar deployment slots para App Service

Etapa 47 — Configurar networking settings para App Service

Domínio 6 — Redes

Etapa 48 — Criar e configurar Virtual Networks e subnets

Etapa 49 — Configurar Virtual Network Peering

Etapa 50 — Configurar Public IP Addresses

Etapa 51 — Configurar user-defined routes

Etapa 52 — Criar e configurar NSGs e Application Security Groups

Etapa 53 — Avaliar effective security rules em NSGs

Etapa 54 — Implementar Azure Bastion

Etapa 55 — Configurar service endpoints e private endpoints

Etapa 56 — Configurar Azure DNS

Etapa 57 — Configurar Load Balancer interno e público

Etapa 58 — Troubleshoot network connectivity

Domínio 7 — Monitoramento

Etapa 59 — Interpretar métricas no Azure Monitor

Etapa 60 — Configurar log settings no Azure Monitor

Etapa 61 — Consultar e analisar logs no Azure Monitor

Etapa 62 — Configurar alert rules, action groups e alert processing rules

Etapa 63 — Monitorar VMs, storage accounts e redes com Azure Monitor Insights

Etapa 64 — Usar Azure Network Watcher e Connection Monitor

Domínio 8 — Backup e Recuperação de Desastres

Etapa 65 — Criar Recovery Services Vault e Backup Vault

Etapa 66 — Criar e configurar backup policy

Etapa 67 — Realizar operações de backup e restore com Azure Backup