Pular para o conteúdo principal

Laboratório Técnico: Interpret an Azure Resource Manager template or a Bicep file

Questões​

Questão 1 — Múltipla Escolha​

Um administrador analisa o seguinte trecho de um template ARM:

"parameters": {
  "storageAccountName": {
    "type": "string",
    "defaultValue": "mystorage",
    "allowedValues": [
      "mystorage",
      "prodstorage"
    ]
  }
}

Durante o deploy, o operador passa o valor "devstorage" via linha de comando. Qual é o comportamento esperado?

A) O deploy é concluído com o valor "devstorage", pois parâmetros passados em tempo de execução sempre substituem defaultValue e allowedValues.

B) O deploy falha na validação, porque o valor fornecido não está na lista de allowedValues.

C) O deploy usa "mystorage" como fallback, ignorando o valor inválido passado pelo operador.

D) O deploy falha apenas se "devstorage" contiver caracteres inválidos para o tipo string.

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

Uma equipe precisa implantar múltiplos ambientes (dev, staging, prod) usando o mesmo template ARM. A única diferença entre os ambientes é o SKU do plano do App Service. O template atual hardcoda o valor "S1" diretamente na propriedade sku:

"sku": {
  "name": "S1",
  "tier": "Standard"
}

O time quer que o SKU seja definido em tempo de deploy sem alterar o template. Qual é a abordagem correta?

A) Criar três templates separados, um por ambiente, substituindo o valor do SKU em cada um.

B) Substituir o valor hardcoded por uma referência a um parâmetro e passar o valor durante o deploy.

C) Usar a função variables() para definir o SKU dinamicamente com base no nome do resource group.

D) Usar a função environment() para selecionar automaticamente o SKU com base no ambiente Azure detectado.

Questão 3 — Verdadeiro ou Falso​

Em um arquivo Bicep, é possível referenciar o valor de saída de um módulo filho diretamente em outro recurso do arquivo pai, desde que o módulo filho tenha declarado esse valor na seção output.

Verdadeiro ou Falso?

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

Um engenheiro revisa o seguinte trecho de template ARM e recebe um erro de validação ao fazer o deploy:

"resources": [
  {
    "type": "Microsoft.Storage/storageAccounts",
    "apiVersion": "2022-09-01",
    "name": "[parameters('storageName')]",
    "location": "[resourceGroup().location]",
    "sku": {
      "name": "Standard_LRS"
    },
    "kind": "StorageV2"
  },
  {
    "type": "Microsoft.Web/sites",
    "apiVersion": "2022-03-01",
    "name": "[parameters('appName')]",
    "location": "[resourceGroup().location]",
    "properties": {
      "storageEndpoint": "[reference(parameters('storageName')).primaryEndpoints.blob]"
    }
  }
]

O erro indica que a propriedade storageEndpoint não pode ser resolvida. Qual é a causa mais provável?

A) A função reference() só pode ser usada dentro de outputs, não em properties de outros recursos.

B) O recurso Microsoft.Web/sites não declara uma dependência explícita da storage account, e o ARM pode tentar resolver a referência antes que o recurso exista.

C) A função reference() exige o resourceId() completo como argumento; usar apenas o nome do parâmetro é inválido em todos os contextos.

D) A propriedade storageEndpoint não é suportada pelo tipo Microsoft.Web/sites e o template é sintaticamente inválido.

Questão 5 — Múltipla Escolha​

Ao interpretar um arquivo Bicep, um analista encontra o seguinte trecho:

var location = resourceGroup().location

resource storageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = {
  name: storageAccountName
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
}

output blobEndpoint string = storageAccount.properties.primaryEndpoints.blob

Qual afirmação descreve corretamente o comportamento do bloco output nesse arquivo?

A) O valor de blobEndpoint é avaliado durante a compilação do Bicep para ARM JSON, antes do deploy.

