Curso de Gestión de Infraestructuras con Terraform para empresas

Instalar Terraform CLI de forma controlada, revisando mecanismos de instalación, actualización, validación de binarios y compatibilidad con proyectos existentes.

Fijar versiones mediante restricciones en el bloque `terraform`, evitando que cada miembro del equipo ejecute planes con versiones distintas sin control.

Organizar herramientas auxiliares como `tflint`, `tfsec` o alternativas equivalentes, validadores HCL, extensiones de editor y comprobaciones previas a commit.

Configurar un entorno local consistente para Windows, macOS y Linux, reduciendo diferencias de rutas, shells, variables de entorno y autenticación cloud.

Preparar convenciones de nombres para archivos `.tf`, variables, salidas, módulos, providers, recursos, etiquetas, entornos y carpetas.

Definir reglas de formato con `terraform fmt` y validación con `terraform validate` como parte obligatoria del flujo de desarrollo.

Establecer un modelo de versionado del código Terraform basado en Git, ramas, pull requests, protección de ramas y revisión técnica de planes.

Separar configuración local, credenciales, variables sensibles y archivos generados para impedir commits accidentales de secretos o estados.

Crear una plantilla de repositorio corporativo con README, estructura mínima, `.gitignore`, `.terraform-version`, documentación y pipeline inicial.

Acordar una guía interna de trabajo que indique cómo ejecutar cambios, revisar planes, pedir aprobación y resolver incidencias sin improvisar.

Dominar la sintaxis HCL desde una perspectiva práctica, trabajando con bloques, argumentos, expresiones, referencias, interpolaciones y comentarios útiles.

Diferenciar tipos primitivos, listas, mapas, objetos, tuplas, sets y estructuras anidadas para modelar infraestructura sin perder legibilidad.

Construir expresiones con `for`, `if`, operadores, funciones integradas, splat expressions y transformaciones de datos aplicadas a casos reales.

Diseñar variables de entrada con tipos explícitos, valores por defecto, descripciones, validaciones y sensibilidad cuando contienen información protegida.

Usar `locals` para centralizar cálculos, nombres, etiquetas, convenciones y decisiones repetidas sin llenar los recursos de lógica duplicada.

Exponer `outputs` útiles para otros módulos, pipelines, equipos o documentación, evitando publicar valores sensibles o detalles internos innecesarios.

Trabajar con `dynamic blocks` solo cuando aportan valor real, evitando configuraciones tan abstractas que el equipo no pueda leer ni mantener.

Aplicar funciones de manipulación de strings, colecciones, rutas, codificación JSON/YAML, CIDR y fechas en escenarios habituales de infraestructura.

Revisar errores comunes de HCL: referencias circulares, tipos ambiguos, conversiones implícitas, valores desconocidos en plan y expresiones difíciles de depurar.

Refactorizar configuraciones iniciales para hacerlas más explícitas, comprensibles y robustas sin convertir cada archivo en una capa excesivamente genérica.

Comprender el papel de los providers como capa de comunicación entre Terraform y APIs externas, revisando instalación, versiones, alias y restricciones.

Configurar providers oficiales y comunitarios con criterios de confianza, mantenimiento, compatibilidad, documentación y riesgo operativo.

Gestionar múltiples configuraciones del mismo provider mediante alias para separar regiones, suscripciones, cuentas, tenants, clusters o entornos.

Implementar autenticación para AWS, Azure, Google Cloud, Kubernetes, Helm, Vault, DNS y otros providers sin incrustar credenciales en código.

Usar variables de entorno, perfiles locales, identidades gestionadas, service principals, roles asumidos y OIDC según el proveedor y el entorno.

Separar permisos de lectura, planificación y aplicación cuando la organización necesite flujos con aprobación o segregación de funciones.

Preparar configuraciones multi-cloud sin crear módulos acoplados a un único proveedor cuando el objetivo sea reutilizar patrones de plataforma.

Resolver conflictos de versiones de provider y lock files, entendiendo cuándo actualizar, cuándo fijar y cómo probar cambios.

Revisar problemas habituales: credenciales caducadas, regiones incorrectas, tenants equivocados, permisos parciales y diferencias entre plan local y pipeline.

Crear una estrategia de documentación de providers para que cada repositorio explique cómo se autentica, qué permisos requiere y qué alcance tiene.

Entender el archivo de estado como inventario crítico que vincula recursos reales con configuración declarativa, no como un simple artefacto técnico.

Analizar los riesgos de estado local en equipos: pérdida de información, sobrescrituras, cambios concurrentes, exposición de secretos y falta de auditoría.

Configurar backends remotos con locking para evitar operaciones simultáneas peligrosas en entornos compartidos.

Comparar backends habituales como HCP Terraform, Terraform Enterprise, S3 con DynamoDB, Azure Storage, Google Cloud Storage y alternativas corporativas.

