Test para practicas de Pipelines

¿Cuáles son los tres aspectos de ALM?. A. Gobierno, integración y despliegue. B. Gobierno, desarrollo y operaciones. C. SDLC, CICD y despliegue continuo. D. Desarrollo y operaciones.

¿Qué significa construir, probar y desplegar automáticamente?. A. Escribir unos scripts de bash para cada tarea. B. Definir trabajos en Jenkins y ejecutarlos cada vez que hay un cambio. C. Documentar cada paso del despliegue exhaustivamente. D. Conseguir que los cambios de código inicien una construcción, ejecuten las pruebas y permitan un despliegue sin intervención humana.

¿Por qué es útil desplegar un entorno de producción antes de que acabe el desarrollo?. A. Para probar el proceso de despliegue antes de la fecha clave. B. Para comprobar que el sistema funciona bien en este entorno, que puede ser y será diferente de los entornos de desarrollo. C. Para aumentar la fiabilidad del proceso. D. Todas las anteriores.

¿Qué significa gestionar automáticamente la configuración?. A. Mantener la configuración de cada entorno separada del script de despliegue y con un control de versiones. B. Escribir scripts separados, uno por entorno, que no dependan de ningún otro fichero. C. Guardar la configuración aplicada en cada entorno en una base de datos. D. Ninguna de las anteriores.

¿Cuál es el objetivo de la integración continua?. A. Obligar a los desarrolladores a integrar cambios todos los días para controlar lo que hacen. B. Implantar una herramienta moderna como Jenkins. C. Aumentar la calidad del código detectando los errores lo más pronto posible y la velocidad a la que se entrega a los clientes. D. Ninguna de las anteriores.

¿Cuál es el objetivo de la entrega continua?. A. Aumentar la fiabilidad del código, reduciendo el número de errores. B. Reducir el tiempo necesario para entregar software en producción. C. Aumentar la fiabilidad de los procesos de despliegue. D. Todas las anteriores.

¿Qué diferencia hay entre entrega y despliegue continuos?. A. Ninguna, son sinónimos. B. La entrega deja el producto listo para desplegar después de cada cambio, pero no tiene por qué desplegar en producción. El despliegue continuo prosigue el flujo de la entrega múltiples veces al día hasta completar el despliegue en producción. C. La entrega solo compila el código, el despliegue, además, incorpora las pruebas. D. Ninguna de las anteriores.

¿Qué se puede esperar de las construcciones de software en una organización que no ha empezado a madurar en la integración continua?. A. El pase a producción es automático, fiable e indoloro. B. Los cambios en la base de datos se ejecutan manualmente. C. La construcción es manual y no se gestionan los artefactos. D. No hay batería de pruebas alguna.

¿En qué debe centrar sus esfuerzos una organización que intenta mejorar su calidad de software?. A. En aquellos aspectos del proceso de integración y entrega que sean más dolorosos. B. En automatizar todo el proceso cuanto antes. C. En desplegar la aplicación sobre Kubernetes. D. En versionar todos los elementos de la configuración.

¿Cuál de estos elementos es fundamental para empezar a aplicar integración continua?. A. Un sistema de control de versiones. B. Una batería de pruebas y automatización. C. Aceptación del equipo. D. Todos los anteriores.

¿En qué consiste un commit?. A. Es el proceso de incluir un fichero en un sistema de control de cambios. B. Es un conjunto de cambios registrados en la historia de un sistema de control de cambios. C. Es una carpeta con los ficheros de una versión de la aplicación. D. Es el cambio a un punto anterior de la historia del repositorio.

¿Qué debería ser versionado?. A. El código fuente de la aplicación. B. La documentación. C. Las herramientas de despliegue. D. Todos los anteriores.

¿En qué consiste la edición simultánea?. A. Varios desarrolladores editan un mismo fichero y uno de ellos combina los cambios del resto manualmente. B. Un desarrollador bloquea un fichero para trabajar sobre él. C. Varios desarrolladores trabajan sobre el mismo repositorio y probablemente sobre los mismos ficheros y el sistema se encarga de fusionar los cambios de todos automáticamente. D. Ninguna de las anteriores.

