Laboratório Hands-on Guiado: AZ-104 — Microsoft Azure Administrator

Cenário

A empresa Datastream Analytics é uma consultoria de dados sediada em São Paulo que está expandindo sua infraestrutura no Azure para suportar novos clientes corporativos. Atualmente, a empresa possui uma única subscription Azure com um Resource Group de desenvolvimento contendo uma Virtual Network e uma Storage Account provisionadas manualmente pelo portal. A equipe de infraestrutura identificou inconsistências entre os ambientes de desenvolvimento e produção causadas por deploys manuais.

A meta técnica deste laboratório é implementar uma estratégia de Infrastructure as Code (IaC) utilizando ARM Templates e Bicep para padronizar, versionar e automatizar o provisionamento de recursos da Datastream Analytics. Ao final, a equipe será capaz de interpretar, modificar, implantar e exportar templates, garantindo reprodutibilidade entre ambientes.

Pré-requisitos

Antes de iniciar a Fase 1, crie ou confirme a existência dos recursos listados abaixo.

Subscription Azure com permissões de Contributor ou Owner. Confirme executando az account show na CLI ou acessando Subscriptions no portal.
Resource Group principal: crie o Resource Group que servirá de base para todo o laboratório.

Via Portal

Navegue até Resource groups no menu lateral.
Clique em Create.
Preencha o campo Resource group com rg-datastream-lab.
Selecione a região East US 2.
Clique em Review + create e depois em Create.

Via CLI

az group create \
  --name rg-datastream-lab \
  --location eastus2

Azure CLI instalada e autenticada: confirme executando az version e az account show. Se necessário, execute az login.
Bicep CLI instalada: confirme executando az bicep version. Se necessário, execute az bicep install.
Editor de código com extensão Bicep instalada (VS Code com extensão oficial da Microsoft é recomendado).

Tabela de Referência de Recursos

Recurso	Nome no lab	Região
Resource Group	rg-datastream-lab	East US 2
Storage Account	stodatastreamlab	East US 2
Virtual Network	vnet-datastream-prod	East US 2
Subnet	snet-app	East US 2
Network Security Group	nsg-datastream-app	East US 2
App Service Plan	asp-datastream-prod	East US 2
Web App	app-datastream-prod	East US 2

Fases do Laboratório

O laboratório está organizado em quatro fases progressivas. Cada fase constrói sobre os recursos e artefatos produzidos na fase anterior.

Fase 1 — Interpretação de ARM Templates e Arquivos Bicep

Nesta fase, você analisará templates ARM e arquivos Bicep existentes para compreender sua estrutura e identificar os recursos, parâmetros e dependências definidos. Essa fase cobre os objetivos Interpret an Azure Resource Manager template e Interpret a Bicep file. Nenhum recurso será implantado ainda; o foco é leitura e análise.

Tarefa 1.1 — Analisar a estrutura de um ARM Template existente

A Datastream Analytics recebeu de um fornecedor um ARM Template que provisiona uma Storage Account. Antes de utilizá-lo, você precisa interpretar cada seção do template para garantir que está em conformidade com os padrões da empresa.

Crie um diretório de trabalho local e dentro dele crie o arquivo storage-template.json com o conteúdo abaixo:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "storageAccountName": {
      "type": "string",
      "metadata": {
        "description": "Nome da Storage Account"
      }
    },
    "location": {
      "type": "string",
      "defaultValue": "[resourceGroup().location]"
    },
    "skuName": {
      "type": "string",
      "defaultValue": "Standard_LRS",
      "allowedValues": [
        "Standard_LRS",
        "Standard_GRS",
        "Standard_RAGRS"
      ]
    }
  },
  "variables": {
    "storageKind": "StorageV2"
  },
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2023-01-01",
      "name": "[parameters('storageAccountName')]",
      "location": "[parameters('location')]",
      "sku": {
        "name": "[parameters('skuName')]"
      },
      "kind": "[variables('storageKind')]",
      "properties": {
        "supportsHttpsTrafficOnly": true,
        "minimumTlsVersion": "TLS1_2"
      }
    }
  ],
  "outputs": {
    "storageId": {
      "type": "string",
      "value": "[resourceId('Microsoft.Storage/storageAccounts', parameters('storageAccountName'))]"
    },
    "primaryEndpoint": {
      "type": "string",
      "value": "[reference(parameters('storageAccountName')).primaryEndpoints.blob]"
    }
  }
}