Migrar estado local a remoto de forma segura, validando backups, acceso, cifrado, bloqueo, permisos y consistencia antes de operar en equipo.

Ejecutar comandos de inspección y mantenimiento de estado sin convertirlos en una vía habitual para corregir malas decisiones de diseño.

Resolver escenarios de estado dañado, bloqueo colgado, recurso eliminado manualmente, cambio de nombre y divergencia entre realidad y configuración.

Usar `moved` blocks para refactorizar direcciones de recursos sin destruir infraestructura por cambios de estructura o nombres internos.

Preparar estrategias de backup, retención, cifrado, acceso restringido y restauración para estados de entornos críticos.

Documentar procedimientos de emergencia para operaciones sobre estado, dejando claro quién puede ejecutarlas y bajo qué aprobación.

Diseñar variables con tipos estrictos y validaciones útiles para impedir configuraciones peligrosas antes de llegar al plan.

Separar valores comunes, valores por entorno, secretos, convenciones globales y parámetros específicos de cada despliegue.

Usar archivos `.tfvars`, variables de entorno, variable sets o mecanismos de HCP Terraform según el nivel de gobierno requerido.

Evitar que las variables se conviertan en un cajón de sastre, estableciendo nombres claros, descripciones útiles y valores por defecto razonables.

Marcar valores sensibles y comprender sus límites, recordando que ocultar en salida no equivale a eliminar el dato del estado.

Integrar gestores de secretos como Vault, AWS Secrets Manager, Azure Key Vault o Google Secret Manager cuando el caso lo justifique.

Definir convenciones de etiquetado corporativo para costes, propietarios, entornos, criticidad, aplicaciones, centros de coste y cumplimiento.

Preparar matrices de configuración para entornos dev, test, preproducción y producción sin copiar carpetas enteras de forma incontrolada.

Revisar patrones anti-mantenibles como enormes ficheros de variables, lógica condicional excesiva y parámetros que cambian el comportamiento del módulo sin claridad.

Crear documentación generada o mantenida de variables para facilitar consumo por otros equipos y reducir errores de configuración.

Modelar recursos de infraestructura con nombres estables, argumentos claros, tags obligatorios y relación directa con necesidades operativas.

Usar data sources para consultar infraestructura existente, catálogos, imágenes, redes, identidades o parámetros compartidos sin duplicar información.

Comprender dependencias implícitas y explícitas, evitando abusar de `depends_on` cuando el grafo de Terraform ya puede inferir relaciones.

Gestionar `lifecycle` con criterio, aplicando `prevent_destroy`, `create_before_destroy`, `ignore_changes` y reemplazos solo cuando hay una razón clara.

Analizar cuándo un cambio obliga a recrear un recurso, qué impacto tiene en servicio y cómo reducir ventanas de indisponibilidad.

Preparar estrategias para recursos críticos que no deben destruirse accidentalmente, como bases de datos, redes centrales, claves, DNS o almacenamiento.

Trabajar con recursos gestionados parcialmente por Terraform y parcialmente por otros sistemas, delimitando responsabilidades para evitar conflictos.

Evitar drift deliberado mediante `ignore_changes` mal utilizado, diferenciando excepciones temporales de deuda técnica permanente.

Interpretar el plan de Terraform para detectar altas, cambios, reemplazos, destrucciones y valores desconocidos antes de aprobar una ejecución.

Crear revisiones de plan orientadas a infraestructura real, preguntando qué cambia, por qué cambia, qué riesgo tiene y cómo se recupera.

Diseñar módulos con una responsabilidad clara, evitando mezclar redes, seguridad, cómputo, observabilidad y aplicaciones en piezas imposibles de reutilizar.

Definir contratos de módulo con variables, outputs, validaciones, documentación y ejemplos que permitan consumo seguro por otros equipos.

Separar módulos internos, módulos de proveedor, módulos de comunidad y módulos específicos de proyecto según riesgo, madurez y propiedad.

Crear módulos para redes, IAM, buckets, clusters, bases de datos, balanceadores, monitorización, DNS y patrones repetidos de plataforma.

Versionar módulos con Git tags, semantic versioning y changelogs para que los consumidores puedan actualizar con control.

Diseñar outputs estables que no filtren detalles internos y permitan componer módulos sin acoplamientos innecesarios.

Evitar módulos excesivamente configurables que terminan aceptando cualquier forma, reduciendo validación, claridad y soporte.

Probar módulos con escenarios mínimos, escenarios completos, entradas inválidas y cambios de versión antes de publicarlos en un registro interno.

Mantener compatibilidad hacia atrás cuando sea posible, documentando cambios disruptivos y rutas de migración para equipos consumidores.

Preparar una guía de diseño de módulos corporativos con nomenclatura, estructura, ejemplos, criterios de aceptación y responsabilidades de mantenimiento.