B) O valor de blobEndpoint só fica disponível após a conclusão do deploy, pois depende de uma propriedade resolvida em tempo de execução pelo Azure.

C) O bloco output força o recurso storageAccount a ser criado antes de qualquer outro recurso no mesmo template.

D) O bloco output é opcional em arquivos Bicep e, se removido, o recurso storageAccount não será implantado.

Gabarito e Explicações​

Gabarito — Questão 1​

Resposta: B

O campo allowedValues define um conjunto restrito de valores aceitos para o parâmetro. Quando um valor é passado durante o deploy, o ARM o valida contra essa lista antes de iniciar qualquer implantação. Como "devstorage" não está em ["mystorage", "prodstorage"], o deploy falha na fase de validação do template, não durante a criação do recurso.

O erro conceitual central dos distratores é tratar allowedValues como uma sugestão ou como um fallback silencioso. Na realidade, ele é uma restrição de validação aplicada pelo Azure antes do deploy começar. O defaultValue só é usado quando nenhum valor é fornecido pelo operador, não como substituto de um valor inválido.

Gabarito — Questão 2​

Resposta: B

A forma correta de parametrizar valores que variam entre ambientes é declarar um parâmetro no template e referenciar esse parâmetro com [parameters('nomeDoPar')] no lugar do valor hardcoded. Assim, o mesmo template pode ser reutilizado com valores diferentes passados via -TemplateParameterObject, arquivo de parâmetros ou linha de comando.

A alternativa C confunde o papel de variables(): variáveis são calculadas internamente no template e não recebem entrada externa. A alternativa D usa environment() de forma incorreta; essa função retorna metadados sobre o ambiente Azure (como endpoints de nuvem soberana), não seleciona SKUs com base em contexto de negócio.

Gabarito — Questão 3​

Resposta: Verdadeiro

Em Bicep, quando um módulo declara valores na seção output, esses valores ficam acessíveis no arquivo pai por meio da sintaxe nomeDoModulo.outputs.nomeDoOutput. O arquivo pai pode usar esse valor como entrada para outro recurso ou módulo, desde que a dependência seja corretamente inferida ou explicitada.

Esse mecanismo é central para composição modular em Bicep e é uma diferença significativa em relação ao ARM JSON puro, onde encadear outputs entre recursos aninhados exige mais verbosidade. A dependência entre o módulo filho e o recurso pai que consome o output é inferida automaticamente pelo compilador Bicep.

Gabarito — Questão 4​

Resposta: B

O ARM implanta recursos em paralelo por padrão quando não há dependência declarada. No template apresentado, o recurso Microsoft.Web/sites usa reference() para acessar uma propriedade da storage account, mas não declara "dependsOn" apontando para ela. Sem essa declaração, o ARM pode tentar resolver a referência antes que a storage account exista, causando o erro.

A solução é adicionar "dependsOn": ["[resourceId('Microsoft.Storage/storageAccounts', parameters('storageName'))]"] ao recurso Web. A alternativa C é parcialmente verdadeira em alguns contextos, mas não é a causa do erro aqui: reference() aceita nomes simples quando o recurso está no mesmo template e no mesmo resource group. A alternativa A é falsa; reference() é amplamente usada em properties.

Gabarito — Questão 5​

Resposta: B

Valores declarados em output que dependem de propriedades de recursos, como primaryEndpoints.blob, só são resolvidos após a conclusão do deploy. Essas propriedades são geradas pelo Azure durante a criação do recurso e não existem antes disso. O bloco output instrui o ARM a capturar e retornar esse valor ao final da implantação.

A alternativa A representa um equívoco frequente: confundir a compilação do Bicep para ARM JSON (que é estática e local) com a resolução de valores de runtime feita pelo Azure. A compilação transforma a sintaxe, mas não executa nem avalia propriedades de recursos. As alternativas C e D são falsas: output não controla ordem de criação e não tem relação com a decisão de implantar ou não um recurso.