Identifique e anote mentalmente cada seção do template: $schema, contentVersion, parameters, variables, resources e outputs.
Verifique quais parâmetros possuem valores padrão e quais são obrigatórios. Observe que storageAccountName não possui defaultValue, portanto é obrigatório no momento do deploy.
Analise a seção resources e identifique o resource type (Microsoft.Storage/storageAccounts), a apiVersion utilizada e como os parâmetros são referenciados usando a função parameters().
Observe que a seção outputs utiliza tanto resourceId() quanto reference() para expor informações do recurso criado.
Valide a sintaxe do template executando:

Via CLI

# Validação sem deploy real
az deployment group validate \
  --resource-group rg-datastream-lab \
  --template-file storage-template.json \
  --parameters storageAccountName=stodatastreamlab

O comando deve retornar sucesso sem erros. Caso retorne erro de validação, revise o JSON verificando chaves não fechadas, vírgulas extras ou valores inválidos no campo allowedValues.

A validação confirma que o template é sintaticamente correto e que os parâmetros fornecidos atendem às restrições definidas (tipo, valores permitidos). Nenhum recurso foi criado nesta etapa.

Tarefa 1.2 — Analisar a estrutura de um arquivo Bicep equivalente

Agora você analisará o equivalente em Bicep do mesmo template, comparando a sintaxe declarativa simplificada com o JSON do ARM Template.

Crie o arquivo storage-template.bicep com o conteúdo abaixo:

@description('Nome da Storage Account')
param storageAccountName string

@description('Regiao do recurso')
param location string = resourceGroup().location

@allowed([
  'Standard_LRS'
  'Standard_GRS'
  'Standard_RAGRS'
])
param skuName string = 'Standard_LRS'

var storageKind = 'StorageV2'

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: storageAccountName
  location: location
  sku: {
    name: skuName
  }
  kind: storageKind
  properties: {
    supportsHttpsTrafficOnly: true
    minimumTlsVersion: 'TLS1_2'
  }
}

output storageId string = storageAccount.id
output primaryEndpoint string = storageAccount.properties.primaryEndpoints.blob

Compare com o ARM Template da tarefa anterior e observe: a ausência de $schema e contentVersion, a sintaxe simplificada de param e var, a declaração de recurso com resource <nome-simbólico> '<tipo>@<api-version>' e o acesso direto a propriedades no output sem uso de reference().
Observe como o decorator @allowed substitui o campo allowedValues do ARM Template e como @description substitui o bloco metadata.
Valide o arquivo Bicep:

Via CLI

# Compila Bicep para ARM e verifica erros de sintaxe
az bicep build --file storage-template.bicep

Verifique que um arquivo storage-template.json foi gerado automaticamente. Compare esse JSON gerado com o template original da Tarefa 1.1 e observe que a estrutura é equivalente, embora possa haver diferenças cosméticas na formatação.

A compilação do Bicep demonstra que ele é uma abstração sobre o ARM Template. O arquivo JSON gerado é o artefato real enviado ao Azure Resource Manager durante um deploy.

Tarefa 1.3 — Identificar e corrigir erros deliberados em templates

Um colega da Datastream Analytics compartilhou um template com problemas. Você precisa identificar os erros antes que o template seja utilizado em produção.

Crie o arquivo broken-template.json com o conteúdo abaixo (contém erros intencionais):

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "storageName": {
      "type": "string"
    }
  },
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2023-01-01",
      "name": "[parameters('storageAccountName')]",
      "location": "[resourceGroup().location]",
      "sku": {
        "name": "Standard_XRS"
      },
      "kind": "StorageV2",
      "properties": {}
    }
  ]
}

Execute a validação:

Via CLI

az deployment group validate \
  --resource-group rg-datastream-lab \
  --template-file broken-template.json \
  --parameters storageName=stodatastreamtest

Analise a saída de erro. O template contém dois problemas:
- O parâmetro definido é storageName, mas a referência no recurso usa parameters('storageAccountName'), que não existe.
- O SKU Standard_XRS não é um valor válido para Storage Accounts.
Corrija ambos os erros no arquivo: altere parameters('storageAccountName') para parameters('storageName') e altere Standard_XRS para Standard_LRS.
Execute a validação novamente e confirme que o comando retorna sucesso.

Essa tarefa demonstra a importância da validação pré-deploy. Erros de referência de parâmetro e valores inválidos de SKU são falhas comuns que a validação captura antes de qualquer provisionamento.