Comparar monorepo, multirepo, repos por dominio, repos por cuenta, repos por plataforma y repos por producto según tamaño y gobierno del equipo.

Diseñar una estructura clara para entornos, regiones, cuentas, suscripciones, tenants, dominios técnicos y módulos compartidos.

Separar código reutilizable de configuración específica para evitar duplicar módulos o mezclar datos de producción con laboratorio.

Definir convenciones para carpetas como `modules`, `environments`, `stacks`, `global`, `networking`, `identity`, `platform` y `apps`.

Gestionar diferencias entre entornos sin copiar y pegar archivos enteros que luego evolucionan de forma divergente.

Crear mecanismos para promocionar cambios desde dev hasta producción con control de versiones, planes comparables y aprobaciones.

Evitar estructuras demasiado abstractas que solo entiende una persona y dificultan onboarding, soporte y revisión por pares.

Preparar documentación de repositorio que explique propósito, propietarios, backends, variables, pipelines, proveedores y procedimientos.

Integrar CODEOWNERS o mecanismos equivalentes para que cambios críticos sean revisados por los equipos responsables.

Diseñar una estructura inicial para una plataforma de infraestructura corporativa que pueda crecer sin reescribirse cada trimestre.

Diferenciar workspaces de Terraform CLI, workspaces en HCP Terraform y separación real de entornos para evitar malentendidos operativos.

Decidir cuándo usar workspaces y cuándo preferir carpetas, repositorios, stacks o proyectos separados por claridad, permisos y trazabilidad.

Organizar workspaces por aplicación, dominio, entorno, cuenta, región o equipo, entendiendo las consecuencias en estado, permisos y ejecución.

Usar proyectos en HCP Terraform o Terraform Enterprise para crear límites de propiedad, acceso y gobierno entre equipos o plataformas.

Configurar variables compartidas mediante variable sets, evitando duplicidades y reduciendo errores en credenciales, etiquetas y parámetros comunes.

Establecer naming conventions para workspaces que permitan identificar entorno, cuenta, región, criticidad y propietario sin consultar documentación externa.

Diseñar flujos de ejecución remota con colas, bloqueos, aprobaciones, notificaciones y separación entre plan y apply.

Preparar estrategias de migración desde estados y pipelines dispersos hacia una organización centralizada sin detener el trabajo diario.

Controlar acceso a workspaces mediante equipos, roles y permisos, evitando que usuarios puedan aplicar cambios en ámbitos fuera de su responsabilidad.

Definir un catálogo interno de workspaces y proyectos que sirva como inventario vivo de infraestructura gestionada por Terraform.

Revisar el papel de HCP Terraform como entorno compartido para ejecuciones, estado remoto, permisos, políticas, registro privado y colaboración.

Diferenciar HCP Terraform y Terraform Enterprise en función de requisitos de SaaS, autogestión, conectividad privada, compliance y control operativo.

Configurar organizaciones, proyectos, workspaces, equipos, permisos y variables para reflejar la estructura real de la empresa.

Implantar ejecución remota para que los planes y applies se realicen en un entorno consistente, auditable y controlado.

Usar agentes privados cuando la infraestructura no es accesible desde internet o requiere ejecución dentro de redes corporativas.

Configurar notificaciones, integraciones VCS, run triggers y aprobaciones para conectar cambios de Git con despliegues gobernados.

Publicar módulos en un registro privado, documentarlos y versionarlos para que otros equipos consuman patrones aprobados.

Revisar auditoría, historial de runs, logs, variables sensibles, permisos y eventos como parte de la operación diaria.

Preparar un modelo de administración de plataforma que separe propietarios de organización, administradores de proyecto, mantenedores y consumidores.

Diseñar una estrategia gradual de adopción para migrar desde Terraform local o pipelines propios hacia un modelo centralizado.

Comprender Terraform Stacks como una forma de dividir configuración en componentes y gestionar despliegues coordinados a través de entornos.

Identificar cuándo Stacks aporta valor frente a workspaces tradicionales, especialmente en plataformas con múltiples componentes interdependientes.

Diseñar componentes que representen piezas lógicas como red, identidad, Kubernetes, observabilidad, datos o servicios compartidos.

Organizar despliegues por entorno, región, cuenta o unidad de negocio sin perder una visión común del ciclo de vida de la plataforma.

Preparar archivos de configuración de Stack con versiones, componentes, variables, proveedores y dependencias expresadas de forma clara.

Revisar el flujo de trabajo de `terraform stacks` y los requisitos actuales de versión para trabajar con esta funcionalidad.

Coordinar cambios entre componentes para evitar que una modificación parcial deje la plataforma en un estado inconsistente.

Evaluar el impacto de Stacks en la gobernanza, costes, facturación, permisos, revisiones y operación de HCP Terraform.

Crear criterios de adopción para decidir qué partes de la infraestructura conviene migrar a Stacks y cuáles mantener en workspaces.

