El primer bloque del dominio de proceso de AZ-104 es "automatizar la implementación de recursos con plantillas de ARM o archivos Bicep". Sus cinco subpuntos, "interpretar una plantilla de ARM o un archivo Bicep", "modificar una plantilla de ARM existente", "modificar un archivo Bicep existente", "implementar recursos" y "exportar una implementación como plantilla de ARM o convertir una plantilla de ARM en un archivo Bicep", comprueban si eres capaz de leer y editar código tú mismo. El examen real muestra parte de una plantilla y pregunta cosas como "¿Qué agregas para crear tres cuentas de almacenamiento?" o "¿Qué pasa con los recursos existentes al ejecutar esta implementación?".
Este artículo pone la misma cuenta de almacenamiento lado a lado en ARM JSON y en Bicep y la lee línea por línea, para que administradores sin experiencia en desarrollo puedan seguir una plantilla. Cubre las secciones de la plantilla y las funciones más comunes, bucles, condiciones y dependencias, archivos de parámetros y referencias a Key Vault, ámbitos y modos de implementación, y la exportación y conversión. Qué son las plantillas de ARM y Bicep se presentó primero en Máquinas Virtuales y Automatización de Implementaciones.
---
Una Plantilla es un Formulario con Campos Fijos
Un formulario de la administración tiene lugares fijos para los campos que rellena el solicitante, los que calcula el funcionario, la solicitud en sí y el justificante que recibes al final. Una plantilla de ARM es igualmente un documento JSON formado por secciones fijas.
| Sección | Función | En un formulario en papel | |------|------|------| | $schema | Versión del lenguaje de la plantilla y ámbito de implementación | Número de formulario | | contentVersion | Versión de la propia plantilla | Número de revisión del documento | | parameters | Valores que llegan desde fuera al implementar | Campos que rellena el solicitante | | variables | Valores calculados dentro de la plantilla y reutilizados | Campos que calcula el funcionario | | resources | Recursos que se crean o actualizan | La solicitud en sí | | outputs | Valores devueltos después de implementar | El justificante |
Esta es una plantilla de ARM que crea una cuenta de almacenamiento.
Funciones de Plantilla que Verás a Menudo
Un valor entre corchetes es una expresión que se evalúa al implementar.
| Función | Resultado | Uso típico | |------|------|------| | resourceGroup().location | La región del grupo de recursos de destino | Valor predeterminado de location | | parameters('nombre') · variables('nombre') | El valor de un parámetro o variable | Reutilizar valores | | concat() · format() | Une cadenas | Construir nombres | | uniqueString(resourceGroup().id) | Un hash de 13 caracteres estable por grupo de recursos | Nombres que deben ser únicos a nivel global | | resourceId('tipo', 'nombre') | El id. completo de un recurso | Referenciar otros recursos, salidas | | copyIndex() | El número de iteración actual en un bucle | Nombres de recursos en bucle |
Consejo para el examen: "Si no se indica un valor, implementar en la misma región que el grupo de recursos" significa usar resourceGroup().location como defaultValue. "Aceptar solo las SKU aprobadas" significa allowedValues.
---
Leer lo Mismo en Bicep
Bicep es un lenguaje que expresa ARM JSON de forma más corta y legible, y se convierte en ARM JSON al implementar. La plantilla anterior queda así en Bicep.
| ARM JSON | Bicep | Qué recordar | |------|------|------| | parameters + defaultValue | param nombre tipo = predeterminado | El valor predeterminado va tras un signo igual | | allowedValues · minLength | Decoradores @allowed · @minLength | Se colocan encima del parámetro | | securestring | @secure() param | Contraseñas y claves deben ser parámetros seguros | | variables | var | Sin declaración de tipo | | type + apiVersion | 'tipo@apiVersion' | Se combinan en una sola cadena | | dependsOn | Casi siempre automático (referencias por nombre simbólico) | Referenciar algo como stg.id crea la dependencia | | copy | [for ... in ...: {...}] | Expresión de bucle | | condition | if (condición) | Implementación condicional | | outputs | output | Requiere declarar el tipo |
Consejo para el examen: En las preguntas de Bicep, una opción como "agregar dependsOn para que la subred se referencie después de crear la VNet" suele sobrar. Cuando referencias un nombre simbólico (por ejemplo, vnet.id), Bicep crea la dependencia automáticamente.
---
Bucles, Condiciones y Dependencias: las Modificaciones más Comunes
Las preguntas de edición de plantillas casi siempre tratan de una de tres cosas: crear varias copias de un recurso, decidir si se crea algo según una condición y controlar el orden de creación.
Para crear tres cuentas de almacenamiento en ARM JSON, agrega una propiedad copy al recurso y añade copyIndex() al nombre.
En Bicep se usa una expresión for.
| Requisito | ARM JSON | Bicep | |------|------|------| | N copias del mismo recurso | copy + count, copyIndex() | [for i in range(0, N): {...}] | | Implementar solo si una condición es verdadera | "condition": "[equals(parameters('env'), 'prod')]" | resource ... = if (env == 'prod') {...} | | Crear la VM después de la NIC | "dependsOn": [ "[resourceId('Microsoft.Network/networkInterfaces', 'nic1')]" ] | Automático al referenciar nic.id | | Referenciar un recurso que ya existe | reference() · resourceId() | resource vnet '...' existing = { name: 'vnet1' } |
Consejo para el examen: copyIndex() empieza en 0. Para "nombrarlas stg1, stg2, stg3 empezando por 1", pasa un valor inicial como en copyIndex(1).
---
Archivos de Parámetros y Valores Secretos
Cuando implementas la misma plantilla en desarrollo y producción con valores distintos, mantén un archivo de parámetros aparte. Los valores secretos, como las contraseñas, no se escriben en el archivo; se referencian desde un secreto de Key Vault.
El parámetro de la plantilla debe ser securestring (@secure() en Bicep) para que el valor no quede en el historial de implementaciones ni en los registros El almacén de claves debe permitir el acceso para la implementación de plantillas (enabledForTemplateDeployment) para leer el secreto durante la implementación Bicep hace lo mismo con un archivo .bicepparam que contiene using './main.bicep' y líneas param nombre = valor
Consejo para el examen: "No exponer la contraseña del administrador de la VM en la plantilla ni en el archivo de parámetros" significa una referencia a un secreto de Key Vault más un parámetro securestring. Si una implementación falla con "no se puede acceder al almacén de claves", revisa la configuración del almacén que permite la implementación de plantillas.
---
Ámbitos y Modos de Implementación
El comando depende de dónde implementes la plantilla.
| Ámbito de implementación | CLI de Azure | PowerShell | |------|------|------| | Grupo de recursos | az deployment group create --resource-group rg1 --template-file main.bicep | New-AzResourceGroupDeployment | | Suscripción | az deployment sub create --location eastus --template-file main.bicep | New-AzSubscriptionDeployment | | Grupo de administración | az deployment mg create --management-group-id mg1 --location eastus | New-AzManagementGroupDeployment | | Inquilino | az deployment tenant create --location eastus | New-AzTenantDeployment |
Las implementaciones en un grupo de recursos tienen dos modos. Se diferencian en cómo tratan los recursos existentes que no están en la plantilla.
!Los modos incremental y completo tratan de forma distinta los recursos que no están en la plantilla
| Modo | Recursos existentes que no están en la plantilla | Recursos de la plantilla | |------|------|------| | Incremental (predeterminado, recomendado) | Se dejan como están | Se crean, o se vuelven a aplicar con los valores de la plantilla | | Completo (no recomendado) | Se eliminan | Se crean o se vuelven a aplicar |
El modo incremental también tiene una trampa. Al volver a implementar un recurso existente, sus propiedades no "se suman"; el recurso se vuelve a aplicar tal como lo define la plantilla, así que las propiedades que faltan en la plantilla pueden sobrescribirse con valores predeterminados. Además, Microsoft no recomienda el modo completo y prevé dejarlo de usar gradualmente; si una implementación necesita eliminar recursos, usa pilas de implementación. Ejecutar what-if (az deployment group what-if) antes de implementar muestra qué se creará, cambiará y eliminará.
Consejo para el examen: Si "RG1 contiene VM1 y Storage1, y se implementa en modo completo una plantilla que solo define VNet1", VM1 y Storage1 se eliminan y solo queda VNet1. Implementar la misma plantilla en modo incremental conserva los tres.
---
Exportar y Convertir
Cuando quieres una plantilla de recursos que ya creaste en el portal, usa la exportación. El resultado cambia según el método.
| Método | Resultado | Características | |------|------|------| | Exportar plantilla desde un grupo de recursos o un recurso | Bicep o ARM JSON | Una instantánea del estado actual, con los cambios hechos después de implementar; muchas propiedades, pocos parámetros | | Guardar desde el historial de implementaciones | Solo ARM JSON | La plantilla exacta usada en la implementación, con parámetros; solo los recursos de esa implementación | | az bicep decompile --file main.json | ARM JSON → Bicep | Una conversión de mejor esfuerzo que puede necesitar retoques | | az bicep build --file main.bicep | Bicep → ARM JSON | Revisar el resultado convertido antes de implementar |
Consejo para el examen: "Necesitas una plantilla que incluya la configuración cambiada en el portal después de implementar" significa exportar desde el grupo de recursos. "Quieres reutilizar la plantilla y los parámetros originales de la primera implementación" significa guardar desde el historial de implementaciones. "Convertir una plantilla de ARM existente en Bicep" significa dec