Relaciona el concepto con su definición. Commit. Rama. Repositorio. Fusión.

¿Qué significa «viajar en el tiempo» en el contexto de los sistemas de control de versiones?. A. Que se pueden instalar versiones antiguas de una aplicación. B. Que las nuevas versiones son compatibles con las anteriores. C. Que un desarrollador puede trabajar en una versión antigua del repositorio. D. Ninguna de las anteriores.

¿Qué metadatos incluyen los commits?. A. Autor. B. Fecha. C. Comentarios. D. Todos los anteriores.

¿Cómo se recomienda versionar las dependencias de una aplicación?. A. Copiando el código fuente de la dependencia dentro de una carpeta del repositorio de la aplicación. B. Manteniendo un documento con instrucciones sobre cómo instalarla. C. Referenciando la versión de la dependencia como una librería e instalándola con un gestor de paquetes durante el despliegue. D. Todas los anteriores son estrategias válidas.

¿Cómo se crea una nueva rama llamada feature en Git?. A. git checkout -b feature. B. git branch feature. C. git create branch feature. D. A y B.

¿Por qué un sistema de control de versiones distribuido no necesita bloqueo de archivos?. A. Sí que lo necesita. B. Porque cada usuario trabaja con una copia completa del repositorio. C. Porque son sistemas más antiguos y limitados. D. Porque cada usuario es propietario de un fichero y solo ese usuario puede modificarlo.

¿Por qué no se puede aplicar el flujo de GitHub en un sistema de control de versiones centralizado?. A. Técnicamente se puede, aunque no es habitual. B. Porque solo funciona con GitHub, que se basa en Git, que es un sistema de control de versiones distribuido. C. Porque se basa en los conceptos de fork y pull requests, que solo ofrecen los sistemas distribuidos. D. Ninguna de las anteriores.

¿Cuántas ramas soporta el flujo centralizado?. A. Solo una, master o trunk. B. Solo una en el repositorio principal y tantas como sean necesarias en los forks. C. Una principal y una de desarrollo. D. Una principal, una de desarrollo y tantas como sean necesarias para las funcionalidades nuevas.

¿Por qué una rama de hotfix se fusiona tanto a master como a develop en el Gitflow?. A. Solo se fusiona a master, no a develop. B. En Gitflow las modificaciones se fusionan en develop y este se fusiona sobre master, siempre. C. Por convenio. Técnicamente no hace falta. D. Porque el cambio es necesario en producción y debe estar disponible en master, pero; además, hay que incorporarlo en cualquier prueba que se esté realizando en el desarrollo de la siguiente versión.

¿Se puede implementar feature branching con GitHub sin usar pull requests?. A. No, en GitHub es obligatorio usar pull requests. B. Sí, porque GitHub ofrece la funcionalidad de abrir pull requests dentro de un mismo repositorio, que son otro tipo de pull requests. C. Sí, feature branching puede implementarse en cualquier tipo de sistema de control de versiones centralizado o distribuido. D. B y C.

¿Cómo se crea un fork en GitHub?. A. En la interfaz de GitHub, haciendo clic sobre el botón Fork. B. Con git fork new. C. Con git clone --fork . D. En la interfaz de GitHub, en el asistente de New repository, hay que seleccionar que se trata de un fork e indicar el repositorio principal.

Relaciona cada flujo con su característica. Flujo centralizado. Feature branching workflow. Flujo de GitLab. Forking workflow.

Un desarrollador no tiene acceso de escritura al repositorio principal repo y ha trabajado en una rama new-feature en su fork. Al abrir la pull request, ¿cuál es la rama de origen y cuál es la de destino?. A. El origen es repo:new-feature y el destino es repo:master. B. El origen es fork/repo:new-feature y el destino es repo:master. C. El origen es fork/repo:new-feature y el destino es repo:new-feature. D. El origen es repo:new-feature y el destino es fork/repo:master.

