Laboratório Técnico: Modify an existing Bicep file
Questões
Questão 1 — Múltipla Escolha
Um administrador precisa adicionar uma tag obrigatória em todos os recursos de um template Bicep existente sem duplicar a declaração em cada recurso individualmente. O arquivo já possui um módulo principal que instancia múltiplos recursos.
Qual abordagem é a mais adequada para centralizar a definição da tag nesse cenário?
A) Declarar a tag diretamente no bloco resource de cada recurso, pois o Bicep não oferece mecanismo de herança de tags.
B) Definir a tag como param no nível do arquivo e referenciar o parâmetro no bloco tags de cada recurso.
C) Utilizar um var no nível do arquivo com o objeto de tags e referenciar a variável no bloco tags de cada recurso.
D) Criar um arquivo .bicepparam separado e importar as tags via using.
Questão 2 — Cenário Técnico
Um administrador está modificando o seguinte trecho de um arquivo Bicep existente para adicionar uma nova propriedade ao recurso:
resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
name: storageName
location: location
sku: {
name: 'Standard_LRS'
}
kind: 'StorageV2'
properties: {
supportsHttpsTrafficOnly: true
}
}
Ao adicionar allowBlobPublicAccess: false dentro de properties, o deploy retorna o erro:
The resource type 'storageAccounts' does not support property 'allowBlobPublicAccess' in api-version '2023-01-01'.
Qual é a causa e a correção apropriada?
A) A propriedade allowBlobPublicAccess foi removida da API; deve-se usar publicNetworkAccess: 'Disabled' como substituto.
B) A versão da API declarada no tipo do recurso não suporta a propriedade; deve-se atualizar a versão da API para uma que inclua essa propriedade.
C) O Bicep não permite adicionar propriedades booleanas dentro de properties; a propriedade deve ser movida para o nível raiz do recurso.
D) O erro indica que o arquivo Bicep está corrompido e precisa ser recompilado com az bicep build antes do deploy.
Questão 3 — Verdadeiro ou Falso
Afirmação: Ao modificar um arquivo Bicep para alterar o valor de uma propriedade marcada como immutable na API do Azure (como o kind de uma Storage Account), o comando az deployment group create com a flag --mode Incremental irá falhar, pois o Azure não permite alterar propriedades imutáveis mesmo em deployments incrementais.
A afirmação é verdadeira ou falsa?
Questão 4 — Cenário Técnico
Um administrador herda o arquivo Bicep abaixo e precisa tornar o SKU da Storage Account configurável por ambiente, sem alterar a lógica de deploy já existente:
param environment string = 'prod'
var skuName = 'Standard_LRS'
resource storageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = {
name: 'staccount${environment}'
location: resourceGroup().location
sku: {
name: skuName
}
kind: 'StorageV2'
properties: {
supportsHttpsTrafficOnly: true
}
}
O requisito é: em prod, usar Standard_GRS; em qualquer outro ambiente, usar Standard_LRS. Qual modificação no arquivo atende ao requisito com a menor mudança estrutural?
A) Substituir var skuName = 'Standard_LRS' por param skuName string e passar o valor correto no momento do deploy.
B) Substituir var skuName = 'Standard_LRS' por var skuName = environment == 'prod' ? 'Standard_GRS' : 'Standard_LRS'.
C) Adicionar um segundo parâmetro param skuName string = 'Standard_GRS' e usar um if no bloco do recurso para selecionar o SKU.
D) Criar um arquivo de parâmetros .bicepparam com dois perfis e referenciar a variável skuName via using.
Questão 5 — Múltipla Escolha
Ao modificar um arquivo Bicep existente, um administrador precisa referenciar o id de um recurso que já existe na assinatura, mas que não é declarado no arquivo Bicep atual. O recurso é uma Virtual Network em outro resource group.
Qual é a forma correta de referenciar esse recurso existente no Bicep?
A) Declarar o recurso normalmente com resource vnet 'Microsoft.Network/virtualNetworks@...' = { ... } e omitir as propriedades obrigatórias.
B) Usar a função resourceId() com o resource group correto para construir o ID diretamente como string.
C) Declarar o recurso com a palavra-chave existing e, se estiver em outro resource group, usar o escopo com resourceGroup().
D) Importar o recurso via módulo Bicep apontando para um arquivo .bicep vazio que declare apenas o output do id.
Gabarito e Explicações
Gabarito — Questão 1
Resposta: C
Explicar com um var do tipo objeto centraliza a definição de tags em um único ponto do arquivo. Qualquer recurso pode referenciar tags: tagObject sem duplicação. Isso é a abordagem idiomática em Bicep para valores reutilizados que não precisam ser expostos como parâmetros externos.
A alternativa B também funcionaria tecnicamente, mas expõe as tags como entrada externa, o que não é adequado para tags fixas e internas ao template. A alternativa D (bicepparam) é usada para fornecer valores de parâmetros no momento do deploy, não para centralizar lógica interna do template. A alternativa A está incorreta: o Bicep permite sim variáveis e parâmetros reutilizados em múltiplos blocos resource.
Gabarito — Questão 2
Resposta: B
O erro indica explicitamente que a versão da API usada (2023-01-01) não reconhece a propriedade allowBlobPublicAccess. Cada versão da API do Azure Resource Manager expõe um conjunto específico de propriedades; propriedades introduzidas em versões posteriores não estão disponíveis em versões anteriores. A correção é atualizar a versão da API no tipo do recurso para uma que inclua essa propriedade.
A alternativa A é uma confusão comum: publicNetworkAccess controla o acesso à rede, não o acesso público a blobs especificamente. A alternativa C está errada: o Bicep suporta propriedades booleanas em qualquer nível. A alternativa D não tem fundamento técnico: az bicep build compila o arquivo Bicep para ARM JSON, mas não resolve incompatibilidades de versão de API.
Gabarito — Questão 3
Resposta: Verdadeiro
O modo Incremental do Azure Resource Manager aplica apenas as alterações definidas no template, mas ainda assim tenta atualizar as propriedades declaradas. Se uma propriedade é imutável na API (como kind em Storage Accounts), a API do Azure rejeitará a operação com erro, independentemente do modo de deployment. O modo Incremental não ignora erros de validação da API; ele apenas omite recursos não declarados no template. Essa é uma distinção importante: Incremental versus Complete define o que acontece com recursos ausentes do template, não como a API trata propriedades imutáveis.
Gabarito — Questão 4
Resposta: B
Substituir a var por uma expressão ternária que avalia o parâmetro environment já existente é a menor mudança estrutural possível. O parâmetro environment já está declarado, a variável skuName já está referenciada no recurso; basta alterar o valor da variável para uma expressão condicional. Nenhuma nova declaração é necessária.
A alternativa A transforma a lógica em responsabilidade externa (quem faz o deploy precisa saber qual SKU usar por ambiente), o que viola o requisito de manter a lógica de decisão no template. A alternativa C introduz um segundo parâmetro desnecessário e usa if de forma incorreta, pois o Bicep usa o operador ternário ? : para expressões condicionais em valores de propriedade, não blocos if. A alternativa D introduz complexidade desnecessária para um requisito de lógica condicional simples.
Gabarito — Questão 5
Resposta: C
A palavra-chave existing instrui o Bicep a referenciar um recurso já provisionado sem tentar criá-lo ou modificá-lo. Para recursos em outros resource groups, combina-se existing com a propriedade scope apontando para resourceGroup('<nome-do-rg>'). Após essa declaração, o id, o name e outras propriedades do recurso ficam acessíveis via a referência simbólica.
A alternativa A causaria uma tentativa de deploy do recurso, o que falharia sem as propriedades obrigatórias. A alternativa B funciona para construir o ID como string, mas perde a tipagem e a capacidade de acessar outras propriedades do recurso de forma segura; além disso, não é a abordagem recomendada quando o Bicep oferece existing nativamente. A alternativa D é tecnicamente impraticável e não representa um padrão suportado pelo Bicep.