Diseñar un ejemplo corporativo donde red, seguridad, Kubernetes y observabilidad se gestionan como componentes coordinados.

Entender dynamic provider credentials como un mecanismo para que las ejecuciones obtengan credenciales temporales mediante OIDC en lugar de secretos largos.

Revisar el flujo de identidad donde HCP Terraform emite tokens de workload identity para que cloud providers validen el origen de la ejecución.

Configurar confianza con AWS, Azure, Google Cloud, Kubernetes, Helm, Vault o HCP según el proveedor y el tipo de entorno.

Sustituir claves persistentes por roles asumidos, federación de identidad, service principals temporales o credenciales dinámicas.

Diseñar claims, audiences, subjects y políticas de confianza que limiten qué workspace, proyecto o Stack puede acceder a cada recurso.

Separar permisos para plan y apply cuando la organización quiera revisar cambios con una identidad distinta de la que ejecuta modificaciones.

Integrar Vault-backed dynamic credentials en entornos donde se requiera generación de secretos desde Vault y redes privadas.

Preparar pruebas de seguridad para verificar que un workspace no puede asumir permisos de otro entorno, cuenta o tenant.

Documentar el modelo de autenticación para auditoría, seguridad y operaciones, incluyendo caducidad, alcance, logs y procedimientos de revocación.

Definir una ruta de migración desde secretos estáticos hacia credenciales dinámicas sin romper pipelines ni despliegues productivos.

Diseñar una VPC corporativa con subredes públicas y privadas, tablas de rutas, NAT, endpoints, gateways y segmentación por entorno.

Modelar grupos de seguridad y reglas de red con criterios de mínimo privilegio, evitando aperturas amplias y reglas imposibles de auditar.

Crear roles IAM, policies, instance profiles y relaciones de confianza sin convertir Terraform en un generador de permisos excesivos.

Desplegar recursos de cómputo como EC2, Auto Scaling Groups, Launch Templates o servicios gestionados según el patrón de infraestructura usado.

Gestionar almacenamiento con S3, cifrado, versionado, políticas de acceso, lifecycle rules y controles contra exposición pública accidental.

Provisionar bases de datos gestionadas con parámetros, subredes, backups, cifrado, mantenimiento y protección frente a destrucción accidental.

Integrar balanceadores, target groups, listeners, certificados y DNS para servicios internos o expuestos de forma controlada.

Usar remote state entre capas cuando red, seguridad, datos y aplicaciones se gestionan desde repositorios o workspaces distintos.

Preparar módulos AWS reutilizables para patrones repetidos sin esconder decisiones críticas de seguridad o coste.

Revisar planes AWS con foco en impacto real: recursos reemplazados, cambios IAM, exposición de red, coste y continuidad.

Organizar infraestructura Azure mediante suscripciones, resource groups, regiones, management groups y convenciones de naming consistentes.

Modelar VNets, subredes, NSG, route tables, private endpoints y DNS privado para entornos corporativos segmentados.

Configurar autenticación con AzureRM y Microsoft Entra ID usando service principals, managed identities u OIDC según el escenario.

Gestionar RBAC, role assignments y scopes con cuidado para evitar privilegios excesivos a nivel de suscripción o management group.

Desplegar servicios como Azure App Service, Azure Kubernetes Service, Azure Container Apps, Storage Accounts, Key Vault y bases de datos gestionadas.

Incorporar políticas de cifrado, soft delete, purge protection, network restrictions y diagnóstico en recursos críticos.

Diseñar módulos Azure que respeten convenciones de empresa, tags obligatorios, límites de red y dependencias entre equipos.

Integrar Terraform con Azure DevOps o GitHub Actions para revisar planes, aplicar aprobaciones y publicar evidencias.

Resolver problemas habituales de Azure: providers registrados, permisos incompletos, bloqueos, nombres globales, cambios fuera de banda y dependencias lentas.

Preparar un patrón de landing zone simplificado que pueda evolucionar hacia arquitecturas Azure más gobernadas.

Estructurar Google Cloud con organizaciones, folders, proyectos, billing accounts, service accounts y separación clara entre entornos.

Crear redes VPC, subredes regionales, firewall rules, Cloud NAT, peering, Private Service Connect y DNS gestionado.

Configurar providers Google y Google Beta cuando una funcionalidad lo requiera, controlando versiones y diferencias de comportamiento.

Gestionar IAM mediante roles predefinidos, roles personalizados, bindings y miembros sin provocar sobreescrituras accidentales entre equipos.

Desplegar recursos como Compute Engine, GKE, Cloud SQL, Cloud Storage, Cloud Run, Pub/Sub y Secret Manager con criterios corporativos.

Integrar Workload Identity Federation para reducir claves persistentes de service accounts en pipelines y ejecuciones remotas.

Organizar módulos por proyecto, red, seguridad, datos y plataforma, respetando límites de cuota, regiones y políticas internas.