Fase 2 — Modificação de ARM Templates e Arquivos Bicep

Nesta fase, você modificará os templates criados na Fase 1 para adicionar novos recursos e configurações. Essa fase cobre os objetivos Modify an existing Azure Resource Manager template e Modify an existing Bicep file. Os templates da Fase 1 serão expandidos progressivamente.

Tarefa 2.1 — Adicionar uma Virtual Network ao ARM Template

A Datastream Analytics precisa provisionar uma Virtual Network junto com a Storage Account. Você modificará o ARM Template da Fase 1 para incluir esse recurso adicional.

Abra o arquivo storage-template.json da Tarefa 1.1.
Adicione dois novos parâmetros na seção parameters:

"vnetName": {
  "type": "string",
  "metadata": {
    "description": "Nome da Virtual Network"
  }
},
"subnetName": {
  "type": "string",
  "defaultValue": "snet-app",
  "metadata": {
    "description": "Nome da Subnet"
  }
}

Adicione o recurso Virtual Network na seção resources, após o recurso de Storage Account:

{
  "type": "Microsoft.Network/virtualNetworks",
  "apiVersion": "2023-05-01",
  "name": "[parameters('vnetName')]",
  "location": "[parameters('location')]",
  "properties": {
    "addressSpace": {
      "addressPrefixes": [
        "10.0.0.0/16"
      ]
    },
    "subnets": [
      {
        "name": "[parameters('subnetName')]",
        "properties": {
          "addressPrefix": "10.0.1.0/24"
        }
      }
    ]
  }
}

Adicione um novo output para o Resource ID da Virtual Network:

"vnetId": {
  "type": "string",
  "value": "[resourceId('Microsoft.Network/virtualNetworks', parameters('vnetName'))]"
}

Valide o template modificado:

Via CLI

az deployment group validate \
  --resource-group rg-datastream-lab \
  --template-file storage-template.json \
  --parameters storageAccountName=stodatastreamlab vnetName=vnet-datastream-prod

Confirme que a validação passa sem erros. O template agora provisiona dois recursos independentes em uma única implantação.

Tarefa 2.2 — Adicionar uma Virtual Network ao arquivo Bicep

Agora aplique a mesma modificação ao arquivo Bicep, adicionando a Virtual Network e explorando as referências simbólicas do Bicep.

Abra o arquivo storage-template.bicep da Tarefa 1.2.
Adicione os novos parâmetros após os parâmetros existentes:

@description('Nome da Virtual Network')
param vnetName string

@description('Nome da Subnet')
param subnetName string = 'snet-app'

Adicione o recurso Virtual Network após o recurso storageAccount:

resource vnet 'Microsoft.Network/virtualNetworks@2023-05-01' = {
  name: vnetName
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: [
        '10.0.0.0/16'
      ]
    }
    subnets: [
      {
        name: subnetName
        properties: {
          addressPrefix: '10.0.1.0/24'
        }
      }
    ]
  }
}

Adicione o output referenciando o nome simbólico:

output vnetId string = vnet.id

Compile e valide:

Via CLI

az bicep build --file storage-template.bicep

az deployment group validate \
  --resource-group rg-datastream-lab \
  --template-file storage-template.bicep \
  --parameters storageAccountName=stodatastreamlab vnetName=vnet-datastream-prod

Observe que o Bicep permite referenciar o recurso pelo nome simbólico (vnet.id) em vez de usar resourceId(). Isso torna o código mais legível e elimina erros de digitação em strings de tipo de recurso.

Tarefa 2.3 — Adicionar dependência explícita e Network Security Group

A equipe de segurança da Datastream Analytics exige que toda Subnet possua um Network Security Group associado. Você adicionará um NSG ao Bicep e criará uma dependência explícita.

Adicione o parâmetro do NSG ao arquivo storage-template.bicep:

@description('Nome do Network Security Group')
param nsgName string = 'nsg-datastream-app'

Adicione o recurso NSG antes da Virtual Network no arquivo:

resource nsg 'Microsoft.Network/networkSecurityGroups@2023-05-01' = {
  name: nsgName
  location: location
  properties: {
    securityRules: [
      {
        name: 'Allow-HTTP-Inbound'
        properties: {
          priority: 100
          direction: 'Inbound'
          access: 'Allow'
          protocol: 'Tcp'
          sourceAddressPrefix: '*'
          sourcePortRange: '*'
          destinationAddressPrefix: '*'
          destinationPortRange: '80'
        }
      }
    ]
  }
}