¿Qué significa que un repositorio local pueda tener varios repositorios remotos?. A. En un sistema distribuido un repositorio puede intercambiar ramas y commits con cualquier otro repositorio. Estos otros repositorios se consideran remotos, y puede definirse más de uno. B. Lo normal es que haya un único repositorio remoto: el fork del usuario. C. Git solo permite un repositorio remoto, pero Subversion permite varios. D. Ninguna de las anteriores.

En Gitflow, ¿por qué se dice que cada fusión sobre master es una nueva versión?. A. No es cierto; en Gitflow se trabaja únicamente con master. B. Porque se añade una etiqueta con el número de la versión a esos commits. C. Por convenio, en master no se añaden commits que no se hayan planificado para una versión concreta. D. Por convenio, las ramas de características nuevas se fusionan sobre master justo antes de preparar la nueva versión. Se fusionan todas juntas, por lo que master está listo para producción.

¿Cuántas fases de prueba tiene un pipeline de CICD?. A. Tres: unitarias, de aceptación automáticas y de aceptación manuales. B. Tantas como seannecesarias en cada proyectode desarrollo. C. Solo una, la inicial. D. Cinco: unitarias, estáticas, de aceptación automática, de aceptación manual y smoke tests.

¿Cuándo debe detenerse un pipeline?. A. Cuando se detecta un error de sintaxis en el código. B. Cuando falla la compilación. C. Cuando falla una de las pruebas. D. Todas lasanteriores.

¿Cuándo no hace falta compilar un software?. A. Siempre es necesario compilar el software. B. Cuando se trata de Java, ya que el bytecode no es realmente una compilación. C. En lenguajes interpretados. D. En lenguajes compilados.

¿Por qué es necesario empaquetar un software?. A. Solo es necesario empaquetar si el lenguaje es compilado. B. Para facilitar la distribución e instalación. C. Para incluir ficheros necesarios para el funcionamiento, como configuraciones y ficheros estáticos. D. B yC.

¿En qué consiste un smoke test?. A. Es una prueba sencilla que permite comprobar si un sistema ha arrancado correctamente, incluyendo todas sus dependencias. B. Es una prueba sin estado ni base de datos. C. Es una prueba manual en la que se verifican funcionalidades ofrecidas al usuario. D. Es una comprobación del servicio para saber si ha arrancado o no.

¿Por qué hay que construir una única vez?. A. Para acelerar el proceso. B. Para asegurar que el paquete que ha pasado las pruebas es el mismo que se despliega en producción. C. A y B. D. No es necesario. De hecho, conviene construir en cada fase para paralelizar mejor.

¿Qué propiedades deben tener los scripts de despliegue?. A. Deben estar incluidos en el control de cambios. B. Se debe usar el mismo script para desplegar todos los entornos. C. El script debe aplicar diferentes configuraciones encada en torno,que obtiene de una ubicación diferente (del control de cambios o de un gestor de configuraciones). D. Todas a las anteriores.

¿En qué consiste desplegar una copia de producción?. A. En clonar el sistema de producción, antes de los despliegues, como copia de seguridad. B. En desplegar, en un entorno lo más parecido posible a producción, en una fase de prueba para reducir el riesgo del despliegue en producción. C. Esto se consigue con despliegues blue/green: se despliega una copia de producción y se apuntan los balanceadores a la nueva instancia. D. Ninguna de las anteriores.

¿Por qué un pipeline no sirve para proyectos que funcionan con pull requests?. A. Sí que se pueden usar. B. Porque entonces no hay una construcción única del paquete. C. Porque el flujo no se puede adaptar. D. Porque es un desperdicio construir el paquete para todas las pull requests.

¿Cómo debería ser una prueba unitaria?. A. Rápida. B. Independiente del estado. C. Dirigida a una única función. D. Todas las anteriores.

¿Qué pruebas requieren que la aplicación esté arrancada?. A. De sistema. B. De rendimiento. C. De aceptación. D. Todas lasanteriores.

¿Cuáles de las siguientes se pueden considerar pruebas no funcionales?. A. De rendimiento. B. De cobertura. C. De seguridad. D. Todas las anteriores.

¿Por qué es útil que el desarrollador pueda acceder a los resultados de las pruebas?. A. En general no lo necesitan. B. Para poder estudiar el error y ser capaz de corregirlo. C. Para identifi car quién ha roto el código. D. Ninguna de las anteriores.

