Laboratório Técnico: Modify an existing Azure Resource Manager template
Questões
Questão 1 — Múltipla Escolha
Você possui o seguinte trecho de um template ARM e precisa tornar o nome da conta de armazenamento configurável em tempo de implantação, sem alterar o comportamento padrão atual:
{
"type": "Microsoft.Storage/storageAccounts",
"name": "minhaconta2024",
"apiVersion": "2023-01-01",
"location": "[resourceGroup().location]",
"sku": {
"name": "Standard_LRS"
},
"kind": "StorageV2"
}
Qual modificação atende corretamente a esse requisito?
A) Substituir "minhaconta2024" por "[variables('storageAccountName')]" e definir a variável com o valor "minhaconta2024" na seção variables.
B) Substituir "minhaconta2024" por "[parameters('storageAccountName')]" e adicionar o parâmetro na seção parameters com "defaultValue": "minhaconta2024".
C) Substituir "minhaconta2024" por "[parameters('storageAccountName')]" e adicionar o parâmetro na seção parameters sem defaultValue.
D) Adicionar uma entrada na seção outputs que exponha o nome atual e reutilizá-lo via "[outputs('storageAccountName').value]" no campo name.
Questão 2 — Cenário Técnico
Uma equipe recebeu o template ARM abaixo para implantar uma máquina virtual. Durante a revisão, um engenheiro identificou que a implantação falhará antes mesmo de atingir o provisionamento da VM.
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"adminPassword": {
"type": "string"
}
},
"variables": {
"vmName": "prod-vm-01"
},
"resources": [
{
"type": "Microsoft.Compute/virtualMachines",
"apiVersion": "2023-03-01",
"name": "[variables('vmName')]",
"location": "[resourceGroup().location]",
"properties": {
"osProfile": {
"adminUsername": "azureadmin",
"adminPassword": "[parameters('adminPassword')]"
}
}
}
]
}
Qual é o problema que causará a falha?
A) O parâmetro adminPassword não declara "type": "securestring", o que é rejeitado pelo Azure Resource Manager para campos de senha.
B) A função [variables('vmName')] não pode ser usada no campo name de um recurso; o nome deve ser um valor literal ou derivado de parâmetros.
C) A seção properties.osProfile está incompleta porque não contém o campo obrigatório computerName.
D) O valor de apiVersion está incorreto para o tipo Microsoft.Compute/virtualMachines e causará erro de validação de schema.
Questão 3 — Verdadeiro ou Falso
A função copyIndex() em um template ARM, quando usada dentro de um loop copy sem argumento, retorna sempre um valor iniciado em 0 e pode ser combinada com copyIndex(1) para iniciar a contagem em 1, sem que isso afete o número total de iterações definido em count.
Questão 4 — Cenário Técnico
Você precisa modificar um template ARM existente para que um recurso Microsoft.Network/publicIPAddresses seja implantado somente quando um parâmetro booleano deployPublicIP tiver o valor true. O trecho atual do recurso é:
{
"type": "Microsoft.Network/publicIPAddresses",
"apiVersion": "2023-05-01",
"name": "pip-prod",
"location": "[resourceGroup().location]",
"sku": { "name": "Standard" },
"properties": {
"publicIPAllocationMethod": "Static"
}
}
Qual modificação implementa corretamente a implantação condicional?
A) Adicionar "dependsOn": ["[parameters('deployPublicIP')]"] ao recurso para criar uma dependência condicional.
B) Envolver o objeto do recurso em uma instrução if no nível do JSON, como "if": "[parameters('deployPublicIP')]": { ... }.
C) Adicionar a propriedade "condition": "[parameters('deployPublicIP')]" diretamente no objeto do recurso.
D) Mover o recurso para a seção outputs e usar "condition" dentro do output para controlar sua criação.
Questão 5 — Múltipla Escolha
Ao modificar um template ARM para referenciar um recurso que será criado na mesma implantação, qual das seguintes abordagens garante que o Azure Resource Manager resolva a dependência corretamente e implante os recursos na ordem adequada?
A) Usar "dependsOn" com o resourceId() completo do recurso dependente, incluindo subscription e resource group.
B) Usar "dependsOn" com o formato "[resourceId('tipo/recurso', 'nome')]" ou simplesmente com o nome simbólico do recurso.
C) Usar a função reference() no campo properties do recurso dependente, o que implicitamente cria uma dependência sem necessidade de dependsOn.
D) Declarar os recursos na ordem correta dentro do array resources, pois o ARM respeita a ordem de declaração por padrão.
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
Usar parameters com "defaultValue" é a única abordagem que atende aos dois requisitos simultaneamente: torna o nome configurável em tempo de implantação e mantém o comportamento padrão atual com o valor "minhaconta2024".
A alternativa A usa variables, que são estáticas e calculadas no próprio template. Elas não podem ser sobrescritas em tempo de implantação via parâmetro de entrada, portanto não tornam o recurso "configurável" pelo operador que executa o deploy.
A alternativa C estaria correta quanto à configurabilidade, mas ao omitir defaultValue quebra o comportamento padrão: qualquer implantação sem o parâmetro explícito passará a falhar por campo obrigatório não fornecido.
A alternativa D representa um equívoco fundamental: outputs serve para expor valores após a implantação e não pode ser referenciado como fonte de valor dentro do mesmo template.
Gabarito — Questão 2
Resposta: C
O campo computerName dentro de osProfile é obrigatório pelo provedor Microsoft.Compute. Sua ausência é detectada pelo ARM durante a validação do payload antes do provisionamento, causando falha imediata.
A alternativa A descreve uma prática recomendada de segurança (securestring), mas não uma regra que cause rejeição automática pelo ARM durante a validação de schema. O deploy não falhará por esse motivo isolado.
A alternativa B é tecnicamente incorreta: variables() é perfeitamente válida no campo name de um recurso.
A alternativa D é um distrator plausível, mas versões de API são validadas de forma menos rígida durante a submissão; erros de apiVersion geralmente resultam em falhas no plano de controle do provedor, não em rejeição imediata de schema.
Gabarito — Questão 3
Resposta: Verdadeiro
A afirmação é verdadeira. copyIndex() sem argumento retorna 0 na primeira iteração. copyIndex(1) é a forma documentada de deslocar o valor de retorno em n posições, útil para nomear recursos a partir de 1 em vez de 0. Esse deslocamento é puramente cosmético para o valor retornado pela função e não interfere no número de iterações, que é controlado exclusivamente pelo campo count do objeto copy.
O equívoco comum é acreditar que copyIndex(1) iniciaria a segunda iteração ou puliria a primeira, o que não ocorre. O loop sempre executa exatamente count vezes, independentemente do argumento passado para copyIndex().
Gabarito — Questão 4
Resposta: C
A propriedade "condition" é o mecanismo nativo do ARM para implantação condicional de recursos. Quando seu valor é avaliado como false, o recurso é ignorado durante a implantação sem causar erro.
A alternativa A confunde dependsOn com lógica condicional. dependsOn define ordem de criação entre recursos que serão criados; não serve para suprimir a criação de um recurso.
A alternativa B descreve uma sintaxe inexistente no ARM. Não há instrução if no nível de objeto de recurso com essa estrutura JSON.
A alternativa D representa um equívoco sobre o papel de outputs. A seção de outputs é usada para expor valores após a implantação e não tem capacidade de controlar a criação de recursos.
Gabarito — Questão 5
Resposta: C
Quando a função reference() é usada dentro de properties de um recurso para acessar atributos de outro recurso da mesma implantação, o ARM infere automaticamente uma dependência entre eles. Essa dependência implícita é suficiente para garantir a ordem de provisionamento, tornando o uso explícito de dependsOn redundante nesse caso.
A alternativa B está parcialmente correta em descrever a sintaxe válida de dependsOn, mas a questão pergunta sobre a abordagem que garante a resolução correta quando se usa reference(), tornando C a resposta mais precisa e completa.
A alternativa A está errada porque resourceId() com subscription e resource group completos é usado para referenciar recursos em escopos externos, não dentro da mesma implantação.
A alternativa D representa o equívoco mais comum: o ARM não respeita a ordem de declaração no array resources. O motor de implantação analisa dependências declaradas e inferidas para determinar a ordem de execução.