Modifique o recurso vnet para associar o NSG à Subnet, referenciando-o pelo nome simbólico:

resource vnet 'Microsoft.Network/virtualNetworks@2023-05-01' = {
  name: vnetName
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: [
        '10.0.0.0/16'
      ]
    }
    subnets: [
      {
        name: subnetName
        properties: {
          addressPrefix: '10.0.1.0/24'
          networkSecurityGroup: {
            id: nsg.id
          }
        }
      }
    ]
  }
}

Compile e valide:

Via CLI

az bicep build --file storage-template.bicep

az deployment group validate \
  --resource-group rg-datastream-lab \
  --template-file storage-template.bicep \
  --parameters storageAccountName=stodatastreamlab vnetName=vnet-datastream-prod

Abra o JSON gerado pelo az bicep build e localize a seção dependsOn do recurso Virtual Network. Observe que o Bicep gerou automaticamente uma dependência implícita para o NSG porque nsg.id foi referenciado dentro da definição da VNet.

Ao referenciar um recurso Bicep pelo nome simbólico, o compilador gera automaticamente a dependência dependsOn no ARM Template resultante. Isso evita erros de ordenação de deploy sem necessidade de declarações manuais.

Tarefa 2.4 — Introduzir um erro de modificação e corrigi-lo

Antes de prosseguir ao deploy, simule um erro comum de modificação para validar sua capacidade de diagnóstico.

No arquivo storage-template.bicep, altere intencionalmente o address prefix da Subnet para um valor que conflita com o address space:

addressPrefix: '192.168.1.0/24'

Tente validar o template:

Via CLI

az deployment group validate \
  --resource-group rg-datastream-lab \
  --template-file storage-template.bicep \
  --parameters storageAccountName=stodatastreamlab vnetName=vnet-datastream-prod

Observe a mensagem de erro indicando que o subnet prefix 192.168.1.0/24 não está contido no address space 10.0.0.0/16 da VNet.
Corrija o valor de volta para 10.0.1.0/24 e revalide. Confirme que a validação retorna sucesso.

Esse tipo de erro, onde a subnet não pertence ao address space da VNet, é uma falha frequente em modificações de templates de rede. A validação pré-deploy é a barreira que impede a propagação desse erro para o ambiente.

Fase 3 — Deploy de Recursos Usando ARM Template e Bicep

Nesta fase, você utilizará os templates finalizados nas Fases 1 e 2 para realizar deploys reais no Azure. Essa fase cobre o objetivo Deploy resources by using an Azure Resource Manager template or a Bicep file. Os templates modificados na Fase 2 serão os artefatos de entrada.

Tarefa 3.1 — Executar deploy com o ARM Template via Portal e CLI

Você implantará o ARM Template JSON no Resource Group da Datastream Analytics para provisionar a Storage Account, a Virtual Network com Subnet e o NSG.

Via Portal

Navegue até o Resource Group rg-datastream-lab.
Clique em Create e pesquise por Template deployment (deploy using custom templates).
Clique em Create.
Selecione Build your own template in the editor.
Clique em Load file e selecione o arquivo storage-template.json (a versão final da Fase 2 com VNet e NSG).
Clique em Save.
Preencha os parâmetros:
- storageAccountName: stodatastreamlab
- vnetName: vnet-datastream-prod
- subnetName: snet-app
- skuName: Standard_LRS
Clique em Review + create e depois em Create.
Aguarde a conclusão do deployment. Clique em Go to resource group e verifique que os três recursos (Storage Account, Virtual Network, NSG) foram criados.

Via CLI

# Deploy usando ARM Template JSON
az deployment group create \
  --resource-group rg-datastream-lab \
  --template-file storage-template.json \
  --parameters storageAccountName=stodatastreamlab \
               vnetName=vnet-datastream-prod \
               subnetName=snet-app \
               skuName=Standard_LRS \
  --name deploy-arm-datastream

Verifique os outputs do deployment:

az deployment group show \
  --resource-group rg-datastream-lab \
  --name deploy-arm-datastream \
  --query properties.outputs

O output deve exibir o storageId, primaryEndpoint e vnetId dos recursos provisionados. Esses valores confirmam que os três recursos foram criados e estão acessíveis.

Tarefa 3.2 — Executar deploy com o arquivo Bicep e verificar idempotência