Relaciona los tipos de pruebas con sus características. Unitarias. De sistema. De GUI. De rendimiento.

¿Para qué sirve el decorador @pytest.mark.unit?. A. Convierte una prueba de servicio en unitaria. B. Para evitar la ejecución de una prueba. C. Etiqueta la prueba en la batería de pruebas unit. D. Exporta el informe de la prueba en formato JUnit.

¿Qué significa que una prueba de GUI se ejecute en un navegador headless?. A. En el navegador no tiene una ventana visible. B. Que es un navegador en modo texto, por lo que no ejecutará código JavaScript. C Que el navegador se ejecuta en un servidor remoto sin pantalla. D. Ninguna de las anteriores.

¿Qué son los informes JUnit?. A. Ficheros XML exclusivos de pruebas en Java. B. Ficheros XML resultado de ejecución de pruebas. C. Ficheros XML exclusivos de pruebas unitarias. D. Ficheros PDF archivados por las herramientas de CICD.

¿Cómo se pueden paralelizar las pruebas?. A. Aprovechando la ejecución en múltiples hilos. B. Separando las pruebas en baterías y ejecutándolas en paralelo. C. Todas las anteriores. D. En general no se puede y deben ejecutarse en serie.

¿Para qué sirve una fixture?. A. Para fi jar el resultado de una prueba. B. Para fijar un estado conocido antes de ejecutar una prueba y devolver el entorno al estado original al terminar. C. Para borrar la base de datos al terminar las pruebas. D. Para deshabilitar una prueba puntualmente.

¿Por qué las revisiones de código deberían estar incorporadas en el flujo de integración continua?. A. Para que los compañeros del equipo puedan aportar feedback antes de que el código esté fusionado en la rama principal. B. Porque todos los pasos del desarrollo deben estar integrados en una única herramienta de CICD. C. No tienen por qué estar integradas, las revisiones deben ser siempre presenciales y antes de que se envíe el commit. D. Ninguna de las anteriores.

¿En qué casos es obligatorio que una revisión apruebe una pull request en GitHub para poder fusionarla?. A. En cualquier caso. B. Cuando se activa la protección de rama. C. Cuando el autor de la pull request no es administrador del repositorio. D. Cuando se abre la pull request en modo borrador.

¿Qué tipo de reglas se tienen en cuenta en una convención de estilo?. A. La longitud máxima de línea. B. El formato de los nombres de variables y funciones. C. El número máximo de líneas de una función. D. Todas las anteriores.

¿Por qué los proyectos adoptan convenciones de estilo?. A. Para que el código sea más legible. B. Para facilitar el mantenimiento por desarrolladores diferentes al autor. C. Para aumentar la consistencia entre módulos. D. Todas las anteriores.

¿Qué mide la cobertura?. A. El número de pruebas unitarias. B. El número de pruebas totales, incluyendo unitarias, de integración y UI. C. El porcentaje de líneas que se ejecutan durante las pruebas. D. El número de líneas de código.

¿Es una cobertura del 100 % sinónimo de riesgo cero?. A. Claro, porque se han ejecutado todas las líneas del código durante las pruebas. B. Claro, porque no tiene sentido escribir más pruebas. C. No, porque llegar al 100 % no es posible. D. No, porque eso no implica que se hayan probado todas las condiciones y valores de frontera.

¿Qué valor aporta Sonar a un proyecto?. A. La evaluación de la calidad del proyecto desde diferentes puntos de vista. B. El seguimiento de la evolución de la calidad a lo largo del tiempo. C. La identificación de problemas potenciales. D. Todas las anteriores.

¿Por qué es deseable reducir la complejidad del código?. A. Para que el código sea más legible. B. Para facilitar el mantenimiento por desarrolladores diferentes al autor. C. La A y la B. D. Para poder pasar el umbral de aceptación de Sonar.

¿Qué significa que Sonar utilice un agente?. A. Que un proceso se encarga de analizar el código y de enviar los resultados a un servidor central. B. Que hay que subir el código a un servidor central para su análisis. C. Que hay que instalar un software adicional junto con el producto para poder analizarlo. D. Todas las anteriores.