Revisar errores habituales de APIs no habilitadas, permisos de billing, propagación IAM, nombres globales y dependencias entre servicios.

Incorporar labels, presupuestos, alertas y controles de coste dentro de la estrategia de infraestructura como código.

Crear un laboratorio multi-proyecto donde red compartida, servicios gestionados y permisos se provisionan de forma reproducible.

Usar providers de Kubernetes y Helm para gestionar namespaces, RBAC, ConfigMaps, Secrets, Deployments, Services, Ingress y charts.

Delimitar qué recursos deben gestionarse con Terraform y cuáles conviene delegar a GitOps, Helm, operadores o pipelines de aplicación.

Provisionar componentes de plataforma como ingress controllers, cert-manager, external-dns, monitorización, logging o políticas de red.

Configurar autenticación segura contra clusters locales, gestionados o privados, evitando kubeconfigs personales en pipelines corporativos.

Aplicar Terraform para bootstrap de clusters y GitOps para despliegue continuo de aplicaciones cuando el modelo organizativo lo recomiende.

Gestionar charts Helm con versiones fijadas, valores revisados, dependencias, repositorios privados y estrategias de actualización.

Controlar drift en Kubernetes, donde otros operadores pueden modificar recursos y provocar diferencias constantes con el estado deseado.

Diseñar módulos para namespaces de equipo con cuotas, límites, RBAC, network policies, secrets externos y convenciones de observabilidad.

Integrar dynamic provider credentials con Kubernetes y Helm cuando se trabaje desde HCP Terraform o Terraform Enterprise.

Crear un patrón de plataforma donde Terraform entrega infraestructura base y GitOps opera el ciclo de vida de workloads.

Modelar bloques CIDR, subredes, segmentación, rutas y zonas de seguridad con una visión previa a la creación de recursos.

Crear redes cloud con subredes por zona, entornos, capas, exposición, servicios internos y tránsito hacia redes corporativas.

Gestionar DNS público y privado con Terraform, incluyendo zonas, registros, delegaciones, split-horizon y convenciones de nombres.

Automatizar certificados, validación DNS, renovación, asociaciones con balanceadores y dependencias con servicios expuestos.

Provisionar balanceadores, listeners, pools, health checks y reglas de enrutado con criterios de disponibilidad y seguridad.

Diseñar conectividad híbrida con VPN, Direct Connect, ExpressRoute, Cloud Interconnect o equivalentes sin perder trazabilidad de dependencias.

Controlar reglas de firewall, security groups, NSG o network policies evitando configuraciones amplias, duplicadas o sin propietario.

Validar cambios de red con planes revisados por perfiles responsables, reduciendo riesgo de interrupciones por rutas, DNS o reglas mal aplicadas.

Crear módulos de red que permitan crecimiento sin renumeraciones constantes ni dependencias rígidas entre aplicaciones.

Documentar topologías generadas por Terraform para que operaciones, seguridad y arquitectura puedan revisarlas sin leer todos los `.tf`.

Incorporar controles de seguridad en el diseño de Terraform, no como una revisión tardía después de crear recursos.

Aplicar políticas sobre cifrado, exposición pública, regiones permitidas, tamaños, etiquetas obligatorias, backups, versiones TLS y acceso administrativo.

Usar Sentinel, OPA, Conftest, Checkov, tfsec, TFLint u otras herramientas según el ecosistema y el grado de gobierno requerido.

Integrar escaneos de seguridad en pull requests y pipelines para bloquear cambios peligrosos antes de ejecutar `apply`.

Crear excepciones controladas, temporales y justificadas para políticas, evitando convertir la gobernanza en una lista de falsos positivos ignorados.

Revisar IAM y RBAC generados por Terraform con criterios de mínimo privilegio, separación de funciones y auditoría.

Controlar secretos en variables, estado, logs, outputs, pipelines y documentación, recordando que Terraform puede persistir datos sensibles.

Preparar evidencias para auditoría: planes, applies, aprobaciones, políticas evaluadas, usuarios ejecutores, cambios y resultados.

Diseñar una matriz de controles por criticidad de entorno, permitiendo más flexibilidad en laboratorio y reglas estrictas en producción.

Establecer un proceso de revisión periódica para módulos, providers, políticas, permisos y configuraciones sensibles.

Diseñar pipelines que ejecuten `fmt`, `validate`, linting, análisis de seguridad, plan, publicación de resultados y aprobación antes de aplicar.

Separar claramente pipelines de pull request, merge, plan especulativo, apply controlado y despliegues programados.

Publicar planes en comentarios de pull request o sistemas equivalentes, facilitando revisión por infraestructura, seguridad y responsables de servicio.

Evitar que el pipeline aplique cambios automáticamente en producción sin controles de aprobación, ventana de cambio o revisión de impacto.

