25 Preguntas de Entrevista DevOps Imprescindibles en 2026
Las entrevistas DevOps son una bestia diferente. No te van a pedir que inviertas un árbol binario ni que debatas sobre REST vs GraphQL. Te van a preguntar cómo desplegarías en producción un viernes a las 3 de la tarde, qué pasa cuando el pipeline se rompe a mitad de un release, y si alguna vez te han despertado a las 2 de la madrugada por una alerta de un servicio que tú mismo construiste.
He estado en ambos lados de estas entrevistas — decenas de veces. El patrón es siempre el mismo: los entrevistadores no evalúan lo que memorizaste. Evalúan lo que has operado. Pipelines rotos, tests inestables, contenedores que se niegan a arrancar, alertas que suenan en el peor momento posible. Ese es el verdadero temario.
Estas 25 preguntas aparecen constantemente en entrevistas DevOps — en startups, scale-ups y grandes empresas. Están agrupadas por dominio para que puedas enfocarte donde más lo necesitas. Para cada una, te explico qué busca realmente el entrevistador y cómo estructurar una respuesta que deje huella.
CI/CD — El Pipeline Es el Producto
Si hay un área que sale en todas y cada una de las entrevistas DevOps, es CI/CD. No solo “sabes qué significan las siglas” — sino si puedes diseñar, debuggear y defender un pipeline bajo presión.
1. ¿Cuál es la diferencia entre integración continua, entrega continua y despliegue continuo?
Lo que buscan: Si entiendes el espectro, no solo los acrónimos. CI significa mergear y testear código frecuentemente. Entrega continua significa que el artefacto siempre está listo para desplegar pero un humano pulsa el botón. Despliegue continuo significa que va a producción automáticamente.
Consejo para responder: No te limites a definirlos. Di cuál has practicado realmente y por qué. “Hacíamos entrega continua porque nuestro equipo de compliance necesitaba una aprobación manual antes de producción” vale diez veces más que una definición de libro.
2. ¿Cómo diseñarías un pipeline CI/CD desde cero para un nuevo microservicio?
Lo que buscan: Pensamiento estructurado. ¿Puedes razonar por etapas — lint, tests unitarios, build, tests de integración, escaneo de seguridad, push del artefacto, despliegue en staging, smoke tests, despliegue en producción?
Consejo para responder: Recórrelo secuencialmente. Menciona qué bloquea el pipeline en cada etapa. A los entrevistadores les encanta oír sobre diseño fail-fast: “Si el lint falla, nada más se ejecuta. No tiene sentido construir un artefacto roto.”
3. Un despliegue acaba de fallar en producción. Explícame tu estrategia de rollback.
Lo que buscan: Madurez operativa. ¿Te entra el pánico o tienes un plan? Blue-green, canary, feature flags, rollback de migraciones de base de datos — quieren detalles.
Consejo para responder: Describe un rollback real que hayas hecho. Cuanto más caótico, mejor. “Teníamos una migración de base de datos que no se podía revertir, así que usamos un feature flag para desactivar la nueva ruta de código mientras escribíamos un forward-fix.” Ese tipo de historia se queda grabada.
4. ¿Cómo manejas los secretos en un pipeline CI/CD?
Lo que buscan: Conciencia de seguridad. Los secretos hardcodeados en archivos YAML siguen siendo escandalosamente comunes. Quieren oír sobre integraciones con vault, variables con scope por entorno, políticas de rotación.
Consejo para responder: Nombra las herramientas específicas que has usado — secretos de GitHub Actions, HashiCorp Vault, AWS Secrets Manager. Luego menciona lo que nunca harías: commitear secretos en git, mostrarlos en los logs del pipeline, pasarlos como build arguments en Docker.
5. ¿Cómo manejas los tests flaky en un pipeline?
Lo que buscan: Pragmatismo. Todo el mundo tiene tests flaky. La pregunta es si los pones en cuarentena, si monitoreas métricas de flakiness, si haces retry con cuidado, o si simplemente relanzas el pipeline y cruzas los dedos.
Consejo para responder: “Etiquetábamos los tests flaky conocidos y los corríamos en una etapa separada no bloqueante mientras arreglábamos las causas raíz. Hacíamos seguimiento del ratio de flake cada semana. Si un test llevaba más de dos sprints siendo flaky, lo arreglábamos o lo eliminábamos.” Eso demuestra madurez de proceso.
Contenedores y Orquestación — Donde la Teoría se Encuentra con la Trinchera
Docker y Kubernetes dominan esta sección. Si solo has hecho tutoriales, aquí es donde se va a notar.
6. ¿Qué pasa cuando ejecutas docker run?
Lo que buscan: Profundidad. ¿Conoces las capas de imagen, el runtime del contenedor, los namespaces, los cgroups? ¿O solo conoces el comando?
Consejo para responder: Recórrelo capa por capa. “El daemon de Docker descarga la imagen si no está en caché, crea una capa de contenedor con escritura encima de las capas de la imagen, configura namespaces para aislamiento de procesos y cgroups para límites de recursos, y luego inicia el proceso del entrypoint.” Ese nivel de detalle separa a los operadores de los que siguen tutoriales.
7. ¿Cuál es la diferencia entre una imagen Docker y un contenedor?
Lo que buscan: Un modelo mental claro. Una imagen es una plantilla de solo lectura. Un contenedor es una instancia en ejecución de esa plantilla con una capa de escritura encima.
Consejo para responder: Usa una analogía si ayuda — “Una imagen es una clase, un contenedor es una instancia” — pero sigue inmediatamente con algo concreto. “Puedo lanzar cinco contenedores desde la misma imagen, cada uno con su propio estado, sus logs y su identidad de red.”
8. Explica cómo funciona el scheduling de Kubernetes.
Lo que buscan: Si entiendes el control plane. El API server acepta la spec del pod, etcd la almacena, el scheduler evalúa la idoneidad de los nodos (recursos, taints, tolerations, reglas de afinidad), y el kubelet en el nodo elegido descarga la imagen e inicia el contenedor.
Consejo para responder: Menciona un problema real de scheduling que hayas tenido. “Teníamos pods atascados en Pending porque nuestro node pool no tenía suficiente margen de memoria. Agregar requests y limits arregló el scheduling, pero también reveló que llevábamos meses sobre-provisionando CPU e infra-provisionando memoria.”
9. ¿Cómo depurarías un pod atascado en CrashLoopBackOff?
Lo que buscan: Un enfoque de debugging sistemático. No solo “mira los logs” — sino una secuencia: kubectl describe pod, revisar events, kubectl logs (incluyendo el contenedor anterior), exec en un sidecar, verificar los probes de readiness/liveness, revisar los resource limits.
Consejo para responder: Preséntalo como una checklist que realmente sigues. Los entrevistadores quieren ver que no te vas a paralizar cuando algo se rompa en producción. Puntos extra si mencionas que CrashLoopBackOff a menudo significa que la aplicación está fallando, no Kubernetes.
10. ¿Cuándo NO usarías Kubernetes?
Lo que buscan: Criterio. Kubernetes es potente pero costoso en complejidad. Si tienes tres servicios con un equipo pequeño, ECS o incluso Docker Compose puede ser la decisión correcta.
Consejo para responder: Esta es una pregunta de madurez. “Kubernetes tiene sentido cuando tienes suficientes servicios y suficientes miembros de equipo para justificar la carga operativa. Para un equipo pequeño que despliega dos servicios, yo elegiría ECS Fargate o Cloud Run. Menos que gestionar, más rápido para entregar.” Los entrevistadores adoran a los candidatos que saben cuándo no sacar la artillería pesada.
Infrastructure as Code — Reproducibilidad o Arrepentimiento
Las preguntas de IaC evalúan si has sufrido el dolor de los cambios manuales de infraestructura y saliste con disciplina.
11. ¿Por qué es importante la Infrastructure as Code?
Lo que buscan: No un discurso de ventas sobre Terraform. Quieren oír sobre reproducibilidad, trazabilidad, colaboración, detección de drift y recuperación ante desastres.
Consejo para responder: Cuenta una historia de terror. “Teníamos un entorno configurado manualmente durante dos años. Cuando necesitamos replicarlo para una auditoría de compliance, costó tres ingenieros y dos semanas. Después de migrar a Terraform, levantar un entorno nuevo tomaba 20 minutos.” Historias como esa son la razón de ser de la IaC.
12. ¿Cómo gestionas el state de Terraform, y qué puede salir mal?
Lo que buscan: Profundidad operativa. State locking, backends remotos (S3 + DynamoDB, Terraform Cloud), corrupción de state, importación de recursos creados manualmente, exposición de secretos en el archivo de state.
Consejo para responder: Menciona un problema de state que hayas tenido. “Una vez dos ingenieros ejecutaron terraform apply al mismo tiempo antes de que configuráramos el state locking. Un apply sobrescribió los cambios del otro. Perdimos una NAT gateway y tuvimos que reimportarla manualmente.” Ese tipo de cicatriz es lo que los entrevistadores respetan.
13. ¿Cuál es la diferencia entre Terraform y Ansible?
Lo que buscan: Tu comprensión de declarativo vs imperativo, provisionamiento vs gestión de configuración. Terraform crea infraestructura. Ansible configura lo que corre sobre ella. Se solapan, pero el punto fuerte es diferente.
Consejo para responder: “Terraform le dice al cloud qué debe existir. Ansible le dice a las máquinas cómo estar configuradas. He usado ambos juntos — Terraform aprovisiona las instancias EC2, Ansible instala y configura la aplicación. Son complementarios, no competidores.”
14. ¿Cómo estructuras Terraform para múltiples entornos?
Lo que buscan: Habilidades de organización reales. Workspaces vs estructura de directorios. Módulos para reutilización. Archivos de variables por entorno. State remoto con backends específicos por entorno.
Consejo para responder: Describe tu layout real de carpetas. “Usábamos una estructura directorio-por-entorno — environments/dev, environments/staging, environments/prod — cada uno llamando a los mismos módulos raíz con diferentes tfvars. Los workspaces nos parecían demasiado implícitos para el tamaño de nuestro equipo.”
15. ¿Cómo manejas los breaking changes en Terraform?
Lo que buscan: Conciencia del riesgo. Renombrar un recurso lo destruye y lo recrea. Cambiar la versión de un provider puede introducir drift. Los state moves, imports y targeted applies tienen todos sus trampas.
Consejo para responder: “terraform plan es sagrado. Nunca aplicábamos sin revisar el plan. Y cuando necesitábamos renombrar recursos, usábamos terraform state mv primero para evitar la destrucción. Una vez alguien renombró una instancia RDS en el código sin mover el state — Terraform intentó destruir y recrear la base de datos de producción. La revisión del plan lo atrapó.”
Monitoreo y Observabilidad — Porque Desplegar Es Solo la Mitad del Trabajo
Entregar código sin monitoreo es como conducir sin luces. Los entrevistadores lo saben, y van a evaluar si tú también.
16. ¿Cuál es la diferencia entre monitoreo y observabilidad?
Lo que buscan: Matices. El monitoreo te dice cuándo algo va mal (alertas, dashboards). La observabilidad te dice por qué — usando logs, métricas y trazas juntos para diagnosticar problemas que no habías previsto.
Consejo para responder: “El monitoreo es la alarma de humo. La observabilidad es tener el plano del edificio, sensores de calor y una cámara para descubrir dónde empezó el fuego y por qué.” Luego anclarlo en lo real: “Teníamos dashboards para latencia y tasas de error, pero no podíamos debuggear fallos entre servicios hasta que agregamos tracing distribuido con Jaeger.”
17. ¿Cómo decides sobre qué alertar?
Lo que buscan: Disciplina. Alertar sobre todo crea ruido. Alertar sobre nada crea ceguera. Quieren oír sobre SLOs, presupuestos de error, y alertas basadas en síntomas vs causas.
Consejo para responder: “Alertábamos sobre síntomas visibles para el usuario — tasa de errores por encima del 1%, p99 de latencia por encima de 500ms — no sobre métricas internas como CPU. Un CPU alto no es un problema si los usuarios no se ven afectados. Quemamos a nuestro equipo de guardia una vez con alertas ruidosas antes de aprender esa lección.”
18. Explica los conceptos de SLO, SLI y SLA.
Lo que buscan: Si puedes conectar conceptos abstractos con operaciones reales. El SLI es la métrica (latencia de las peticiones), el SLO es el objetivo (99,9% de peticiones por debajo de 200ms), el SLA es el contrato de negocio con consecuencias.
Consejo para responder: Sé concreto. “Nuestro SLI era respuestas API exitosas divididas entre el total de respuestas. Nuestro SLO era 99,95% en una ventana de 30 días. Eso nos daba un presupuesto de error de unos 22 minutos de downtime al mes. Cuando consumimos la mitad del presupuesto en un solo incidente, pausamos el desarrollo de features para estabilizar.”
19. ¿Cómo abordas el logging en una arquitectura de microservicios?
Lo que buscan: Logging estructurado, agregación centralizada, correlation IDs, niveles de log, políticas de retención. No solo “usamos ELK.”
Consejo para responder: “Cada servicio emite logs JSON estructurados con un correlation ID que fluye a través de todas las llamadas downstream. Enviamos todo a un sistema centralizado — usábamos Loki, pero ELK o Datadog funcionan igual. Lo clave es poder buscar por correlation ID y reconstruir el recorrido completo de una petición a través de todos los servicios.”
20. ¿Qué es el tracing distribuido y cuándo lo usarías?
Lo que buscan: Tu comprensión de la propagación del contexto de traza, los spans, y cuándo el tracing aporta valor vs cuándo es excesivo. El tracing brilla en microservicios donde una sola petición toca cinco o más servicios.
Consejo para responder: “Agregamos tracing con OpenTelemetry cuando intentábamos debuggear un pico de latencia que los logs solos no podían explicar. Resultó que un servicio downstream hacía una llamada síncrona a una API de terceros que a veces tardaba 3 segundos. Sin tracing, habríamos culpado al servicio equivocado durante semanas.”
Cultura y Proceso — La Parte que Realmente Define DevOps
DevOps es una cultura antes que una cadena de herramientas. Los entrevistadores que hacen estas preguntas están evaluando si tú entiendes eso.
21. ¿Qué significa DevOps para ti?
Lo que buscan: No una definición de diccionario. Quieren oír sobre responsabilidad compartida, bucles de feedback rápidos, automatización como principio, y romper silos entre desarrollo y operaciones.
Consejo para responder: “Para mí, DevOps es la práctica de hacer que todo el equipo sea responsable de lo que pasa después de que el código se escribe — no solo antes. Si yo lo escribo, debo poder desplegarlo, monitorearlo, y que me llamen cuando se rompe. Esa responsabilidad cambia cómo escribes código.”
22. ¿Cómo manejas un incidente de producción?
Lo que buscan: Proceso. ¿Tienes un framework de incidentes? ¿Roles (incident commander, comunicador, debugger)? ¿Clasificación de severidad? ¿Revisiones post-incidente?
Consejo para responder: Recorre un incidente real. “Tuvimos un SEV-1 cuando nuestro servicio de pagos se cayó. Yo era el incident commander. Abrimos una war room, asignamos roles, comunicamos el estado cada 15 minutos a los stakeholders, identificamos la causa raíz en 40 minutos — un pool de conexiones mal configurado — y escribimos un postmortem blameless al día siguiente.”
23. ¿Qué es un postmortem blameless y por qué importa?
Lo que buscan: Si entiendes la seguridad psicológica en ingeniería. Culpar lleva a ocultar. La ausencia de culpa lleva a aprender.
Consejo para responder: “Un postmortem blameless se enfoca en lo que el sistema permitió que pasara, no en quién lo hizo. Preguntamos ‘¿por qué el sistema permitió que este despliegue pasara sin canary?’ no ‘¿por qué pusheaste ese código roto?’ El objetivo es arreglar el proceso, no castigar a la persona. Los equipos que culpan dejan de reportar incidentes. Los equipos que aprenden de sus incidentes se vuelven más resilientes.”
24. ¿Cómo equilibras la velocidad de entrega con la fiabilidad del sistema?
Lo que buscan: El concepto SRE de presupuestos de error. Se entrega rápido cuando hay presupuesto. Se frena y estabiliza cuando no lo hay.
Consejo para responder: “Los presupuestos de error son el mecanismo. Si estamos dentro de nuestro SLO, entregamos features agresivamente. Si hemos consumido la mayoría de nuestro presupuesto de error, pausamos e invertimos en fiabilidad — mejores tests, monitoreo mejorado, correcciones arquitectónicas. Es una forma basada en datos de resolver el eterno debate ‘entregar vs estabilizar’.“
25. ¿Cómo evalúas si construir una herramienta internamente o usar una solución existente?
Lo que buscan: Criterio y conciencia de costos. Build vs buy no es solo cuestión de dinero — es carga de mantenimiento, costo de oportunidad y experiencia del equipo.
Consejo para responder: “Mi posición por defecto es usar soluciones existentes a menos que haya una razón fuerte para no hacerlo. El costo de mantenimiento del tooling interno casi siempre se subestima. Una vez construimos una herramienta de despliegue custom porque ‘ninguna herramienta existente se adapta a nuestro workflow.’ Dos años después, tres ingenieros dedicaban el 30% de su tiempo a mantenerla. Migramos a ArgoCD y recuperamos a esos ingenieros.”
Cómo Estructurar tus Respuestas
Un patrón que he visto funcionar en entrevistas DevOps, una y otra vez:
- Enuncia tu comprensión del concepto. Una o dos frases. No des una clase magistral.
- Da un ejemplo concreto de tu experiencia. Proyecto real, consecuencia real. “En mi empresa anterior, nosotros…” pesa más que “En teoría, deberías…”
- Menciona los trade-offs. Cada decisión DevOps tiene uno. Si tu respuesta no incluye un inconveniente o un “depende,” probablemente suena ensayada.
- Cierra con lo que recomendarías y por qué. Demuestra que sabes tomar una decisión, no solo listar opciones.
Los entrevistadores DevOps son operadores ellos mismos. Pueden detectar una respuesta guionizada desde el otro lado de la sala. La experiencia operativa — incluyendo los fracasos — es lo que separa a los candidatos que reciben ofertas de los que reciben rechazos corteses.
FAQ
¿Cuántas herramientas DevOps debo conocer para una entrevista?
La profundidad le gana a la amplitud. Conoce una herramienta de CI/CD a fondo (GitHub Actions o GitLab CI son las más comunes), un orquestador de contenedores (Kubernetes), una herramienta de IaC (Terraform) y un stack de monitoreo (Prometheus + Grafana o Datadog). Si manejas esas cuatro con confianza, puedes aprender las alternativas en días.
¿Las entrevistas DevOps incluyen desafíos de código?
A menudo, sí. Espera preguntas de scripting en Bash o Python — parsear logs, automatizar una tarea, escribir un health check simple. Algunas empresas también incluyen rondas de diseño de sistemas donde arquitecturas un pipeline de despliegue o un sistema de monitoreo. Es menos LeetCode y más resolución de problemas prácticos.
¿Debo certificarme antes de aplicar a roles DevOps?
Certificaciones como el AWS DevOps Professional o el CKA (Certified Kubernetes Administrator) ayudan a pasar los filtros de RRHH, especialmente en empresas grandes. Pero no van a sostener la entrevista por sí solas. He visto candidatos certificados incapaces de explicar cómo funciona terraform plan en la práctica. La certificación abre puertas. Las historias operativas son las que te hacen avanzar.
¿Cuál es la mayor señal de alerta en una respuesta de entrevista DevOps?
Decir “nosotros” para todo sin poder explicar tu contribución específica. Los entrevistadores van a preguntar “¿y cuál fue tu rol en eso?” Si no puedes responder con claridad, van a asumir que viste a alguien más hacer el trabajo.
¿Quieres el plan de preparación completo? Las preguntas DevOps son solo una parte. Para coding, diseño de sistemas, rondas de comportamiento y un plan de estudio semana a semana, lee cómo preparar una entrevista técnica en 2026.
¿Estudiando cloud junto con DevOps? Estas preguntas combinan bien con nuestras preguntas de entrevista cloud para AWS, Azure y GCP.
¿Listo para empezar? Accede al early access —>