¿En qué consisten los perfiles de calidad de Sonar?. A. En un proyecto concreto. B. En todas las reglas posibles de un lenguaje. C. En un umbral de complejidad que marca el proyecto como válido. D. En conjuntos de reglas que se evalúan durante el análisis de los proyectos a los que se asigna el perfil.

¿Qué trabajos se pueden programar en Jenkins?. A. Compilación. B. Pruebas. C. Despliegues. D. Todas las anteriores.

¿Cuál es la contraseña por defecto de Jenkins?. A. admin. B. Password1!. C. Es aleatoria, Jenkins la imprime por la salida estándar. D. No hay contraseña por defecto, el inicio de sesión es automático.

¿Dónde debe definirse el código de un pipeline?. A. En un Jenkinsfi le en el repositorio. B. En la definición del trabajo. C. Los trabajos se definen en un formulario web donde se escribe el código a ejecutar. D. Todas las anteriores.

¿Sobre qué plataformas puede ejecutar un proyecto Jenkins?. A. Sobre cualquier que soporte Java. B. Solo sobre Linux, ya que Jenkins es de código abierto. C. En Windows, Debian y RedHat. D. Ninguna de las anteriores.

¿Para qué sirve archivar artefactos?. A. Para hacer una copia de seguridad de los informes de pruebas. B. Para que Jenkins pueda mostrar los informes de pruebas. C. Para almacenar el resultado de una compilación, una construcción o de un informe de pruebas, junto a los detalles de la ejecución. D. Todas las anteriores.

¿Cómo se puede configurar un trabajo para que se ejecute cuando hay cambios en un repositorio?. A. Configurando un webhook en GitHub sobre Jenkins. B. Haciendo una comprobación periódica del repositorio. C. A través de una petición a la API de Jenkins desde un Githook. D. Todas las anteriores.

¿Qué configuración hay que usar para ejecutar un trabajo de Jenkins a cada hora?. A. A partir de un webhook en un sistema con cron. B. Un trigger periódico y una agenda 0 * * * *. C. Una comprobación periódica del repositorio con una agenda 0 * * * *. D. Todas las anteriores.

¿Qué relación hay entre «trabajo» y «ejecución» en Jenkins?. A. Son sinónimos. B. Un trabajo se ejecuta en el master, mientras que los agentes se encargan de las ejecuciones. C. Un trabajo es una definición de un pipeline y la ejecución es cada una de las fases del pipeline. D. Un trabajo es una definición de una tarea que puede tener varias fases; una ejecución es una activación concreta del trabajo con unos parámetros y un resultado concretos.

¿Cómo se indica que debe ser la ejecución de un trabajo en un nodo con herramientas de compilación de Java?. A. Con la sentencia label 'maven' en la sección del agente. B. Con la sentencia label 'java' en la sección del agente. C. Asignando una etiqueta concreta a los agentes con herramientas de compilación e indicando esa etiqueta en la sentencia label ''. D. Todas las anteriores.

¿Qué servicios ofrece GitLab?. A. Repositorio remoto de Git. B. Pipelines de CICD. C. Registros de paquetes. D. Todos los anteriores.

¿Cómo se llama la funcionalidad de pull request de GitLab?. A. Pull request. B. Merge request. C. Join request. D. Branch merge.

¿Dónde se defi nen las fases de un pipeline en GitLab?. A. En el fichero .gitlab-ci.yml, en la raíz del repositorio. B. En la interfaz de GitLab, en la sección de opciones del repositorio. C. En Jenkins, a través del plugin de GitLab. D. Todas las anteriores son opciones válidas.

¿Dónde se ejecutan los trabajos de un pipeline en GitLab?. A. En el servidor principal, si no hay runners asociados al proyecto, o en los runners asociados. B. En los runners asociados al proyecto, en los compartidos entre varios proyectos. C. En los agentes de Jenkins a través del plugin de GitLab. D. En el servidor principal de GitLab.

