20 Preguntas de Práctica de Automatización, CI/CD y control de versiones con Respuestas

1. 1. Un administrador debe garantizar que en cuarenta servidores haya un paquete instalado, un servicio habilitado y un archivo de configuración con un contenido concreto, y el procedimiento debe poder repetirse cada semana sin riesgo. ¿Por qué una definición declarativa de gestión de configuración se adapta mejor a esto que un script de shell que ejecuta en orden los comandos de instalación y habilitación?

   • A.Ejecuta los mismos comandos en el mismo orden en cada host, así que el resultado no varía entre servidores.
   • B.Se ejecuta por completo en el shell de cada host, de modo que no hace falta intérprete ni software de gestión.
   • C.Declara el estado final de cada recurso y la herramienta solo modifica lo que aún no coincide.✓ Respuesta
   • D.Registra cada comando en el orden en que se ejecutó, así que cualquier host puede reconstruirse repitiendo ese registro.

   Una definición declarativa nombra el estado final deseado de cada recurso; la herramienta lee el estado actual del host y actúa solo donde ambos difieren, por eso puede aplicarse cada semana sin causar daño. Un script se limita a repetir sus comandos y en un host ya configurado puede fallar, duplicar trabajo o reiniciar un servicio que no necesitaba cambio.

   Ref. QB-V5MYWUFuente: CompTIA Linux+ exam objectives, Automation, Orchestration and Scripting domain: infrastructure as code and declarative desired stateReportar un problema con esta pregunta

2. 2. Una definición de configuración se aplica por segunda vez a un host sin haberla modificado, y la ejecución informa de cuatro recursos comprobados y ninguno cambiado. ¿Qué propiedad de la herramienta demuestra este resultado?

   • A.Idempotencia, porque aplicar la misma definición a un host que ya coincide con ella no provoca ningún cambio más.✓ Respuesta
   • B.Atomicidad, porque una ejecución aplica todos sus recursos o los revierte todos en conjunto.
   • C.Orquestación, porque la ejecución coordina el orden del trabajo entre varios hosts.
   • D.Modo de comprobación, porque la ejecución compara y solo informa de lo que cambiaría.

   La idempotencia significa que aplicar una definición a un host que ya coincide con ella no cambia nada, de modo que la segunda ejecución informa de recursos comprobados y no cambiados. Esa segunda ejecución silenciosa es la señal de convergencia que busca el administrador; informar de cambios sin aplicarlos sería una ejecución de prueba, no una aplicación normal.

   Ref. QB-EN5GPWFuente: CompTIA Linux+ exam objectives, Automation, Orchestration and Scripting domain: idempotence in configuration managementReportar un problema con esta pregunta

3. 3. Un cambio en una definición de configuración afecta a todos los hosts web de producción. Antes de alterar nada, el administrador quiere una lista de los archivos y servicios que la ejecución modificaría. ¿Cuál es el paso adecuado?

   • A.Aplicar la definición en modo de comprobación, que compara cada recurso con el host e informa sin modificar nada.✓ Respuesta
   • B.Aplicar la definición con casi todos los recursos comentados, dejando activa solo una parte para evaluarla.
   • C.Aplicar la definición primero en un host de producción y leer sus archivos para deducir qué harán los demás.
   • D.Aplicar la definición con el máximo detalle de registro y revisar después el registro para ver qué recursos se modificaron.

   El modo de comprobación, llamado habitualmente ejecución en seco, evalúa cada recurso contra el host real e imprime las diferencias que aplicaría sin escribir nada, que es justo la vista previa necesaria antes de tocar producción. Leer los registros tras una aplicación real llega tarde, porque los hosts ya se han modificado.

   Ref. QB-W5YA4WFuente: CompTIA Linux+ exam objectives, Automation, Orchestration and Scripting domain: configuration management dry run (check mode) before applying changesReportar un problema con esta pregunta

