12.2-GCP-ACE
|
|
Título del Test:
![]() 12.2-GCP-ACE Descripción: Associate Cloud Engineer GCP |



| Comentarios |
|---|
NO HAY REGISTROS |
|
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. |