¿Cómo se determina el orden de ejecución de fases y trabajos?. A. Las fases se ejecutan secuencialmente. B. Los trabajos de una misma fase se ejecutan en paralelo. C. Los trabajos empiezan tan pronto terminan sus dependencias. D. Todas las anteriores.

¿Para qué sirve la directiva artifacts?. A. Para guardar archivos o directorios que serán utilizados en fases posteriores del pipeline. B. Para guardar archivos o directorios que deben estar disponibles para los usuarios al terminar el pipeline. C. Para recopilar informes de pruebas, cobertura o análisis de seguridad y mostrarlos en la interfaz de GitLab. D. Todas las anteriores.

¿Cuándo se ejecuta un pipeline en GitLab?. A. Cuando hay un cambio en una rama, ya sean etiquetas de Git o commits nuevos. B. Cuando se abre una merge request a partir de una rama de un fork. C. Es necesario arrancarlas manualmente desde la interfaz de GitLab o con el comando gitlab-runner start. D. Ninguna de las anteriores.

¿Cuándo se borran las imágenes del registro de contenedores?. A. Manualmente. B. Al fi nalizar el pipeline, a menos que se etiqueten con *-latest. C. Tras un intervalo configurable, a menos que estén incluidas como excepción. D. A los noventa días.

¿Cuándo se ejecuta el contenido de before_script?. A. Al inicio del pipeline. B. Antes de iniciar cada trabajo, siempre y cuando el trabajo no sobreescriba la sección beforescript explícitamente. C. Antes de iniciar cada trabajo. D. Al terminar cada trabajo.

¿Cuándo se detiene un pipeline?. A. Se pueden detener manualmente. B. Si un trabajo falla, la siguiente fase no se ejecuta, pero los trabajos que se pongan en marcha en paralelo pueden terminar. C. Se pueden cancelar automáticamente si la rama recibe más cambios durante la ejecución de su pipeline. D. Todas las anteriores.

¿Con qué sistemas de control de versiones distribuidos es compatible Bitbucket?. A. GitHub. B. Git. C. Mercurial. D. SVN.

¿En qué fichero se definen los pipelines de CircleCI?. A. .circleci/confi g.yml. B. gitlab-ci.yml. C. Jenkinsfi le. D. .circle-ci.yml.

¿Cómo se ejecutan los trabajos de un workflow de CircleCI?. A. Secuencialmente. B. En paralelo. C. En paralelo por defecto, salvo que se definan dependencias entre ellos. D. Secuencialmente por defecto, salvo que se indique que pueden ejecutarse en paralelo.

¿Se puede seguir un flujo de trabajo de GitHub con Bitbucket?. A. No, en todo caso se podría seguir el flujo de trabajo de Bitbucket. B. No, porque Bitbucket no soporta forks ni pull requests. C. No, aunque sí que soporta el flujo de trabajo de GitLab. D. Sí, ya que soporta la creación de forks y pull requests.

¿Con qué servicios de control de versiones se integra CircleCI?. A. GitHub y Bitbucket. B. GitHub, GitLab y Bitbucket. C. Con cualquiera que ofrezca un plugin, como Jenkins. D. Con cualquiera que use Git como sistema de control de versiones.

¿A partir de qué cambios se ejecuta un pipeline de CircleCI?. A. Creación de ramas nuevas y cambios en ramas existentes. B. Creación de pull requests. C. Creación de etiquetas de Git, si se activan explícitamente. D. Cualquiera de las anteriores.

¿En qué consiste un orb de CircleCI?. A. En una plantilla con fases habituales para un sistema concreto. B. En un paquete YAML reutilizable. C. Código reutilizable, bien privado o público, ofrecido habitualmente por las propias organizaciones. D. Todas las anteriores.

¿Qué ventaja tiene usar Nexus como proxy?. A. Acelera la descarga de paquetes en una red local. B. Aísla a los sistemas internos de posibles caídas de servicio de repositorios públicos. C. Centraliza el acceso a Internet a un único sistema en sistemas privados donde esta conectividad está restringida. D. Todas las anteriores.