4. 4. La política del centro prohíbe instalar cualquier demonio residente adicional en los hosts gestionados, mientras que el acceso administrativo por el servicio de inicio de sesión remoto cifrado ya está permitido. ¿Qué modelo de gestión de configuración encaja con esa restricción?

   • A.Un modelo pull, en el que un cliente residente en cada host obtiene y aplica periódicamente su catálogo.
   • B.Un modelo pull, en el que el servidor central abre una sesión a cada host e instala el cliente que necesita.
   • C.Un modelo push, en el que un host de control se conecta por el acceso remoto permitido y aplica el trabajo.✓ Respuesta
   • D.Un modelo push, en el que cada host receptor usa un temporizador local para clonar el repositorio y aplicarlo.

   Un modelo push sin agente no necesita nada residente en los hosts gestionados: el host de control se conecta por el transporte de inicio de sesión remoto ya permitido, hace el trabajo y se desconecta, así que solo él lleva el software de gestión. Los modelos pull dependen de un cliente instalado que contacta periódicamente con un servidor central, justo el demonio residente que la política prohíbe.

   Ref. QB-FNGTUXFuente: CompTIA Linux+ exam objectives, Automation, Orchestration and Scripting domain: agentless push versus agent-based pull configuration managementReportar un problema con esta pregunta

5. 5. Una misma definición de configuración debe fijar una raíz de documentos distinta en los servidores web y un valor de memoria distinto en los de base de datos, sin mantener dos copias de la definición. ¿Cómo debe organizarse?

   • A.Listar los hosts en un inventario plano y aplicar la definición dos veces, una con cada juego de valores.
   • B.Listar los hosts en un inventario plano y mantener a mano una copia de la definición para cada tipo de host.
   • C.Listar los hosts en el inventario, agruparlos como web y de base de datos, y fijar los valores por grupo.✓ Respuesta
   • D.Listar los hosts en el inventario y escribir los valores finales en los archivos que se copian a cada host.

   El inventario enumera los hosts gestionados y los coloca en grupos, y las variables de cada grupo aportan los valores que difieren, así que una sola definición con archivos de configuración basados en plantillas sirve para ambos tipos de host. Duplicar la definición o incrustar valores fijos anula la razón de mantener una única fuente de verdad revisable.

   Ref. QB-X5BN9XFuente: CompTIA Linux+ exam objectives, Automation, Orchestration and Scripting domain: inventory of managed hosts, host groups and group variablesReportar un problema con esta pregunta

6. 6. En una revisión se encuentra una contraseña de base de datos escrita en claro dentro de una plantilla confirmada en el repositorio de configuración. Más allá del desorden, ¿por qué se trata esto como un incidente de seguridad?

   • A.Las plantillas se procesan solo en el host de control, así que un valor en claro nunca llega a un host gestionado.
   • B.El repositorio guarda los objetos comprimidos, así que un valor en claro daña el objeto al cambiar el archivo.
   • C.Un valor en claro se vuelve a leer en cada ejecución, la definición deja de ser idempotente e informa de cambios.
   • D.Cualquiera que pueda leer el repositorio y su historial ya posee esa contraseña, y borrarla después no la despublica.✓ Respuesta

   Un repositorio de configuración es legible por todos los que tienen acceso y conserva cada versión anterior de cada archivo, así que una credencial confirmada debe considerarse divulgada y hay que rotarla; borrarla en un commit posterior la deja en el historial. Los secretos van en un almacén cifrado o un gestor de secretos al que la definición hace referencia en ejecución, nunca en claro en el repositorio.

   Ref. QB-GNU52ZFuente: CompTIA Linux+ exam objectives, Automation, Orchestration and Scripting domain: secret handling in infrastructure-as-code repositoriesReportar un problema con esta pregunta

7. 7. Una publicación exige que la migración del esquema en el host de base de datos termine antes de actualizar los hosts de aplicación, y la configuración del balanceador solo puede cambiarse después de eso. ¿Qué capacidad se está describiendo?

   • A.Orquestación, porque el trabajo debe secuenciarse entre hosts distintos y no dentro de uno solo.✓ Respuesta
   • B.Gestión de configuración, porque el estado declarado de cada host ya fija cuándo se cambia.
   • C.Instalación desatendida, porque el archivo de respuestas de cada host decide el orden del despliegue.
   • D.Control de versiones, porque el orden de los commits en el repositorio fija el orden de aplicación.

   Coordinar pasos en un orden obligatorio entre máquinas distintas es orquestación. La gestión de configuración declara en qué estado debe estar cada host, pero una definición de estado deseado no expresa por sí sola que un host deba terminar antes de que otro empiece.

   Ref. QB-Y5PYEYFuente: CompTIA Linux+ exam objectives, Automation, Orchestration and Scripting domain: orchestration across hosts compared with configuration managementReportar un problema con esta pregunta

