Preguntas de entrevista para ingeniero DevOps senior en producción

Milad Bonakdar
Autor
Prepárate con preguntas prácticas sobre Kubernetes, estado de Terraform, GitOps, seguridad, observabilidad, respuesta a incidentes y decisiones de producción.
En qué se centra una entrevista DevOps senior
Una entrevista DevOps senior suele medir si sabes operar sistemas en producción, no solo si conoces herramientas. Espera preguntas por escenarios sobre fallos en Kubernetes, seguridad del estado de Terraform, despliegues GitOps, resiliencia en la nube, controles de seguridad, observabilidad e incidentes.
Usa esta guía para practicar respuestas con criterio: qué revisarías primero, qué riesgo reducirías, cómo validarías la solución y cómo explicarías el compromiso técnico a ingeniería, seguridad o producto.
Kubernetes Avanzado
1. Explique la arquitectura de Kubernetes y el rol de los componentes clave.
Respuesta: Kubernetes usa una arquitectura de plano de control y nodos de trabajo. Una buena respuesta senior explica los componentes y cómo el estado deseado avanza por el sistema:
Componentes del Plano de Control:
- API Server: Frontend para el plano de control de Kubernetes, gestiona todas las peticiones REST
- etcd: Almacén de clave-valor distribuido para el estado del clúster
- Scheduler: Asigna pods a nodos basándose en los requisitos de recursos
- Controller Manager: Ejecuta procesos de controlador (replicación, endpoints, etc.)
- Cloud Controller Manager: Se integra con las APIs del proveedor de la nube
Componentes del Nodo:
- kubelet: Agente que asegura que los contenedores se están ejecutando en pods
- kube-proxy: Mantiene las reglas de red para la comunicación del pod
- Container Runtime: Ejecuta contenedores (Docker, containerd, CRI-O)
Cómo funciona:
- El usuario envía la implementación a través de kubectl
- API Server valida y almacena en etcd
- Scheduler asigna pods a nodos
- kubelet en el nodo crea contenedores
- kube-proxy configura la red
Frecuencia: Muy Común Dificultad: Difícil
2. ¿Cómo se soluciona un pod atascado en CrashLoopBackOff?
Respuesta: Enfoque de depuración sistemático:
Causas comunes:
- La aplicación falla al inicio
- Faltan variables de entorno
- Configuración incorrecta de la sonda de liveness
- Recursos insuficientes (OOMKilled)
- Errores de extracción de imágenes
- Faltan dependencias
Ejemplo de corrección:
Frecuencia: Muy Común Dificultad: Media
3. Explique la red de Kubernetes: Services, Ingress y Network Policies.
Respuesta: Capas de red de Kubernetes:
Services: Tipos de exposición de servicios:
Ingress: Enrutamiento HTTP/HTTPS:
Network Policies: Controlar la comunicación pod-a-pod:
Frecuencia: Muy Común Dificultad: Difícil
4. ¿Cómo implementa el autoescalado en Kubernetes?
Respuesta: Múltiples estrategias de autoescalado:
Horizontal Pod Autoscaler (HPA):
Vertical Pod Autoscaler (VPA):
Cluster Autoscaler: Ajusta automáticamente el tamaño del clúster basándose en los pods pendientes:
Frecuencia: Común Dificultad: Media
Terraform Avanzado
5. Explique la gestión del estado de Terraform y las mejores prácticas.
Respuesta: El estado de Terraform rastrea la infraestructura y es fundamental para las operaciones.
Configuración del Estado Remoto:
Bloqueo de Estado:
Mejores Prácticas:
1. Nunca subas archivos de estado a Git
2. Usa workspaces para entornos
3. Importa recursos existentes
4. Manipulación del estado (usar con cuidado)
5. Hacer una copia de seguridad del estado antes de grandes cambios
Frecuencia: Muy Común Dificultad: Difícil
6. ¿Cómo estructura el código de Terraform para grandes proyectos?
Respuesta: Estructura modular para la mantenibilidad:
Estructura de Directorios:
Ejemplo de Módulo:
Usando Módulos:
Frecuencia: Común Dificultad: Difícil
Arquitectura en la Nube
7. Diseñe una arquitectura multi-región de alta disponibilidad en AWS.
Respuesta: Arquitectura multi-región para alta disponibilidad:
Componentes Clave:
1. DNS y Gestión del Tráfico:
2. Replicación de la Base de Datos:
3. Replicación de Datos:
Principios de Diseño:
- Configuración activa-activa o activa-pasiva
- Failover automatizado con comprobaciones de salud
- Replicación de datos con mínimo retardo
- Implementación consistente entre regiones
- Monitorización y alertas para ambas regiones
Frecuencia: Común Dificultad: Difícil
GitOps & CI/CD
8. Explique GitOps y cómo implementarlo con ArgoCD.
Respuesta: GitOps utiliza Git como la única fuente de verdad para la infraestructura y las aplicaciones declarativas.
Principios:
- Configuración declarativa en Git
- Sincronización automatizada
- Control de versiones para todos los cambios
- Reconciliación continua
Implementación de ArgoCD:
Estructura de Directorios:
Kustomization:
Beneficios:
- Git como registro de auditoría
- Rollbacks fáciles (git revert)
- Estado deseado declarativo
- Detección automatizada de la desviación
- Gestión multi-clúster
Frecuencia: Común Dificultad: Media
Seguridad & Cumplimiento
9. ¿Cómo implementa las mejores prácticas de seguridad en Kubernetes?
Respuesta: Enfoque de seguridad multi-capa:
1. Pod Security Standards:
2. RBAC (Control de Acceso Basado en Roles):
3. Network Policies:
4. Gestión de Secretos:
5. Security Context:
6. Image Scanning:
Frecuencia: Muy Común Dificultad: Difícil
Observabilidad & SRE
10. Diseñe una pila de observabilidad integral.
Respuesta: Tres pilares de la observabilidad: Métricas, Logs, Trazas
Arquitectura:
1. Métricas (Prometheus + Grafana):
2. Logging (Loki):
3. Tracing (Jaeger):
4. Reglas de Alerta:
5. Monitorización de SLO:
Frecuencia: Común Dificultad: Difícil
Disaster Recovery
11. ¿Cómo implementa la recuperación ante desastres para un clúster de Kubernetes?
Respuesta: Estrategia integral de DR:
1. Estrategia de Backup:
2. Backup de etcd:
3. Procedimiento de Restauración:
4. Failover Multi-Región:
5. Objetivos RTO/RPO:
- RTO (Recovery Time Objective): < 1 hora
- RPO (Recovery Point Objective): < 15 minutos
- Simulacros de DR regulares (mensuales)
- Runbooks documentados
- Failover automatizado donde sea posible
Frecuencia: Común Dificultad: Difícil
Service Mesh
12. Explique la arquitectura de service mesh y cuándo usarla.
Respuesta: Un service mesh proporciona una capa de infraestructura para la comunicación servicio-a-servicio.
Componentes Centrales:
Implementación de Istio:
Cuándo usarlo:
- Comunicación compleja entre microservicios
- mTLS, autorización y reglas de tráfico consistentes
- Canary releases, división de tráfico y aislamiento de fallos
- Observabilidad común para llamadas entre servicios
Qué vigilar: Un service mesh añade complejidad, latencia y carga operativa. En una entrevista senior, explica por qué el beneficio compensa esos costes en ese sistema.
Conclusión
No prepares solo definiciones de herramientas. En cada respuesta, muestra cómo aislarías un problema de producción, priorizarías riesgos, validarías la corrección y convertirías lo aprendido en una mejora duradera.