Gestionar secretos y credenciales del pipeline con identidades federadas, variables protegidas y permisos mínimos.

Diseñar promoción entre entornos basada en el mismo código y distintas configuraciones, reduciendo divergencias entre dev, preproducción y producción.

Preparar mecanismos de bloqueo para impedir ejecuciones concurrentes sobre el mismo estado desde varios pipelines o usuarios.

Integrar pruebas de módulo, pruebas de contrato, validaciones de política y verificaciones post-apply antes de dar un cambio por completado.

Crear plantillas de pipeline reutilizables para equipos, evitando que cada repositorio invente su propio flujo de Terraform.

Documentar el procedimiento de emergencia cuando un apply falla a mitad, un estado queda bloqueado o un plan muestra destrucciones inesperadas.

Analizar inventarios existentes para decidir qué recursos deben importarse, recrearse, ignorarse o quedar fuera del alcance de Terraform.

Preparar importaciones con identificadores correctos, configuración equivalente y validación posterior para evitar cambios destructivos involuntarios.

Usar `terraform import`, import blocks y herramientas auxiliares según el caso, documentando limitaciones y pasos manuales necesarios.

Comparar el estado importado con la configuración escrita hasta que el plan quede limpio o muestre diferencias entendibles y aceptadas.

Refactorizar recursos importados hacia módulos sin provocar destrucciones, utilizando `moved` blocks y cambios incrementales.

Gestionar recursos creados manualmente que tienen configuraciones inconsistentes, nombres fuera de convención o dependencias no documentadas.

Priorizar importación por dominios críticos: redes, IAM, DNS, almacenamiento, bases de datos, clusters y servicios compartidos.

Preparar ventanas de cambio para recursos sensibles donde un error de importación puede afectar conectividad, seguridad o disponibilidad.

Crear documentación de transición que explique qué se ha importado, qué queda fuera y quién es propietario de cada bloque.

Establecer una estrategia para que, tras la importación, no vuelvan a realizarse cambios manuales sin proceso de reconciliación.

Definir drift como diferencia entre configuración, estado y realidad, entendiendo por qué aparece en entornos gestionados por varios equipos o herramientas.

Detectar cambios manuales en consola cloud, modificaciones de operadores, ajustes urgentes, rotaciones externas y recursos alterados por servicios gestionados.

Establecer procesos de revisión periódica de drift mediante planes programados, HCP Terraform, pipelines o herramientas de observabilidad.

Clasificar drift entre aceptable, temporal, peligroso, urgente o derivado de un diseño incorrecto de Terraform.

Reconciliar cambios fuera de banda incorporándolos al código, revirtiéndolos o excluyéndolos conscientemente con justificación.

Evitar que `ignore_changes` tape problemas reales de gobierno, usándolo solo cuando el proveedor o el servicio modifica campos esperados.

Crear alertas y reportes de drift para propietarios de servicio, seguridad y plataforma, priorizando cambios con impacto en exposición o coste.

Preparar runbooks para drift crítico en IAM, red, DNS, bases de datos, cifrado, backups o políticas de seguridad.

Integrar revisión de drift en comités de cambio, auditoría cloud y mantenimiento preventivo.

Medir reducción de drift como indicador de madurez de infraestructura como código y calidad operativa.

Diseñar una estrategia de pruebas para Terraform que combine validación sintáctica, linting, políticas, pruebas unitarias y pruebas de integración.

Probar módulos con combinaciones de variables representativas, entradas inválidas, valores por defecto, outputs y escenarios de actualización.

Usar Terratest, kitchen-terraform, OpenTofu/Terraform test u otras alternativas cuando el equipo necesite validaciones ejecutables.

Crear entornos efímeros para comprobar despliegues reales sin comprometer producción ni generar costes permanentes.

Validar recursos creados mediante llamadas a APIs cloud, pruebas de conectividad, verificación de etiquetas, cifrado, backups y exposición.

Ejecutar pruebas destructivas controladas para verificar que `destroy` limpia correctamente recursos de laboratorio y no deja residuos costosos.

Probar migraciones de estado, cambios de módulos y actualizaciones de provider antes de aplicarlas a workspaces críticos.

Crear datos de prueba y convenciones de nombres que permitan identificar recursos temporales y eliminarlos de forma segura.

Integrar pruebas en CI/CD con límites de coste, límites de tiempo, credenciales específicas y limpieza automática.

Definir criterios de calidad mínimos para aceptar un módulo corporativo en el registro privado.

Integrar etiquetas obligatorias para centro de coste, propietario, entorno, aplicación, criticidad, ciclo de vida y responsable operativo.

Diseñar variables y módulos que obliguen a definir información económica antes de crear recursos.

Incorporar herramientas de estimación de coste en pull requests o pipelines para revisar impacto financiero antes del apply.

Controlar tamaños, familias de recursos, tipos de almacenamiento, niveles de redundancia y servicios gestionados para evitar sobredimensionamiento.