8. 8. Aplicar un cambio de la definición reinicia el servicio de la aplicación. Treinta hosts de aplicación idénticos están tras un balanceador de carga y aplicarlo en todos a la vez provocó la última vez una caída total. ¿Cuál es el enfoque correcto?

   • A.Aplicar el cambio a todos los hosts a la vez, retrasando cada reinicio del servicio unos segundos al azar.
   • B.Aplicar el cambio a unos pocos hosts por vez y esperar a que cada lote pase su comprobación de salud.✓ Respuesta
   • C.Aplicar el cambio a un solo host y dejar los demás en el estado anterior para poder compararlos.
   • D.Aplicar el cambio a todos los hosts a la vez fuera del horario laboral, cuando cabe una caída breve.

   Desplegar el cambio por lotes y condicionar cada lote a una comprobación de salud mantiene la mayor parte del conjunto atendiendo tráfico mientras el cambio se demuestra, así que un cambio defectuoso cuesta una fracción de la capacidad y no todo el servicio. Reiniciar todos los hosts a la vez, aunque se escalone unos segundos, puede dejar sin backends al mismo tiempo.

   Ref. QB-HN7G72Fuente: CompTIA Linux+ exam objectives, Automation, Orchestration and Scripting domain: rolling deployment in batches during orchestrated releasesReportar un problema con esta pregunta

9. 9. Un equipo quiere que sea imposible que un cambio llegue a la línea principal compartida si la batería de pruebas automáticas no ha pasado sobre ese cambio. ¿Qué disposición lo consigue?

   • A.Que la canalización se ejecute cada noche en la línea principal y revierta lo integrado desde la última vez.
   • B.Que la canalización se ejecute en la línea principal tras cada fusión y avise al autor si algo falla.
   • C.Que cada autor ejecute las pruebas en su equipo y declare en la descripción que todo ha pasado.
   • D.Que la canalización se ejecute sobre el cambio propuesto y bloquee la fusión hasta que pasen las pruebas.✓ Respuesta

   La integración continua controla la fusión: la canalización se ejecuta sobre el cambio propuesto antes de integrarlo y la fusión sigue bloqueada hasta que la etapa de pruebas informe de éxito, con lo que la línea principal se mantiene compilable por construcción. Probar solo tras la fusión, o fiarse de un pase declarado en local, deja entrar primero el cambio defectuoso.

   Ref. QB-Z52BMZFuente: CompTIA Linux+ exam objectives, Automation, Orchestration and Scripting domain: CI/CD pipelines and shift-left testingReportar un problema con esta pregunta

10. 10. Cada cambio que pasa la canalización se compila, se prueba y se empaqueta como candidato a publicación, pero un responsable de versiones todavía debe aprobar el paso a producción. ¿Qué práctica es esta y qué único cambio la convertiría en la otra?

    • A.Despliegue continuo; volver a situar las pruebas automáticas antes de la aprobación es lo que daría entrega continua.
    • B.Integración continua; añadir una etapa de empaquetado tras las pruebas es lo que daría despliegue continuo.
    • C.Entrega continua; añadir una segunda aprobación antes de producción es lo que daría integración continua.
    • D.Entrega continua; quitar la aprobación humana para que la compilación se publique sola da despliegue continuo.✓ Respuesta

    La entrega continua significa que toda compilación que pasa queda demostrada como publicable mientras una persona decide cuándo se publica; el despliegue continuo elimina esa decisión y la compilación válida se promueve sola a producción. El factor que las distingue es la aprobación humana, no las pruebas ni el empaquetado, comunes a ambas.

    Ref. QB-MASA2VFuente: CompTIA Linux+ exam objectives, Automation, Orchestration and Scripting domain: continuous delivery compared with continuous deploymentReportar un problema con esta pregunta

