Las entrevistas de DevOps y SRE tratan menos de nombrar herramientas y más de juicio bajo restricciones: qué revertir primero, sobre qué alertar, y qué dejar deliberadamente roto hasta la mañana. Aquí están las preguntas hechas más a menudo, cada una con una respuesta modelo.
Cada pregunta viene con una respuesta modelo con la que puedes comparar la tuya.
1
¿Cuál es la diferencia entre continuous integration, delivery y deployment?
Respuesta
Continuous integration significa que cada commit se mergea y verifica con un build y test automatizados, así la rama nunca se aleja mucho de main. Continuous delivery significa que cada build que pasa produce un artefacto que podría ir a producción, con el push final siendo una decisión humana. Continuous deployment elimina esa decisión — cada build verde se lanza. La distinción importa en entrevistas porque la mayoría de los equipos que dicen practicar CD en realidad practican delivery.
2
¿Cómo funcionan las capas de Docker, y cómo mantienes una imagen pequeña?
Respuesta
Cada instrucción crea una capa de solo lectura, y las capas se cachean y reutilizan mientras todo lo anterior no haya cambiado — por eso copias el manifiesto de dependencias e instalas dependencias antes de copiar el código fuente. El tamaño baja con builds multi-stage que dejan atrás al compilador, una imagen base slim o distroless, y combinando comandos para que los archivos intermedios nunca lleguen a una capa. Borrar un archivo en una capa posterior no achica la imagen, porque la capa anterior todavía lo contiene.
3
Explica la relación entre un Pod, un Deployment y un Service.
Respuesta
Un Pod es la unidad programable más pequeña — uno o más contenedores compartiendo un namespace de red y ciclo de vida. Un Deployment gestiona un ReplicaSet que mantiene un número declarado de Pods idénticos corriendo y maneja actualizaciones rolling y rollbacks. Un Service le da a ese conjunto cambiante de Pods una IP virtual y nombre DNS estables, balanceando carga entre los Pods que actualmente coinciden con su selector, así los callers nunca rastrean IPs de Pods individuales.
4
¿Cuál es la diferencia entre un liveness y un readiness probe?
Respuesta
Un readiness probe decide si un Pod recibe tráfico; fallarlo remueve el Pod de los endpoints del Service pero lo deja corriendo. Un liveness probe decide si el contenedor se reinicia. Confundirlos es una caída clásica: apuntar liveness a una dependencia significa que una base de datos lenta reinicia cada réplica simultáneamente, convirtiendo un servicio degradado en downtime total. Liveness debería testear solo "¿este proceso está atascado?", readiness debería testear "¿puedo servir ahora mismo?".
5
¿Qué es el state de Terraform y por qué es peligroso?
Respuesta
El state mapea los recursos declarados en tu configuración a los objetos reales en el provider, así Terraform puede decir qué crear, cambiar o destruir. Es peligroso porque es autoritativo: si se pierde, Terraform ya no sabe que posee tu infraestructura y va a intentar recrearla. También frecuentemente contiene secretos en texto plano. Por eso el state pertenece a un backend remoto con encriptación, versionado, y locking para que dos ingenieros no puedan aplicar a la vez.
6
¿Cuándo usas Terraform versus Ansible?
Respuesta
Terraform es provisioning declarativo: crea y destruye infraestructura y converge el mundo real hacia tu state declarado. Ansible es gestión de configuración procedural: corre tareas ordenadas contra máquinas que ya existen. La división limpia es Terraform para cualquier cosa con un ciclo de vida en una API de cloud, Ansible para lo que pasa dentro de una VM. En un stack basado en Kubernetes, el rol de Ansible se reduce mucho, porque las imágenes de contenedor reemplazan la configuración de máquinas.
7
¿Qué son SLI, SLO y un error budget?
Respuesta
Un SLI es un indicador medido de la salud del servicio, como la fracción de requests servidos exitosamente bajo 300 ms. Un SLO es el objetivo para ese indicador sobre una ventana, por ejemplo 99.9% en 30 días. El error budget es el déficit permitido — 0.1% de requests — y convierte la confiabilidad en un recurso gastable: si el budget está intacto puedes lanzar más rápido, y si se agotó congelas features y arreglas confiabilidad. Eso es lo que evita que "confiabilidad versus velocidad" sea una discusión de opiniones.
8
¿Cuál es la diferencia entre métricas, logs y traces?
Respuesta
Las métricas son agregados numéricos baratos en el tiempo y responden "¿algo está mal?" — son sobre lo que alertas. Los logs son eventos discretos con detalle y responden "¿qué pasó exactamente?" en un request o componente. Los traces siguen un solo request a través de servicios y responden "¿dónde se fue el tiempo?" en una cadena de llamadas distribuida. Alertar sobre logs es caro y ruidoso; debuggear solo desde métricas es adivinar. Necesitas los tres, usados para lo que cada uno hace bien.
9
Compara los deployments rolling, blue-green y canary.
Respuesta
Rolling reemplaza instancias gradualmente, necesita poca capacidad extra, pero durante el roll dos versiones sirven tráfico y el rollback es lento. Blue-green corre un segundo entorno completo y cambia el tráfico de una vez, dando rollback instantáneo al costo de doble capacidad y un problema difícil de migración de base de datos. Canary envía una pequeña porción de tráfico a la nueva versión y observa métricas antes de ampliar, lo que atrapa problemas que golpean a usuarios reales pero requiere observabilidad sólida y análisis automatizado para que valga la pena.
10
¿Cómo deberían manejarse los secretos en un pipeline?
Respuesta
Los secretos nunca viven en el repositorio, en capas de imagen, o en variables de entorno planas horneadas al momento del build. Vienen de un store dedicado — Vault, un gestor de secretos de cloud, o los secretos encriptados del provider de CI — y se inyectan en runtime con el alcance más estrecho y vida más corta que puedas manejar. Credenciales de vida corta emitidas a través de federación OIDC son mejores que llaves de vida larga, porque el riesgo principal no es el robo de un secreto sino un secreto que se mantiene válido por años.
11
Un Pod está en CrashLoopBackOff. Explica tu diagnóstico.
Respuesta
Empieza con kubectl describe pod para ver eventos — fallos de pull de imagen, montajes fallidos, OOMKilled, o un probe fallando todos aparecen ahí. Luego kubectl logs con --previous, porque el contenedor actual puede ser demasiado joven para haber logueado algo útil. Revisa si el código de salida sugiere OOM, en cuyo caso compara el límite de memoria contra el uso real. Si el contenedor arranca y muere inmediatamente, las causas usuales son un config o secret faltante, una migration fallando al arrancar, o un liveness probe con un delay inicial demasiado corto.
12
¿Qué hace útil a un postmortem en vez de ceremonial?
Respuesta
Un postmortem útil no busca culpables, así la gente describe lo que realmente hizo en vez de lo que se ve defendible, y se enfoca en las condiciones que dejaron que un error se convirtiera en una caída. Registra una línea de tiempo precisa, distingue el disparador de la causa raíz, y produce un pequeño número de action items con dueño y fecha en vez de una lista de deseos. La prueba es si el documento le permitiría a un ingeniero nuevo entender la falla un año después, y si los follow-ups realmente se hacen.