Crear políticas que bloqueen regiones no autorizadas, recursos caros, falta de apagado en entornos temporales o ausencia de etiquetas.

Diseñar entornos efímeros con caducidad, horarios de apagado, limpieza automática y presupuestos controlados.

Relacionar cambios Terraform con variaciones de coste para facilitar conversaciones entre infraestructura, negocio y finanzas.

Crear dashboards FinOps basados en etiquetas y outputs relevantes, conectando infraestructura desplegada con consumo real.

Revisar decisiones de arquitectura que aumentan coste por alta disponibilidad, cifrado, tráfico, backups, logs o almacenamiento.

Preparar una cultura de coste responsable donde Terraform sirva para prevenir gastos inesperados, no solo para desplegar más rápido.

Definir qué observabilidad debe acompañar a cada recurso desplegado: métricas, logs, trazas, alertas, dashboards y ownership.

Incorporar módulos que desplieguen monitorización junto a infraestructura, evitando crear servicios sin visibilidad operativa.

Configurar diagnósticos cloud, exportación de logs, métricas de red, health checks y alertas de disponibilidad desde Terraform.

Gestionar herramientas como Prometheus, Grafana, Datadog, New Relic, CloudWatch, Azure Monitor o Google Cloud Monitoring según el entorno.

Asociar alertas con equipos responsables, severidad, runbooks, ventanas de mantenimiento y procedimientos de escalado.

Crear outputs y documentación que indiquen dónde observar cada servicio, qué métricas mirar y qué alertas existen.

Evitar módulos que crean infraestructura sin requisitos de observabilidad, backup, mantenimiento o respuesta ante incidencias.

Medir el resultado de cambios Terraform después del apply, comprobando que recursos nuevos están monitorizados y operativos.

Integrar runbooks de infraestructura con cambios de Terraform para que soporte entienda dependencias y riesgos.

Revisar indicadores de operación como disponibilidad, errores, saturación, latencia, consumo, drift y tiempo medio de recuperación.

Diseñar infraestructura con zonas de disponibilidad, regiones, réplicas, backups, snapshots y estrategias de recuperación según criticidad.

Modelar recursos críticos con protección frente a destrucción accidental y controles de aprobación reforzados.

Gestionar backups y políticas de retención mediante Terraform, revisando que la existencia del recurso no sustituye a una restauración probada.

Diseñar planes de recuperación que contemplen estado de Terraform, credenciales, backends, módulos, proveedores, DNS y dependencias externas.

Separar infraestructura primaria y secundaria sin duplicar configuraciones de forma incontrolada ni generar divergencias peligrosas.

Preparar pruebas de restauración en entornos controlados para validar que los recursos pueden recuperarse realmente.

Evaluar impacto de `destroy`, reemplazos y cambios de red en sistemas con alta disponibilidad y usuarios activos.

Crear procedimientos para reconstruir entornos desde código, identificando qué partes son reproducibles y qué datos requieren backups externos.

Integrar Terraform en planes de continuidad de negocio, no solo en despliegues iniciales.

Documentar objetivos RTO/RPO, dependencias, responsables y pasos técnicos para recursos gestionados con Terraform.

Diseñar Terraform como base de una plataforma interna que ofrece módulos aprobados a equipos de producto o desarrollo.

Crear catálogos de infraestructura reutilizable: redes, bases de datos, buckets, colas, clusters, namespaces, certificados y observabilidad.

Definir límites entre equipo de plataforma y equipos consumidores, aclarando quién mantiene módulos, quién configura variables y quién aprueba cambios.

Construir interfaces sencillas mediante módulos, plantillas, repositorios iniciales o portales internos sin ocultar riesgos importantes.

Integrar Terraform con herramientas de autoservicio como Backstage, ServiceNow, GitHub Actions, GitLab CI o Azure DevOps.

Aplicar políticas y validaciones que permitan velocidad sin abrir la puerta a configuraciones inseguras o costes descontrolados.

Medir adopción de plataforma por número de módulos consumidos, tiempo de provisión, reducción de tickets y satisfacción de equipos.

Crear documentación práctica para consumidores, con ejemplos reales, decisiones permitidas y procedimientos de soporte.

Mantener compatibilidad de módulos publicados, gestionando cambios de versión, deprecaciones y comunicación a equipos consumidores.

Diseñar un modelo de soporte interno para incidencias de módulos, providers, permisos, pipelines y cambios de plataforma.

Revisar el cambio de licencia de HashiCorp a Business Source License y su impacto en políticas internas, proveedores, redistribución y ofertas gestionadas.

Entender OpenTofu como alternativa bajo el paraguas de la Linux Foundation y como opción a considerar en estrategias de IaC abiertas.

Evaluar diferencias prácticas entre Terraform y OpenTofu en proveedores, módulos, estado, tooling, soporte, roadmap, ecosistema y requisitos legales.