11. 11. Un defecto aparece solo en producción. La investigación muestra que cada entorno compila la aplicación por separado desde el código, así que los binarios resultantes difieren. ¿Qué práctica elimina esta clase de problema?

    • A.Reconstruir en cada entorno pero fijar las versiones del compilador y las bibliotecas para igualarlas.
    • B.Construir el artefacto una vez, guardarlo y promoverlo por pruebas, preproducción y producción.✓ Respuesta
    • C.Reconstruir en cada entorno, comparar las sumas de comprobación y volver a construir donde difieran.
    • D.Construir primero en producción y copiar ese árbol de fuentes a pruebas y preproducción.

    Construir el artefacto una sola vez y promover ese mismo artefacto almacenado por cada entorno significa que lo probado es lo desplegado, así que el defecto ya no puede venir de una diferencia de compilación entre entornos. Reconstruir en cada entorno reintroduce variación de compilación y el binario de producción nunca fue el que aprobaron las pruebas.

    Ref. QB-5TXFMVFuente: CompTIA Linux+ exam objectives, Automation, Orchestration and Scripting domain: CI/CD pipeline artifacts and promotion between environmentsReportar un problema con esta pregunta

12. 12. Una canalización compila, prueba y publica un archivo en cada commit. Después un ingeniero descarga ese archivo y lo copia a mano en los servidores. ¿Por qué esto todavía no es un despliegue automatizado?

    • A.El archivo pierde su suma de comprobación al descargarlo una persona y los servidores no pueden verificarlo.
    • B.Una canalización no puede publicar un archivo si su etapa de despliegue no está en la misma definición.
    • C.Una copia manual siempre va a la ruta equivocada porque faltan las variables de entorno de la canalización.
    • D.El último paso no queda registrado ni puede repetirlo una máquina, así que el resultado depende de quién lo haga.✓ Respuesta

    Un despliegue automatizado está definido como código, lo dispara la canalización y se puede repetir sin intervención humana. Una copia manual no queda registrada ni revisada y varía según quién la haga, así que ese paso es el que debe trasladarse a la canalización antes de llamar automatizado al despliegue.

    Ref. QB-NA5N7WFuente: CompTIA Linux+ exam objectives, Automation, Orchestration and Scripting domain: CI/CD pipeline automation of the deployment stageReportar un problema con esta pregunta

13. 13. Se han editado tres archivos del árbol de trabajo. Solo dos de esos cambios deben ir en la siguiente confirmación y el tercero debe quedarse como edición local. ¿Cuál es la acción correcta?

    • A.Confirmar los tres archivos y añadir el tercero a la lista de exclusión para que no se registre.
    • B.Confirmar los tres archivos y luego enmendar la confirmación para sacar de ella el tercero.
    • C.Preparar los dos archivos deseados y confirmar, porque la confirmación registra lo que está preparado.✓ Respuesta
    • D.Guardar los tres archivos en el alijo y confirmar, porque la confirmación toma la última entrada.

    Una confirmación registra el contenido del área de preparación, no todo el árbol de trabajo, así que preparar solo los dos archivos deseados confirma exactamente esos cambios y deja el tercero como edición local sin confirmar. La lista de exclusión no afecta a un archivo ya seguido, y guardar en el alijo retira los cambios en vez de confirmarlos. Confirmar todo y luego enmendar para sacar el tercer archivo es un rodeo, no la acción correcta.

    Ref. QB-6TATSWFuente: Git documentation, git-add and git-commit manual pages: the index (staging area) as the source of a commitReportar un problema con esta pregunta

