New game
Download
Get Academic Plan
Share game
Integrate it into your platform

You can integrate the game into an LMS compatible with LTI 1.1 or LTI 1.3 such as Canvas, Moodle, or Blackboard. This way, the scores will be automatically saved into the platform’s gradebook.
Download
You have exceeded the maximum number of games you can integrate into Google Classroom with your current Plan.

To integrate as many games as you want in Google Classroom, you need an Academic Plan or a Commercial Plan.

You have exceeded the maximum number of games you can integrate into Microsoft Teams with your current Plan.

To integrate as many games as you want in Microsoft Teams, you need an Academic Plan or a Commercial Plan.

Downloading games is an exclusive feature for users with an Academic Plan or a Commercial Plan.

Get your Academic Plan or your Commercial Plan now and start integrating your games into your LMS, website or blog.

If you wish, you can download a demo game here and test its integration:

Clase 12 y 13

Quiz

Played 1 %Accuracy 88 Average time 00:-1

About this activity

Clase 12 y 13

Created by

Chile

Download the paper version to play

Make your own free game from our game creator
Compete against your friends to see who gets the best score in this game

Top Games

%
Anonymous
Anonymous
%
%
%
You have exceeded the maximum number of games you can print with your current Plan.

To print as many games as you want, you need an Academic Plan or a Commercial Plan.

Print your game
Clase 12 y 13
 

Clase 12 y 13Online version

Clase 12 y 13

by Anibal Alarcon
1

En un flujo DevOps, ¿por qué Git debe entenderse como control del cambio técnico y no solo como almacenamiento de archivos?

2

¿Cuál es la diferencia más precisa entre automatización imperativa y automatización declarativa?

3

¿Qué riesgo principal aparece cuando se modifica directamente la rama main para ahorrar tiempo?

4

¿Por qué el plan de ejecución es una pausa crítica antes de aplicar una definición de IaC?

5

¿Qué caracteriza a un commit útil en un repositorio profesional?

6

En IaC, ¿por qué el drift es especialmente peligroso?

7

¿Qué función cumple un pull request en un flujo Git maduro?

8

¿Cuál es el propósito más correcto de policy as code en una automatización cloud?

9

¿Qué problema resuelve principalmente un archivo .gitignore?

10

¿Qué significa idempotencia en el contexto de IaC?

11

¿Qué diferencia conceptual existe entre tag y release?

12

¿Qué riesgo aparece si el estado de una herramienta IaC se pierde o se corrompe?

13

¿Cuál es la razón más sólida para usar CODEOWNERS o revisores obligatorios en un repositorio?

14

¿Cuándo una tarea cloud es mejor candidata inicial para automatización?

15

¿Por qué squash puede ser útil al integrar una rama?

16

¿Qué función cumple un módulo reutilizable en IaC?

17

¿Qué diferencia hay entre revert y rollback?

18

¿Por qué el bloqueo o locking es relevante en IaC?

19

¿Cuál es el valor principal de una trazabilidad completa issue-commit-pull request-release?

20

¿Qué indica que una plantilla IaC sea un anti-patrón por ser demasiado grande?

21

¿Qué riesgo existe si un secreto se sube a un repositorio?

22

¿Qué aporta el estado deseado en una definición declarativa de infraestructura?

23

¿Por qué una release sin notas dificulta la operación?

24

¿Cuál es la mejor interpretación de “automatizar con criterio”?

Explicación

Git permite saber qué cambió, quién lo cambió, cuándo, por qué y cómo recuperar contexto si algo falla. Su valor está en la trazabilidad y el control del cambio.

La automatización imperativa indica una secuencia de acciones. La declarativa expresa cómo debe quedar el resultado final para que la herramienta lo construya o ajuste.

Main suele representar la línea estable. Modificarla directamente puede incorporar errores sin revisión, sin aprobación y sin una trazabilidad adecuada.

El plan permite revisar impacto antes de ejecutar, especialmente si aparecen eliminaciones, reemplazos, cambios de permisos o modificaciones en el ambiente equivocado.

Un commit útil representa una modificación con propósito claro, facilita revisión, diagnóstico, revert y comprensión futura del cambio.

El drift ocurre cuando la realidad cambia fuera del proceso controlado. Esto dificulta auditoría, repetición, recuperación y futuras ejecuciones de IaC.

El pull request permite revisar cambios antes de integrarlos, dejar comentarios, validar impacto, aprobar y conservar evidencia del proceso.

Policy as code permite validar reglas como cifrado obligatorio, etiquetas de costo, permisos mínimos o bloqueo de reglas abiertas antes de aplicar cambios.

.gitignore define qué archivos no deben entrar al repositorio, reduciendo ruido y evitando subir elementos locales, temporales o generados.

Idempotencia significa que ejecutar varias veces una definición debería mantener el estado esperado, no crear duplicados ni provocar cambios innecesarios.

Un tag identifica un punto específico del historial. Una release normalmente usa ese tag y agrega notas, artefactos o contexto de entrega.

El estado ayuda a la herramienta a relacionar definiciones con recursos reales. Si se daña, puede generar errores, recreaciones o cambios inesperados.

CODEOWNERS ayuda a exigir revisión de responsables sobre rutas sensibles, como seguridad, infraestructura o configuración crítica.

Una tarea repetitiva, estable y de riesgo controlado permite aprender, estandarizar y reducir errores sin comprometer procesos críticos inmaduros.

Squash combina varios commits de una rama en uno más limpio al integrar, útil cuando hubo commits intermedios de prueba o ajuste.

Un módulo agrupa componentes repetibles, como red, almacenamiento o monitoreo, para usarlos de forma más consistente mediante parámetros.

Revert mantiene trazabilidad en el historial creando un nuevo cambio que deshace otro. Rollback es una acción operacional sobre el ambiente o versión desplegada.

El locking ayuda a impedir que dos ejecuciones modifiquen simultáneamente el mismo conjunto de recursos, reduciendo errores de estado y sobrescrituras

La trazabilidad completa permite responder qué originó el cambio, quién lo hizo, quién lo revisó, qué se validó y en qué versión se entregó.

Una plantilla gigante y mezclada aumenta complejidad, dificulta revisión y puede provocar cambios no deseados sobre partes que no deberían tocarse.

Un secreto puede permanecer en el historial o haber sido copiado. Por eso se debe revocar o rotar la credencial y corregir el flujo de prevención.

El estado deseado describe cómo debe quedar la infraestructura, permitiendo detectar diferencias y orientar cambios hacia ese resultado.

Las notas de release comunican cambios, correcciones, advertencias e impacto. Sin ellas, aumenta la incertidumbre para soporte, operación y jefaturas.

Automatizar con criterio significa definir, validar, revisar, aprobar, ejecutar y verificar, manteniendo controles sobre riesgos, permisos, secretos e impacto.

Are you sure you want to leave the page?

If you leave the page, you will lose your game progress.