Pular para o conteúdo principal

Laboratório Técnico: Deploy resources by using an Azure Resource Manager template or a Bicep file

Questões​

Questão 1 — Múltipla Escolha​

Durante a revisão de um pipeline de implantação, um engenheiro analisa o seguinte trecho de um template ARM:

{
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2022-09-01",
      "name": "[parameters('storageName')]",
      "location": "[resourceGroup().location]",
      "sku": {
        "name": "Standard_LRS"
      },
      "kind": "StorageV2",
      "dependsOn": [
        "[resourceId('Microsoft.Network/virtualNetworks', parameters('vnetName'))]"
      ]
    }
  ]
}

O template implanta a storage account e uma VNet em recursos separados. A implantação falha com erro de dependência circular. Qual é a causa mais provável?

A) O campo dependsOn não é suportado para recursos do tipo Microsoft.Storage/storageAccounts.

B) O recurso da VNet, em outro ponto do template, também declara dependsOn apontando para a storage account, criando uma dependência mútua.

C) O ARM resolve dependências implicitamente via reference() e ignora o dependsOn explícito, gerando conflito interno.

D) A função resourceId() dentro de dependsOn é inválida; o valor correto seria o nome do recurso diretamente como string.

Questão 2 — Cenário Técnico​

Uma equipe precisa implantar a mesma infraestrutura em três ambientes distintos: dev, staging e prod. Cada ambiente deve usar SKUs diferentes para os recursos. A equipe optou por Bicep e criou um único arquivo main.bicep. Para diferenciar os ambientes, o tech lead propõe duas abordagens:

Abordagem X: Usar um parâmetro env do tipo string e, dentro do arquivo, utilizar expressões condicionais com o operador ternário para definir os SKUs com base no valor recebido.

Abordagem Y: Criar três arquivos .bicepparam separados, cada um fornecendo os valores de parâmetros adequados para seu respectivo ambiente, e referenciar o mesmo main.bicep.

Considerando as práticas recomendadas para reutilização, rastreabilidade e manutenção do código Bicep, qual afirmação descreve melhor a relação entre as duas abordagens?

A) A Abordagem X é preferível porque centraliza toda a lógica no arquivo principal, eliminando a necessidade de arquivos adicionais.

B) A Abordagem Y é a única tecnicamente válida; arquivos .bicepparam são obrigatórios para implantações multi-ambiente no Bicep.

C) As duas abordagens são funcionalmente equivalentes, mas a Abordagem Y favorece a separação entre lógica de infraestrutura e valores de configuração, o que melhora rastreabilidade por ambiente.

D) A Abordagem X não é suportada pelo Bicep; o operador ternário só está disponível em templates ARM no formato JSON.

Questão 3 — Verdadeiro ou Falso​

Afirmação: Em um template ARM, quando dois recursos não possuem dependência declarada explicitamente via dependsOn e nenhum deles referencia o outro com a função reference() ou resourceId() dentro de suas propriedades, o Azure Resource Manager os implanta obrigatoriamente em sequência, aguardando a conclusão do primeiro antes de iniciar o segundo.

Verdadeiro ou Falso?

Questão 4 — Cenário Técnico​

Um administrador executa o seguinte comando para implantar um arquivo Bicep:

az deployment group create \
  --resource-group rg-production \
  --template-file main.bicep \
  --mode Complete

Após a implantação bem-sucedida, o administrador percebe que dois recursos que existiam no grupo de recursos antes da execução foram deletados, embora não estivessem definidos no arquivo main.bicep. Nenhum erro foi retornado.

Qual é a explicação correta para esse comportamento?

A) O modo Complete exclui recursos do grupo de recursos que não estão declarados no template, sendo esse o comportamento esperado e documentado.

B) O comando apresenta um bug conhecido da CLI do Azure; o modo Complete deveria ser ignorado em implantações de grupo de recursos.

C) O modo Complete só exclui recursos se o parâmetro --confirm-with-what-if for omitido; o administrador deveria tê-lo incluído para evitar a exclusão.

D) Os recursos foram excluídos porque o template continha um bloco outputs que referenciava apenas os recursos definidos, sinalizando ao ARM que os demais deveriam ser removidos.

Questão 5 — Múltipla Escolha​

Um time de operações precisa implantar um conjunto de recursos de rede em múltiplos grupos de recursos dentro da mesma assinatura. Eles possuem um único arquivo Bicep que descreve todos os recursos. Qual escopo de implantação e qual comando são mais adequados para essa necessidade?