Para validar a equivalência entre ARM e Bicep, você implantará o arquivo Bicep sobre o mesmo Resource Group. Como os recursos já existem com configurações idênticas, o deploy deve ser idempotente.

Antes do deploy, registre o estado atual dos recursos:

Via CLI

# Listar recursos existentes no Resource Group
az resource list \
  --resource-group rg-datastream-lab \
  --output table

Execute o deploy com o arquivo Bicep:

Via Portal

Navegue até o Resource Group rg-datastream-lab.
Clique em Create e pesquise por Template deployment.
Clique em Create e selecione Build your own template in the editor.
Clique em Load file e selecione o arquivo storage-template.bicep.
Preencha os mesmos parâmetros da Tarefa 3.1.
Clique em Review + create e depois em Create.

Via CLI

# Deploy usando Bicep diretamente
az deployment group create \
  --resource-group rg-datastream-lab \
  --template-file storage-template.bicep \
  --parameters storageAccountName=stodatastreamlab \
               vnetName=vnet-datastream-prod \
               subnetName=snet-app \
  --name deploy-bicep-datastream

Verifique que o deployment completou com status Succeeded e que nenhum recurso foi recriado ou alterado:

# Verificar status do deployment
az deployment group show \
  --resource-group rg-datastream-lab \
  --name deploy-bicep-datastream \
  --query properties.provisioningState

Compare a lista de recursos antes e depois do deploy. Nenhum recurso novo deve ter sido criado, confirmando a idempotência.

O Azure Resource Manager compara o estado desejado (template) com o estado atual dos recursos. Quando não há diferença, o deploy completa sem alterações. Essa é a base do modelo declarativo de IaC.

Tarefa 3.3 — Executar deploy com arquivo de parâmetros externo

Em ambientes corporativos, parâmetros são armazenados separadamente dos templates. Crie um arquivo de parâmetros e execute um novo deploy.

Crie o arquivo parameters-prod.json:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "storageAccountName": {
      "value": "stodatastreamlab"
    },
    "vnetName": {
      "value": "vnet-datastream-prod"
    },
    "subnetName": {
      "value": "snet-app"
    },
    "skuName": {
      "value": "Standard_GRS"
    }
  }
}

Observe que o skuName foi alterado para Standard_GRS para simular uma mudança de requisito (a equipe agora exige geo-redundância).
Execute o deploy com o arquivo de parâmetros:

Via CLI

az deployment group create \
  --resource-group rg-datastream-lab \
  --template-file storage-template.bicep \
  --parameters @parameters-prod.json \
  --name deploy-params-datastream

Verifique que a Storage Account foi atualizada para o SKU Standard_GRS:

az storage account show \
  --name stodatastreamlab \
  --resource-group rg-datastream-lab \
  --query sku.name

O output deve exibir Standard_GRS. O deploy com arquivo de parâmetros externo permite reutilizar o mesmo template para diferentes ambientes, alterando apenas os valores dos parâmetros.

Tarefa 3.4 — Diagnosticar e resolver falha de deploy

Simule uma falha de deploy para praticar o diagnóstico de erros em implantações.

Crie um arquivo de parâmetros incorreto chamado parameters-broken.json:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "storageAccountName": {
      "value": "INVALID_NAME_WITH_UPPERCASE"
    },
    "vnetName": {
      "value": "vnet-datastream-prod"
    }
  }
}

Execute o deploy:

Via CLI

az deployment group create \
  --resource-group rg-datastream-lab \
  --template-file storage-template.bicep \
  --parameters @parameters-broken.json \
  --name deploy-broken-datastream

O deploy deve falhar. Analise o erro:

az deployment group show \
  --resource-group rg-datastream-lab \
  --name deploy-broken-datastream \
  --query properties.error

A mensagem de erro indicará que o nome da Storage Account contém caracteres inválidos (maiúsculas e underscores não são permitidos; apenas letras minúsculas e números entre 3 e 24 caracteres).
Para reforçar a prevenção desse tipo de erro, adicione uma restrição ao parâmetro no arquivo Bicep:

@description('Nome da Storage Account')
@minLength(3)
@maxLength(24)
param storageAccountName string

Recompile e valide para confirmar que a restrição está ativa:

az bicep build --file storage-template.bicep

Nomes de Storage Account possuem regras rígidas de nomenclatura no Azure. Adicionar decorators @minLength e @maxLength no Bicep captura parte dessas violações na fase de validação, antes do deploy.

