12-GCP-ACE

Un equipo quiere administrar infraestructura de Google Cloud como código declarativo y reproducible. ¿Qué debe usar?. Terraform con el proveedor de Google. Scripts manuales sin estado. Logs Explorer. Cloud Trace.

Has clonado por primera vez una configuración Terraform. ¿Qué comando debes ejecutar antes de planificar?. terraform destroy. terraform init. terraform output. terraform state rm.

Quieres comprobar la sintaxis y coherencia interna de la configuración sin consultar recursos remotos. ¿Qué comando debes ejecutar?. terraform apply. terraform import. terraform validate. terraform destroy.

El repositorio tiene estilos HCL inconsistentes. ¿Qué comando los normaliza automáticamente?. terraform taint. terraform plan. terraform show. terraform fmt.

Antes de cambiar producción quieres ver recursos que se crearán, modificarán o destruirán sin ejecutar acciones. ¿Qué debes usar?. terraform plan. terraform apply -auto-approve. terraform destroy. gcloud projects delete.

Un pipeline debe aplicar exactamente el plan que fue revisado y aprobado. ¿Qué patrón debes usar?. Ejecutar apply en cada portátil sin plan. Guardar el plan con terraform plan -out y pasar ese archivo a terraform apply. Editar el estado manualmente. Usar siempre terraform destroy primero.

¿Qué bloque declara un objeto de infraestructura que Terraform administrará?. output. variable. resource. locals únicamente.

Una configuración usa recursos google_*. ¿Qué componente traduce esos bloques a llamadas de API?. El backend. El módulo raíz. El archivo tfvars. El provider de Google.

Quieres evitar que una actualización futura del proveedor introduzca cambios inesperados. ¿Qué debes declarar?. Restricciones de versión del provider y conservar el archivo de bloqueo en control de versiones. Una IP estática. Una alerta de CPU. Una clave de cuenta de servicio en el repositorio.

Los entornos dev y prod difieren en project_id y región. ¿Cómo debes modelarlo sin duplicar toda la configuración?. Editar literales antes de cada apply. Declarar variables de entrada tipadas y proporcionar valores por entorno. Crear un proveedor distinto por recurso sin motivo. Guardar ambos valores en el estado manualmente.

Un valor de contraseña debe marcarse para no mostrarse normalmente en salidas de CLI. ¿Qué atributo debes usar en la variable u output?. default = public. nullable = false únicamente. sensitive = true. description = secret.

Una variable environment solo puede valer dev, staging o prod. ¿Qué debes añadir?. Un output. Un provider alias. Un data source. Un bloque de validación en la variable.

Quieres proporcionar varios valores complejos de variables sin problemas de escape en la línea de comandos. ¿Qué opción es preferible?. Un archivo .tfvars apropiadamente protegido. Editar el binario de Terraform. Modificar el state con un editor. Usar una etiqueta de Compute Engine.

Un recurso B necesita usar la dirección creada por el recurso A. ¿Cómo debes expresar la dependencia normalmente?. Con un comentario. Referenciando directamente el atributo de A en la configuración de B. Esperando un minuto entre recursos. Añadiendo una variable sin valor.

Existe una dependencia operativa que Terraform no puede inferir de referencias de datos. ¿Qué meta-argumento debes usar de forma explícita?. count. provider. depends_on. lifecycle.ignore_changes.

Debes crear una instancia por cada elemento de un mapa con claves estables. ¿Qué meta-argumento suele ser más adecuado?. output. backend. provisioner. for_each.

Un consumidor necesita conocer la IP creada por el módulo raíz después del despliegue. ¿Qué debes declarar?. Un output que exponga el atributo necesario. Una variable sin valor. Un backend local adicional. Una segunda copia del recurso.

Varios equipos repiten la misma combinación de VPC, subredes y reglas. ¿Cómo debes reducir duplicación?. Copiar y pegar los recursos en cada repositorio. Crear un módulo reutilizable con inputs, recursos y outputs bien definidos. Administrarlos manualmente en la consola. Guardar el state en correo electrónico.

Un módulo publicado cambia con frecuencia. ¿Qué debes hacer para evitar actualizaciones inesperadas en producción?. Omitir siempre la fuente. Descargarlo manualmente cada vez. Fijar una restricción de versión compatible y actualizarla mediante revisión controlada. Editar su código dentro de .terraform.

El módulo hijo crea una red y el módulo raíz debe pasar su ID a otro módulo. ¿Qué interfaz debes usar?. Leer archivos internos de .terraform. Consultar el state con un editor. Duplicar la red. Exponer el ID como output del primer módulo y usarlo como input del segundo.