¿Cuándo tiene sentido usar Nexus como repositorio para paquetes o imágenes?. A. Cuando los proyectos son privados y no se desea alojarlos en un repositorio público. B. Cuando se quiere acelerar la publicación de paquetes. C. Cuando no se dispone de una cuenta en el repositorio público. D. Ninguna de las anteriores.

¿Qué gestores de paquetes soporta Nexus?. A. npm. B. docker. C. apt. D. Todas las anteriores.

Qué significa que un despliegue no tenga pérdida de servicio?. A. Que ofrece todas las funcionalidades durante todo el proceso de despliegue. B. Que puede no prestar servicio durante un período de tiempo anunciado previamente como «mantenimiento». C. Que, en la mayoría de los casos, los usuarios pueden seguir accediendo, pero las respuestas del sistema pueden ser inconsistentes. D. Que el despliegue siempre es exitoso y nunca hay vuelta atrás.

Relaciona el concepto con su característica principal. Blue/green. Actualización incremental. Canary releasing. Feature flag.

¿Por qué el esquema de datos se puede convertir en un problema si dos versiones conviven en el tiempo?. A. En general, no suele ser un problema. Las bases de datos se encargan de mantener el esquema. B. Porque dos servidores con versiones diferentes pueden escribir el mismo registro a la vez provocando un bloqueo. C. Porque el código nuevo puede escribir un dato con un esquema incompatible con el código antiguo. D. Porque habría que aplicar una subida de esquema si accede la versión nueva, y una bajada de esquema si accede la versión antigua.

¿Cómo se pueden actualizar sistemas dependientes sin que haya problemas de compatibilidad?. A. Ofreciendo una API que siempre sea compatible hacia atrás. B. Versionando la API, de forma que se pueda actualizar un sistema dependiente a la siguiente versión en cualquier momento. C. Actualizándolos siempre en conjunto. D. Todas las anteriores.

¿Por qué se ha dicho que el modelo de despliegue blue/green ofrece todo o nada?. A. Porque actualiza los servidores in situ, sin desplegar ninguno nuevo. B. Porque en un momento dado, todos los servidores quedan servicio tienen la misma versión del código. C. Porque solo sirve para todos los sistemas de una aplicación. D. Ninguna de las anteriores.

¿Qué ventajas ofrece el Canary releasing frente a un despliegue blue/green?. A. Si se introduce un error en la nueva versión, solo afecta a los usuarios del servidor canario. B. Si se detecta un error, se puede detener el servidor canario o dejar de dirigirle tráfico, sin necesidad de modificar los otros servidores en funcionamiento. C. Puede usarse para pruebas A/B. D. A y B son correctas.

¿Cuánto tiempo conviven dos versiones en un despliegue incremental?. A. Desde que se despliega el primer servidor con la nueva versión hasta que se apaga el último de la versión antigua. B. No conviven ambas versiones, ya que se modifica el enrutador de tráfico instantáneamente para que apunte a la versión nueva o a la antigua. C. Desde que se despliega el servidor canario hasta que se sustituyen todos los demás servidores. D. Ninguna de las anteriores.

¿Qué significa que los despliegues y la oferta de funcionalidades deba desacoplarse?. A. Que hay que desplegar las versiones cuando se decida ofrecer una funcionalidad concreta. B. Que la fecha de un despliegue no tiene por qué coincidir con la exposición de una nueva funcionalidad a los usuarios. C. Que un despliegue debe estar disponible para todos los usuarios exactamente al mismo tiempo. D. Que los despliegues deben estar controlados por configuraciones definidas en una feature flag.

¿Qué usos se le puede dar a una feature flag?. A. Desplegar funcionalidades de manera incremental a nivel de usuario. B. Bloquear funcionalidades secundarias de manera global. C. Experimentar con usuarios reales en producción. D. Todas las anteriores.

¿Cómo detecta Kubernetes si un pod ha arrancado correctamente?. A. Si hay suficientes ejecuciones exitosas consecutivas de la sonda readinessProbe. B. Una vez desplegado un contenedor, Kubernetes lo considera disponible automáticamente. C. Si el proceso no termina automáticamente tras initialDelaySeconds segundos. D. Ninguna de las anteriores.