Fase 4 — Exportação e Conversão de Templates

Nesta fase, você exportará deployments existentes como ARM Templates e converterá templates entre os formatos ARM JSON e Bicep. Essa fase cobre o objetivo Export a deployment as an Azure Resource Manager template or convert an Azure Resource Manager template to a Bicep file. Os recursos criados na Fase 3 serão utilizados como base para a exportação.

Tarefa 4.1 — Exportar um deployment como ARM Template

A Datastream Analytics precisa documentar a infraestrutura atualmente implantada. Você exportará o deployment executado na Fase 3 para obter o ARM Template correspondente.

Via Portal

Navegue até o Resource Group rg-datastream-lab.
No menu lateral, clique em Deployments.
Localize e clique no deployment deploy-bicep-datastream (ou o nome utilizado na Tarefa 3.2).
Clique em Template no menu lateral do deployment.
Analise o template exibido. Observe que ele reflete o estado do template no momento do deploy, incluindo todos os parâmetros, variáveis e recursos.
Clique em Download para salvar o template e o arquivo de parâmetros como um arquivo ZIP.

Via CLI

# Exportar o template de um deployment específico
az deployment group export \
  --resource-group rg-datastream-lab \
  --name deploy-bicep-datastream \
  --output json > exported-deployment.json

Abra o arquivo exported-deployment.json e compare com o template original. Observe que o template exportado de um deployment preserva a estrutura original do template utilizado.

A exportação de deployment retorna o template exato que foi enviado ao Resource Manager. Isso difere da exportação de recurso (próxima tarefa), que gera o template a partir do estado atual do recurso.

Tarefa 4.2 — Exportar recursos existentes como ARM Template

Agora exporte os recursos individuais do Resource Group para obter um template baseado no estado atual da infraestrutura.

Via Portal

Navegue até o Resource Group rg-datastream-lab.
No menu lateral, clique em Export template.
Aguarde a geração do template. Observe que o portal gera um ARM Template com todos os recursos do Resource Group.
Analise o template gerado e note as diferenças em relação ao template original: o template exportado inclui todas as propriedades dos recursos (inclusive defaults preenchidos pelo Azure), resultando em um template mais verboso.
Clique em Download para salvar.

Via CLI

# Exportar todos os recursos do Resource Group como template
az group export \
  --name rg-datastream-lab \
  --output json > exported-resources.json

Compare exported-resources.json com o template original. O template exportado conterá propriedades adicionais como provisioningState, resourceGuid e outros valores preenchidos automaticamente pelo Azure que não estavam presentes no template original.
Verifique se o template exportado é válido para reutilização:

az deployment group validate \
  --resource-group rg-datastream-lab \
  --template-file exported-resources.json

Caso a validação falhe (comportamento comum em templates exportados de recursos), analise o erro. Templates exportados frequentemente contêm propriedades read-only que precisam ser removidas antes de reutilização, como provisioningState e IDs gerados automaticamente.

Templates exportados de recursos servem como documentação do estado atual, mas raramente são reutilizáveis sem edição. É uma prática recomendada manter os templates originais versionados em repositório, em vez de depender de exportações.

Tarefa 4.3 — Converter ARM Template para Bicep

A Datastream Analytics decidiu migrar toda a sua base de templates para Bicep. Você converterá o ARM Template exportado para o formato Bicep.

Utilize o template exportado na Tarefa 4.1 (exported-deployment.json) como entrada:

Via CLI

# Converter ARM Template JSON para Bicep
az bicep decompile --file exported-deployment.json

O comando gerará o arquivo exported-deployment.bicep. Abra o arquivo e analise o resultado.
Verifique se o compilador emitiu warnings durante a decompilação. Warnings comuns incluem:
- Propriedades que podem ser removidas por serem valores default.
- Parâmetros que poderiam ser simplificados.
- Referências que foram convertidas de funções ARM para sintaxe Bicep nativa.
Compile o arquivo Bicep gerado para validar a integridade da conversão:

az bicep build --file exported-deployment.bicep

Compare o JSON gerado pelo build com o template original. A estrutura funcional deve ser equivalente, embora a formatação possa diferir.
Para verificar a equivalência funcional, execute um what-if com o arquivo Bicep convertido:

az deployment group what-if \
  --resource-group rg-datastream-lab \
  --template-file exported-deployment.bicep \
  --parameters storageAccountName=stodatastreamlab \
               vnetName=vnet-datastream-prod