Un equipo de cinco personas usa Terraform y actualmente guarda terraform.tfstate en el portátil de un desarrollador. ¿Qué mejora es prioritaria?. Configurar un backend remoto en un bucket de Cloud Storage protegido. Enviar el state por chat antes de cada cambio. Incluir el state en un repositorio público. Eliminar el state después de cada apply.

¿Por qué debes tratar el state como información sensible?. Porque solo contiene comentarios. Porque puede incluir atributos y secretos en texto legible aunque estén marcados como sensitive. Porque nunca puede copiarse. Porque reemplaza el código fuente.

Quieres poder recuperar el state después de una escritura errónea o corrupción. ¿Qué debes habilitar en el bucket del backend?. Acceso público. Cloud CDN. Object Versioning y una política de retención adecuada. Una URL firmada sin caducidad.

Dos pipelines intentan modificar el mismo estado simultáneamente. ¿Qué capacidad del backend necesitas para evitar escrituras concurrentes?. Un output adicional. Una label. Un alias de provider. Bloqueo del estado compatible con el backend y serialización del pipeline.

Un recurso ya existe porque fue creado manualmente y quieres que Terraform lo administre sin recrearlo. ¿Qué debes hacer?. Declararlo en la configuración e importarlo al state con la dirección e ID correctos. Ejecutar destroy sobre todo el proyecto. Copiar su JSON al archivo tfvars. Crear otro recurso con el mismo nombre.

Un recurso fue eliminado manualmente fuera de Terraform. ¿Qué mostrará normalmente el siguiente plan?. Nada, porque Terraform nunca consulta APIs. La recreación del recurso si sigue declarado en la configuración. La eliminación automática del código. Un cambio del provider a AWS.

El equipo quiere saber si alguien cambió manualmente un recurso respecto a lo declarado. ¿Qué concepto debe buscar en el plan?. DNS propagation. Cold start. Configuration drift. Log exclusion.

Quieres eliminar de la administración de Terraform un recurso sin destruir el objeto remoto. ¿Qué operación debes realizar con precaución?. terraform destroy. Borrar el proyecto. Eliminar primero el recurso en la consola. Quitar su dirección del state y después ajustar la configuración.

Terraform se ejecuta dentro de Google Cloud. Quieres evitar claves JSON persistentes. ¿Cómo debe autenticarse?. Con credenciales de corta duración de una cuenta de servicio adjunta y Application Default Credentials. Con una clave Owner incluida en Git. Con la contraseña de un empleado. Haciendo públicos todos los recursos.

Terraform se ejecuta en un sistema CI externo. ¿Qué método evita claves de servicio de larga duración?. Una clave HMAC compartida. Workload Identity Federation e impersonación de una cuenta de servicio mínima. Una cuenta personal Owner. Acceso anónimo.

Quieres que el pipeline detecte configuraciones que incumplen políticas antes de aplicar. ¿Qué práctica debes incorporar?. Aplicar directamente en producción. Revisar solo el formato. Validación de políticas sobre el plan, además de fmt, validate y revisión. Eliminar el state.

Un recurso crítico no debe destruirse accidentalmente mediante Terraform. ¿Qué protección local puedes añadir?. count = 0. Un output sensible. Un provider alias. lifecycle { prevent_destroy = true } junto con controles de revisión.

Una API asigna a un atributo un valor diferente al escrito, provocando cambios repetidos sin efecto. ¿Qué debes hacer?. Entender primero el comportamiento del provider y usar ignore_changes solo si aceptar esa gestión externa es intencionado. Ignorar todos los atributos de todos los recursos. Borrar el state. Desactivar la API.

¿Qué dos archivos deben mantenerse normalmente en control de versiones? Selecciona dos respuestas. Los archivos .tf de configuración. .terraform.lock.hcl. terraform.tfstate con secretos. Claves JSON de cuentas de servicio.

Un módulo acepta decenas de variables que nadie cambia y resulta difícil de usar. ¿Qué mejora sigue buenas prácticas?. Añadir aún más variables por si acaso. Eliminar descripciones. Exponer solo valores con un caso real de variación, tiparlos y documentarlos; usar locals para detalles internos. Guardar todos los valores en el state manualmente.

El equipo quiere destruir un entorno efímero administrado completamente por Terraform. ¿Qué debe hacer antes de confirmar?. Ejecutar el comando desde cualquier state disponible. Eliminar el backend remoto. Quitar las copias de seguridad. Revisar el plan de destrucción, confirmar que usa el workspace y state correctos y después ejecutar terraform destroy.