14. 14. Una rama de característica de larga vida se ha quedado por detrás de la línea principal. El equipo quiere que su trabajo aparezca como una línea recta sobre la punta actual de la principal y no unido por un commit de fusión. ¿Qué hace un rebase y qué límite impone?

    • A.Mueve la etiqueta de la rama a la nueva base sin tocar ningún commit, así que las copias ajenas siguen siendo válidas.
    • B.Reproduce los commits de la rama sobre la nueva base como commits nuevos, por eso no debe usarse en historia compartida.✓ Respuesta
    • C.Une las dos historias en un commit con dos padres, y eso es lo que mantiene lineal la historia principal.
    • D.Descarta los commits propios de la rama y conserva solo el más reciente, por lo que no puede haber conflicto.

    El rebase escribe commits nuevos, con identidad nueva, sobre la nueva base, y eso es lo que produce una historia lineal sin commit de fusión. Como los commits originales se sustituyen en lugar de conservarse, rebasar trabajo que otros ya han obtenido les deja dos versiones del mismo cambio, por lo que el rebase se limita a commits no publicados.

    Ref. QB-PAGYCXFuente: Git documentation, git-rebase manual page: replaying commits and the warning against rebasing published commitsReportar un problema con esta pregunta

15. 15. Un commit que introduce un defecto se publicó en el remoto compartido hace días y varios compañeros ya lo han obtenido. ¿Cuál es la forma adecuada de deshacerlo?

    • A.Reescribir la historia para eliminar el commit y forzarlo al remoto, porque el error debe desaparecer.
    • B.Borrar la rama compartida en el remoto y publicar otra que contenga solo los commits deseados.
    • C.Restablecer la rama local al commit anterior y seguir confirmando trabajo nuevo desde ahí.
    • D.Registrar un commit nuevo que revierta el cambio, dejando intacta la historia ya publicada.✓ Respuesta

    Cuando un commit ya está publicado y otros lo tienen, deshacerlo con seguridad significa registrar un commit nuevo que revierta su contenido, porque así la historia de cada clon existente sigue siendo válida y solo se añade la corrección. Reescribir la historia publicada y forzarla rompe todos los clones que ya contienen los commits antiguos.

    Ref. QB-7TN5YXFuente: Git documentation, git-revert manual page: undoing a commit that has already been sharedReportar un problema con esta pregunta

16. 16. Meses después de una publicación, un operador debe poder extraer exactamente el código que se publicó, aunque la rama desde la que se publicó haya recibido muchos commits desde entonces. ¿Qué debería haberse hecho al publicar?

    • A.Etiquetar el commit de la versión, porque una etiqueta apunta siempre a un commit fijo y la rama avanza.✓ Respuesta
    • B.Anotar la fecha de la versión, porque se puede buscar en el historial el commit vigente ese día.
    • C.Guardar una copia del paquete, porque después no se puede saber qué commit lo produjo.
    • D.Anotar el nombre de la rama en las notas, porque una rama siempre resuelve al código que se publicó.

    Una etiqueta es una referencia fija y con nombre a un commit concreto, así que sigue identificando el código publicado mucho después de que la rama haya avanzado. El nombre de una rama resuelve siempre al commit más reciente de esa rama, por eso no sirve para nombrar una versión pasada.

    Ref. QB-QAUAJYFuente: Git documentation, git-tag manual page: tags as fixed references to a release commitReportar un problema con esta pregunta

17. 17. Un archivo de registro generado se confirmó por error y ahora aparece como modificado tras cada ejecución. El administrador añade su ruta a la lista de exclusión del repositorio, pero sigue apareciendo como modificado. ¿Por qué?

    • A.La lista de exclusión solo compara directorios, así que una entrada de un único archivo se descarta.
    • B.La lista de exclusión no surte efecto en el repositorio hasta que se cree la siguiente etiqueta.
    • C.La lista de exclusión solo afecta a rutas sin seguimiento, así que hay que dejar de seguir el archivo.✓ Respuesta
    • D.La lista de exclusión se obtiene del remoto, así que la entrada debe publicarse para que se aplique.

    Las reglas de exclusión solo se consultan para rutas que aún no se siguen, así que un archivo ya confirmado permanece bajo seguimiento y se sigue informando como modificado. Hay que dejar de seguirlo, conservándolo en el disco, para que la entrada de exclusión surta algún efecto.

    Ref. QB-8TZF5ZFuente: Git documentation, gitignore manual page: ignore patterns apply only to untracked filesReportar un problema con esta pregunta