O what-if deve indicar no changes (ou apenas alterações cosméticas) para os recursos já existentes, confirmando que a conversão preservou a semântica do template.

A decompilação de ARM para Bicep não é sempre perfeita. O comando az bicep decompile realiza uma conversão de melhor esforço, e o resultado pode exigir ajustes manuais para seguir as melhores práticas do Bicep (como substituir variáveis desnecessárias por referências diretas).

Tarefa 4.4 — Converter Bicep para ARM Template e validar ciclo completo

Para fechar o ciclo de conversão, converta o arquivo Bicep original para ARM Template e valide que o processo é bidirecional.

Converta o arquivo Bicep final da Fase 2:

Via CLI

# Compilar Bicep para ARM Template
az bicep build --file storage-template.bicep --outfile storage-from-bicep.json

Compare storage-from-bicep.json com o storage-template.json original. Observe que o JSON gerado pelo compilador Bicep é funcional, mas pode apresentar diferenças de formatação (ordem de propriedades, espaçamento).
Agora converta o JSON gerado de volta para Bicep:

az bicep decompile --file storage-from-bicep.json

Compare storage-from-bicep.bicep com storage-template.bicep. O round-trip (Bicep para JSON para Bicep) pode introduzir diferenças estilísticas, como nomes de variáveis renomeados ou parâmetros reorganizados, mas a funcionalidade deve ser equivalente.
Valide o ciclo completo executando what-if com o arquivo resultante do round-trip:

az deployment group what-if \
  --resource-group rg-datastream-lab \
  --template-file storage-from-bicep.bicep \
  --parameters storageAccountName=stodatastreamlab \
               vnetName=vnet-datastream-prod

Confirme que o resultado mostra no changes nos recursos existentes.

O ciclo de conversão demonstra que ARM e Bicep são interoperáveis. A compilação Bicep para JSON é lossless (sem perda de informação), enquanto a decompilação JSON para Bicep é best-effort e pode exigir refinamentos manuais.

Validação Final

Após concluir todas as fases, verifique os critérios abaixo para confirmar que o laboratório foi executado corretamente.

Critério 1 — Recursos provisionados: Execute az resource list --resource-group rg-datastream-lab --output table e confirme que os seguintes recursos estão presentes: Storage Account (stodatastreamlab), Virtual Network (vnet-datastream-prod), Network Security Group (nsg-datastream-app).

Critério 2 — Storage Account com SKU correto: Execute az storage account show --name stodatastreamlab --resource-group rg-datastream-lab --query sku.name e confirme que o output é Standard_GRS (alterado na Tarefa 3.3 via arquivo de parâmetros).

Critério 3 — NSG associado à Subnet: Execute az network vnet subnet show --resource-group rg-datastream-lab --vnet-name vnet-datastream-prod --name snet-app --query networkSecurityGroup.id e confirme que o output contém o ID do NSG nsg-datastream-app.

Critério 4 — Validação comportamental via regra de NSG: Execute um teste que confirme que a regra de NSG permite tráfego HTTP (porta 80). Navegue no portal até rg-datastream-lab > nsg-datastream-app > Inbound security rules e confirme que a regra Allow-HTTP-Inbound está listada com prioridade 100, acesso Allow, protocolo TCP e porta de destino 80. Alternativamente, via CLI: az network nsg rule list --resource-group rg-datastream-lab --nsg-name nsg-datastream-app --output table e verifique a presença e os atributos da regra.

Critério 5 — Arquivos Bicep compiláveis: Execute az bicep build --file storage-template.bicep e confirme que nenhum erro é emitido. Execute az bicep build --file exported-deployment.bicep (da Tarefa 4.3) e confirme que a compilação também é bem-sucedida.

Cleanup do Ambiente

Remova todos os recursos criados durante o laboratório para evitar cobranças desnecessárias. A exclusão do Resource Group principal remove todos os recursos filhos automaticamente.

Via Portal

Navegue até Resource groups.
Localize e clique em rg-datastream-lab.
Clique em Delete resource group.
No campo de confirmação, digite o nome rg-datastream-lab.
Clique em Delete.
Aguarde a conclusão. Navegue novamente até Resource groups e confirme que rg-datastream-lab não está mais listado.

Via CLI

# Remover o Resource Group e todos os recursos contidos
az group delete \
  --name rg-datastream-lab \
  --yes \
  --no-wait