A) Escopo resourceGroup; o time deve executar az deployment group create uma vez por grupo de recursos, passando o mesmo arquivo Bicep com parâmetros diferentes.

B) Escopo subscription; o time deve usar az deployment sub create e declarar targetScope = 'subscription' no Bicep, usando módulos com scope explícito apontando para cada grupo de recursos.

C) Escopo managementGroup; é o único escopo que permite implantar recursos em múltiplos grupos de recursos simultaneamente dentro de uma assinatura.

D) Escopo tenant; implantações que cruzam grupos de recursos exigem permissões de nível de tenant e o comando az deployment tenant create.

Gabarito e Explicações​

Gabarito — Questão 1​

Resposta: B

O ARM detecta dependência circular quando dois ou mais recursos se referenciam mutuamente como pré-requisito. Se o recurso da VNet, em outro trecho do mesmo template, declara dependsOn apontando para a storage account, e a storage account declara dependsOn apontando para a VNet, o motor de orquestração não consegue determinar uma ordem de criação válida e falha.

O principal equívoco representado pelos distratores está em atribuir a falha a restrições sintáticas ou de função: dependsOn é suportado para qualquer tipo de recurso, resourceId() dentro de dependsOn é uso correto e documentado, e o ARM não ignora dependsOn quando reference() também está presente. Escolher a alternativa A ou D levaria o engenheiro a modificar uma sintaxe válida sem resolver o problema real de design do template.

Gabarito — Questão 2​

Resposta: C

Arquivos .bicepparam foram introduzidos exatamente para separar os valores de parâmetros específicos de ambiente da lógica de infraestrutura contida no arquivo .bicep. Isso permite que main.bicep permaneça agnóstico ao ambiente e que cada arquivo .bicepparam seja versionado, revisado e auditado de forma independente.

A Abordagem X é tecnicamente funcional, e o operador ternário é válido no Bicep. No entanto, centralizar a lógica de seleção de SKU dentro do arquivo principal mistura responsabilidades e dificulta auditar o que exatamente foi implantado em cada ambiente. A alternativa B está errada porque arquivos .bicepparam não são obrigatórios; são uma prática recomendada. Escolher A levaria a um código mais difícil de manter à medida que o número de ambientes ou variações cresce.

Gabarito — Questão 3​

Resposta: Falso

Quando não há dependência explícita nem implícita entre recursos, o ARM os implanta em paralelo, não em sequência. O motor de orquestração do ARM é projetado para maximizar a paralelização, iniciando todos os recursos sem dependências declaradas simultaneamente. Assumir implantação sequencial como padrão é um equívoco comum que leva a templates com dependsOn desnecessários, aumentando o tempo total de implantação sem qualquer benefício. A sequência só é garantida quando há dependência declarada ou inferida pelo uso de reference() ou resourceId() dentro das propriedades de um recurso.

Gabarito — Questão 4​

Resposta: A

O modo Complete instrui o ARM a tratar o template como a definição completa e desejada do grupo de recursos. Qualquer recurso presente no grupo que não esteja declarado no template é excluído ao final de uma implantação bem-sucedida. Esse é o comportamento documentado e intencional, projetado para manter o estado do ambiente em conformidade estrita com o template.

O modo Incremental, que é o padrão, apenas adiciona ou atualiza recursos declarados no template, sem remover os que não constam nele. A confusão entre os dois modos é uma das causas mais comuns de exclusões acidentais em produção. O parâmetro --confirm-with-what-if não altera o modo de implantação; ele apenas simula as mudanças antes de executá-las, sendo uma boa prática de segurança, mas não um mecanismo de proteção automática.

Gabarito — Questão 5​

Resposta: B

Para implantar recursos em múltiplos grupos de recursos dentro da mesma assinatura a partir de um único arquivo Bicep, o escopo correto é subscription. O arquivo deve declarar targetScope = 'subscription' e utilizar módulos Bicep com o atributo scope apontando explicitamente para cada grupo de recursos alvo. O comando correspondente é az deployment sub create.

O escopo resourceGroup exigiria execuções independentes do comando, o que não satisfaz a premissa de uma implantação coordenada a partir de um único arquivo. O escopo managementGroup opera acima das assinaturas e é usado para implantar recursos em múltiplas assinaturas, não para cruzar grupos de recursos dentro de uma mesma assinatura. O escopo tenant é reservado para recursos de nível de tenant, como definições de política globais, e não resolve o cenário descrito.