Basadas en fuentes oficiales. Revisadas a fondo.

Las plantillas de Azure Resource Manager (ARM) usan sintaxis JSON declarativa para definir el estado deseado de tu infraestructura. Entre sus principales beneficios están: implementaciones repetibles (la misma plantilla produce entornos idénticos siempre), consistencia entre dev/staging/prod, idempotencia (volver a implementar la misma plantilla da el mismo resultado sin duplicar recursos) y orquestación integrada (ARM resuelve automáticamente el orden de las dependencias). Las plantillas no reemplazan a las suscripciones — sigues necesitando una suscripción como destino de la implementación. Una sola plantilla puede implementar docenas de recursos a la vez, no solo uno. La optimización de costos es terreno de Azure Advisor, no de las plantillas ARM. Consejo para el examen: plantillas ARM = infraestructura como código declarativa, repetible, consistente e idempotente. Ten en cuenta también que Bicep es el sucesor recomendado de las plantillas ARM en JSON. (Ref: learn.microsoft.com/azure/azure-resource-manager/templates/overview)

Azure Cloud Shell es una terminal autenticada basada en el navegador a la que puedes acceder desde el portal de Azure, shell.azure.com o la app móvil de Azure. Viene con Azure CLI (comandos az) y Azure PowerShell (módulo Az) preinstalados, además de herramientas como kubectl, Terraform, git y editores de código. La persistencia de archivos funciona mediante un recurso compartido de Azure Files (5 GB) montado en tu directorio $HOME, para que los scripts y las configuraciones sobrevivan al reinicio de la sesión. Cloud Shell se ejecuta en un host de Linux temporal que se autentica automáticamente con tus credenciales de Azure. Las sesiones expiran tras 20 minutos de inactividad. Al iniciarla, eliges entre Bash o PowerShell. La afirmación es “Verdadero” porque ambas CLI vienen preinstaladas y Azure Files brinda persistencia entre sesiones. (Ref: learn.microsoft.com/azure/cloud-shell/overview)

Los resource locks de Azure evitan la eliminación o modificación accidental de recursos críticos. Dos tipos de lock: CanNotDelete (Delete lock): los usuarios autorizados pueden leer y modificar el recurso, pero no pueden eliminarlo. ReadOnly: los usuarios autorizados pueden leer el recurso, pero no pueden modificarlo ni eliminarlo. Los locks se pueden aplicar a nivel de subscription, resource group o recurso individual, y se heredan a los recursos secundarios. Los locks anulan los permisos de RBAC: incluso los Owners no pueden eliminar un recurso con lock CanNotDelete sin quitar primero el lock. Azure Policy aplica reglas de cumplimiento, pero no evita directamente la eliminación. RBAC controla el acceso, pero no puede evitar eliminaciones con nivel de Owner. Consejo para el examen: Resource locks = evitan la eliminación/modificación accidental. Dos tipos: CanNotDelete y ReadOnly. Anulan RBAC.

La jerarquía de recursos de Azure desde el alcance más alto hasta el más bajo es: Management groups → Subscriptions → Resource groups → Resources. Los Management groups están en la parte superior, organizan varias subscriptions y aplican gobernanza a escala. Las Subscriptions son límites de facturación y acceso que contienen resource groups. Los Resource groups son contenedores lógicos que agrupan recursos relacionados para la administración del ciclo de vida. Los Resources son los servicios individuales de Azure (VMs, bases de datos, storage accounts). Las asignaciones de Policies y RBAC en niveles superiores se heredan hacia niveles inferiores. Un resource solo puede pertenecer a un resource group, un resource group a una subscription, y una subscription a un management group. Consejo para el examen: Jerarquía de arriba hacia abajo: Management groups > Subscriptions > Resource groups > Resources.