Para confirmar que a exclusão foi concluída:

az group exists --name rg-datastream-lab

O output deve ser false, indicando que o Resource Group e todos os seus recursos foram eliminados com sucesso.

Remova também os arquivos locais criados durante o laboratório (templates JSON, arquivos Bicep e outputs de exportação) do diretório de trabalho.

Cenário​

Pré-requisitos​

Via Portal​

Via CLI​

Tabela de Referência de Recursos​

Fases do Laboratório​

Fase 1 — Interpretação de ARM Templates e Arquivos Bicep​

Tarefa 1.1 — Analisar a estrutura de um ARM Template existente​

Via CLI​

Tarefa 1.2 — Analisar a estrutura de um arquivo Bicep equivalente​

Via CLI​

Tarefa 1.3 — Identificar e corrigir erros deliberados em templates​

Via CLI​

Fase 2 — Modificação de ARM Templates e Arquivos Bicep​

Tarefa 2.1 — Adicionar uma Virtual Network ao ARM Template​

Via CLI​

Tarefa 2.2 — Adicionar uma Virtual Network ao arquivo Bicep​

Via CLI​

Tarefa 2.3 — Adicionar dependência explícita e Network Security Group​

Via CLI​

Tarefa 2.4 — Introduzir um erro de modificação e corrigi-lo​

Via CLI​

Fase 3 — Deploy de Recursos Usando ARM Template e Bicep​

Tarefa 3.1 — Executar deploy com o ARM Template via Portal e CLI​

Via Portal​

Via CLI​

Tarefa 3.2 — Executar deploy com o arquivo Bicep e verificar idempotência​

Via CLI​

Via Portal​

Via CLI​

Tarefa 3.3 — Executar deploy com arquivo de parâmetros externo​

Via CLI​

Tarefa 3.4 — Diagnosticar e resolver falha de deploy​

Via CLI​

Fase 4 — Exportação e Conversão de Templates​

Tarefa 4.1 — Exportar um deployment como ARM Template​

Via Portal​

Via CLI​

Tarefa 4.2 — Exportar recursos existentes como ARM Template​

Via Portal​

Via CLI​

Tarefa 4.3 — Converter ARM Template para Bicep​

Via CLI​

Tarefa 4.4 — Converter Bicep para ARM Template e validar ciclo completo​

Via CLI​

Validação Final​

Cleanup do Ambiente​

Via Portal​

Via CLI​

Cenário

Pré-requisitos

Via Portal

Via CLI

Tabela de Referência de Recursos

Fases do Laboratório

Fase 1 — Interpretação de ARM Templates e Arquivos Bicep

Tarefa 1.1 — Analisar a estrutura de um ARM Template existente

Via CLI

Tarefa 1.2 — Analisar a estrutura de um arquivo Bicep equivalente

Via CLI

Tarefa 1.3 — Identificar e corrigir erros deliberados em templates

Via CLI

Fase 2 — Modificação de ARM Templates e Arquivos Bicep

Tarefa 2.1 — Adicionar uma Virtual Network ao ARM Template

Via CLI

Tarefa 2.2 — Adicionar uma Virtual Network ao arquivo Bicep

Via CLI

Tarefa 2.3 — Adicionar dependência explícita e Network Security Group

Via CLI

Tarefa 2.4 — Introduzir um erro de modificação e corrigi-lo

Via CLI

Fase 3 — Deploy de Recursos Usando ARM Template e Bicep

Tarefa 3.1 — Executar deploy com o ARM Template via Portal e CLI

Via Portal

Via CLI

Tarefa 3.2 — Executar deploy com o arquivo Bicep e verificar idempotência

Via CLI

Via Portal

Via CLI

Tarefa 3.3 — Executar deploy com arquivo de parâmetros externo

Via CLI

Tarefa 3.4 — Diagnosticar e resolver falha de deploy

Via CLI

Fase 4 — Exportação e Conversão de Templates

Tarefa 4.1 — Exportar um deployment como ARM Template

Via Portal

Via CLI

Tarefa 4.2 — Exportar recursos existentes como ARM Template

Via Portal

Via CLI

Tarefa 4.3 — Converter ARM Template para Bicep

Via CLI

Tarefa 4.4 — Converter Bicep para ARM Template e validar ciclo completo

Via CLI

Validação Final

Cleanup do Ambiente

Via Portal

Via CLI