Definir criterios corporativos para elegir Terraform, HCP Terraform, Terraform Enterprise, OpenTofu u otra plataforma de ejecución.

Analizar dependencias de funcionalidades específicas de HashiCorp, como HCP Terraform, Stacks, políticas, agentes, registros privados o MCP Server.

Preparar una evaluación de riesgo para equipos que ofrecen servicios a terceros, plataformas internas o productos con capacidades IaC.

Documentar decisiones de licencia y herramienta para evitar debates repetidos en cada proyecto o auditoría.

Diseñar pruebas de compatibilidad si la organización quiere mantener una vía de salida o evaluar migración parcial.

Separar estándares de código HCL reutilizables de dependencias exclusivas de una plataforma concreta cuando el negocio lo requiera.

Crear un plan de gobierno que incluya licenciamiento, soporte, actualizaciones, formación interna y revisión periódica de estrategia IaC.

Comprender Terraform MCP Server como una vía para que asistentes de IA accedan a documentación actualizada de providers y módulos.

Evaluar casos de uso seguros de IA en Terraform: explicación de módulos, generación inicial, revisión de errores, documentación y búsqueda de referencias.

Definir límites claros para que la IA no aplique cambios, no acceda a secretos y no sustituya revisiones humanas de planes críticos.

Preparar prompts internos que ayuden a generar HCL alineado con estándares de la empresa, naming, etiquetas, seguridad y módulos aprobados.

Usar IA para revisar planes y cambios propuestos, identificando destrucciones, exposición pública, permisos amplios o costes inesperados.

Incorporar controles frente a alucinaciones, documentación obsoleta, providers incorrectos o argumentos inexistentes sugeridos por modelos genéricos.

Configurar entornos locales o remotos de MCP Server teniendo en cuenta su modelo de seguridad y el acceso a documentación o registros privados.

Crear flujos donde IA asiste al desarrollador de infraestructura, pero Git, CI/CD, políticas y aprobaciones siguen gobernando el cambio.

Documentar decisiones tomadas con ayuda de IA para mantener trazabilidad y evitar que recomendaciones no verificadas lleguen a producción.

Diseñar una guía corporativa de uso de IA en Terraform con usos permitidos, usos prohibidos, revisión obligatoria y tratamiento de datos.

Crear runbooks para errores habituales: bloqueo de estado, fallo de provider, permisos insuficientes, drift inesperado, plan destructivo o credenciales caducadas.

Establecer un proceso de soporte interno para dudas de módulos, pipelines, backends, autenticación, estado y cambios de plataforma.

Definir niveles de severidad para incidencias Terraform según impacto en producción, seguridad, costes, disponibilidad o cumplimiento.

Preparar procedimientos de recuperación ante apply fallido, estado inconsistente, recurso parcialmente creado o cambio interrumpido.

Registrar decisiones de intervención manual y reconciliarlas después en código, evitando que urgencias operativas creen deuda permanente.

Crear un calendario de mantenimiento para actualizar providers, módulos, Terraform CLI, políticas, pipelines y documentación.

Medir indicadores de salud de la práctica Terraform: drift, fallos de pipeline, tiempo de aprobación, módulos reutilizados y errores recurrentes.

Organizar guardias o responsables de plataforma cuando Terraform controla infraestructura crítica para varios equipos.

Mantener una base de conocimiento interna con errores resueltos, decisiones, patrones aprobados y guías de recuperación.

Revisar periódicamente si los procesos de Terraform siguen sirviendo al equipo o se han convertido en burocracia sin valor técnico.

Diseñar una plataforma Terraform completa para una empresa ficticia con red, identidad, seguridad, cómputo, Kubernetes, observabilidad y servicios compartidos.

Crear una estructura de repositorios profesional con módulos internos, entornos separados, backends remotos, documentación y estándares de nombres.

Implementar módulos reutilizables para red, seguridad, almacenamiento, roles, Kubernetes, monitorización y recursos base de aplicaciones.

Configurar estado remoto con locking, permisos restringidos, backups, cifrado y procedimiento documentado de recuperación.

Integrar pipelines CI/CD con validación, linting, análisis de seguridad, plan en pull request, aprobación y apply controlado.

Incorporar políticas de gobierno para etiquetas, regiones, cifrado, exposición pública, tamaños permitidos y prevención de destrucciones críticas.

Configurar credenciales seguras mediante OIDC, dynamic provider credentials o un patrón equivalente adaptado al entorno de laboratorio.

Simular drift, importación, refactorización con `moved` blocks, actualización de provider y resolución de un apply fallido.

Preparar dashboards, alertas, runbooks, documentación de arquitectura y guía de operación para el equipo de infraestructura.

Presentar la solución final justificando decisiones técnicas, seguridad, costes, riesgos, mantenibilidad, escalabilidad y plan de evolución.