18. 18. Un asistente produce una función de shell que rota y comprime archivos de registro y a primera vista parece correcta. El administrador va con retraso. ¿Cuál es la forma responsable de proceder?

    • A.Confirmarla y ejecutarla ya en producción, y restaurar de la copia de seguridad si algo va mal.
    • B.Leer cada línea, comprobar que hace lo previsto y probarla en un sistema que no sea de producción.✓ Respuesta
    • C.Confirmarla sin cambios e indicar en el mensaje que fue generada, de modo que la responsabilidad recaiga en el revisor.
    • D.Ejecutarla en producción y pedir después al asistente que la explique como paso de revisión.

    El código generado es responsabilidad de quien lo confirma: puede estar sutilmente equivocado, desactualizado para la familia de distribución en uso o llevar una licencia que la organización no puede aceptar, y nada de eso se ve a primera vista. Leerlo línea por línea y ejercitarlo fuera de producción es la revisión, y no puede delegarse en la herramienta que lo escribió.

    Ref. QB-RA7NQZFuente: CompTIA Linux+ exam objectives, responsible use of AI: avoid copy and paste without review, verify outputReportar un problema con esta pregunta

19. 19. Al depurar una definición de automatización que falla, un administrador quiere pegar el archivo completo en un asistente alojado. El archivo contiene un token de API, nombres de host internos y un identificador de cuenta de cliente. ¿Qué debe hacerse primero?

    • A.Subir el archivo sin cambios, porque el texto del prompt es efímero y se descarta al cerrar.
    • B.Eliminar antes el token y los datos identificativos, o usar un modelo local en toda la sesión.✓ Respuesta
    • C.Pegar el archivo sin cambios añadiendo una frase que prohíba conservarlo o entrenar con él.
    • D.Incluir solo la credencial, porque un token por sí solo no se vincula con su sistema de origen.

    El contenido enviado a un modelo alojado sale del control de la organización y puede conservarse o usarse para entrenamiento, así que hay que quitar credenciales, identificadores internos y datos de clientes antes de enviarlo, o trabajar con un modelo local que mantenga los datos dentro. Una instrucción escrita en el prompt es una petición, no un control exigible, y la política corporativa rige la elección.

    Ref. QB-9TCTA2Fuente: CompTIA Linux+ exam objectives, responsible use of AI: data governance and private versus public modelsReportar un problema con esta pregunta

20. 20. Un asistente devuelve una única línea de comando destinada a borrar archivos obsoletos bajo un árbol de directorios, con dos opciones que el administrador nunca ha usado. ¿Cuál es el manejo correcto?

    • A.Leer la página de manual del comando y sus opciones y probarlo sobre una copia desechable de los datos.✓ Respuesta
    • B.Ejecutarlo en producción con privilegios elevados, ya que el fallo habitual es la falta de permisos.
    • C.Preguntar al asistente si el comando es seguro y tomar esa respuesta como verificación del comando.
    • D.Ejecutarlo sobre el árbol de producción, porque el comando devuelto se valida contra el sistema antes.

    Un comando destructivo es igual de destructivo generado que escrito a mano, y una línea generada suele llevar opciones cuyo comportamiento real difiere de la descripción que la acompaña. Comprobar cada opción en la página de manual del propio sistema y ensayar el comando sobre datos desechables es la verificación; pedir al asistente que avale su salida no verifica nada.

    Ref. QB-YJG6MMFuente: CompTIA Linux+ exam objectives, responsible use of AI: verify generated output and test outside productionReportar un problema con esta pregunta

Preguntas de práctica redactadas según los objetivos publicados del examen CompTIA Linux+ y la práctica estándar de administración de Linux. CompTIA y Linux+ son marcas de CompTIA, y Linux es una marca registrada de Linus Torvalds; este sitio no está afiliado ni respaldado por CompTIA. El examen real combina preguntas de opción múltiple con preguntas basadas en desempeño que piden ejecutar una tarea en un entorno simulado: eso no puede reproducirse en un formato de cuatro opciones, así que este banco cubre la mitad teórica y conviene practicar en un sistema real en paralelo. CompTIA revisa y numera las versiones de los objetivos periódicamente: confirma los objetivos, el código de examen y los requisitos vigentes con CompTIA antes de examinarte. Sobre la certificación CompTIA Linux+ →