¿Cómo diseñas un pipeline CI/CD desde cero para un nuevo proyecto?

Empiezo por entender qué necesita el equipo para entregar de forma segura y rápida, no por elegir herramientas. Mapeo las etapas por las que debe pasar el código: build, test, escaneo de seguridad, empaquetado, despliegue en staging y promoción a producción. Automatizo cada etapa y defino criterios de promoción claros para que nada avance sin cumplir los umbrales de calidad. Para un proyecto típico usaría GitHub Actions o GitLab CI para el pipeline, con builds en contenedores para mantener la consistencia de los entornos. Incluyo pruebas unitarias y de integración automatizadas al principio del pipeline para que los fallos aparezcan rápido y a bajo coste. También incorporo el escaneo de seguridad a nivel de imagen y dependencias en lugar de tratarlo como una preocupación post-despliegue. El objetivo es que cada commit en la rama principal sea desplegable. Trato el pipeline como código y lo versiono junto a la aplicación.

¿Cómo abordas la infraestructura como código y qué herramientas prefieres?

Trato la infraestructura como código como un principio fundamental, no como una optimización. Si la infraestructura no está en control de versiones, no puede revisarse, probarse ni reproducirse de forma fiable. Mi herramienta preferida para infraestructura cloud-agnóstica es Terraform por su sintaxis declarativa, ecosistema de proveedores y comunidad sólida. Para gestión de configuración uso Ansible cuando necesito gestionar el estado en máquinas existentes, y para Kubernetes uso Helm para el empaquetado y ArgoCD para la entrega estilo GitOps. Organizo Terraform en módulos por dominio para mantener la composabilidad y reutilización entre entornos. También impongo un flujo de trabajo plan antes de apply en CI para que los cambios de infraestructura se revisen como cambios de código.

¿Cómo piensas la monitorización y observabilidad de un sistema en producción?

Pienso la observabilidad en términos de los tres pilares: métricas, logs y trazas. Las métricas te dicen que algo va mal, los logs te dicen qué ocurrió, y las trazas te dicen dónde en un sistema distribuido se originó el problema. Mi enfoque estándar es instrumentar las aplicaciones con logs estructurados desde el principio, exportar métricas a una base de datos de series temporales como Prometheus y usar trazado distribuido con OpenTelemetry para entender los flujos de peticiones. Construyo dashboards que reflejan las cuatro señales doradas: latencia, tráfico, errores y saturación. También configuro alertas sobre síntomas que importan a los usuarios, no sobre umbrales de recursos de bajo nivel. El test que aplico a cualquier alerta es: si se dispara a las 3 de la madrugada, ¿vale la pena despertar a alguien?

Cuéntame sobre un incidente de producción importante que gestionaste. ¿Cuál fue tu papel y qué aprendiste?

Tuvimos un agotamiento del pool de conexiones a la base de datos que dejó fuera de servicio nuestro servicio principal durante 35 minutos un martes por la tarde. Estaba de guardia y asumí el mando del incidente. Mi primer paso fue declarar el incidente formalmente, abrir un canal de comunicación dedicado y alertar a los ingenieros relevantes sin inundar el canal de ruido. Mantuve separadas las comunicaciones internas y externas y di a nuestro director de ingeniería una actualización factual breve cada 10 minutos. La mitigación inmediata fue un reinicio y un aumento del límite del pool, que restauró el servicio en 12 minutos. La causa raíz era un job en segundo plano reciente con una liberación de conexión faltante en una condición de error. El cambio de proceso fue añadir una métrica del pool de conexiones a nuestro dashboard principal y una prueba de circuit breaker a nuestras pruebas de carga pre-producción.

Describe una situación en la que mejoraste la frecuencia de despliegue o redujiste el riesgo.

Cuando me incorporé a mi equipo anterior, los despliegues a producción ocurrían una vez a la semana los viernes por la tarde y requerían un runbook manual de 30 minutos ejecutado por dos ingenieros. Construí un pipeline completamente automatizado con pruebas de humo automatizadas, despliegue blue-green en nuestro cluster de Kubernetes y rollback automático si las pruebas fallaban. En dos meses estábamos desplegando varias veces al día sin pasos manuales y con un tiempo medio de recuperación de un despliegue fallido de menos de cuatro minutos. La frecuencia de despliegue es una de las métricas DORA, y mejorarla correlacionó directamente con una reducción en la tasa de fallos de cambios.

Dame un ejemplo de cómo has influido en la cultura de ingeniería en torno a las prácticas operativas.

Cuando me incorporé a una startup sin proceso de guardia, introduje una rotación de guardia ligera y una plantilla sencilla de respuesta a incidentes. Conduje un post-mortem sin culpas tras el primer incidente significativo bajo el nuevo proceso y reconocí explícitamente al ingeniero que había señalado honestamente un fallo de diseño. Durante el trimestre siguiente hice tres sesiones de aprendizaje interno sobre principios SRE, cada una de menos de 30 minutos, y publiqué una lista de comprobación de preparación operativa para nuevos servicios. Al final del año cada equipo tenía una rotación de guardia, los tiempos de respuesta a incidentes habían mejorado y los ingenieros hacían voluntariamente post-mortems sobre casi-incidentes.

¿Cómo gestionas los secretos y la configuración sensible en un entorno cloud-nativo?

Nunca almaceno secretos en variables de entorno codificadas en manifiestos de despliegue o código fuente, y nunca los hago commit en control de versiones. Mi enfoque preferido en un entorno Kubernetes es usar una herramienta de gestión de secretos como HashiCorp Vault o AWS Secrets Manager, con la aplicación recuperando los secretos en tiempo de ejecución a través de un sidecar o init container. Roto los secretos regularmente y automatizo la rotación donde el proveedor lo permite. Para pipelines CI/CD uso la gestión de secretos integrada en la plataforma. También sigo el principio de mínimo privilegio para todas las cuentas de servicio: cada servicio solo debe poder leer los secretos que necesita.

¿Cómo abordas la seguridad de contenedores y Kubernetes?

La seguridad de contenedores empieza a nivel de imagen. Uso imágenes base mínimas, escaneo imágenes en CI para vulnerabilidades conocidas con una herramienta como Trivy o Snyk, y aplico una política que bloquea el despliegue de imágenes por encima de un umbral de gravedad. En Kubernetes aplico políticas de red para restringir el tráfico entre pods, uso RBAC para limitar lo que pueden hacer las cuentas de servicio, y ejecuto pods como usuarios no-root con sistemas de archivos raíz de solo lectura donde sea posible. Uso admission controllers para aplicar políticas a nivel de cluster. Para los secretos uso un almacén dedicado en lugar de Kubernetes Secrets, que solo están en base64 a menos que configures el cifrado en reposo.

¿Cómo abordas la planificación de capacidad y la optimización de costes en un entorno cloud?

Empiezo por la visibilidad: no puedes optimizar lo que no puedes ver. Configuro dashboards de costes que desglosan el gasto por equipo, servicio y entorno para que las personas que toman decisiones arquitectónicas vean las implicaciones en tiempo real. Para el dimensionamiento, miro la utilización real de recursos durante una ventana de 30 días antes de hacer cambios. Uso autoescalado horizontal para cargas de trabajo sin estado y reservas o descuentos por uso comprometido para la carga de base predecible. También programo el apagado de entornos que no son producción fuera del horario laboral. Para el almacenamiento aplico políticas de ciclo de vida para mover automáticamente los datos poco consultados a niveles más económicos.

Ingeniero DevOps

Las entrevistas para ingeniero DevOps evalúan tu capacidad para conectar desarrollo y operaciones, automatizar infraestructura y construir sistemas fiables a escala. Los entrevistadores buscan experiencia práctica con pipelines CI/CD, plataformas cloud y gestión de incidentes, junto con una mentalidad orientada a la cultura que permita una entrega rápida y segura. Esta guía cubre las preguntas más frecuentes y las respuestas que consiguen ofertas.

Para consejos generales de preparación, consulta nuestra guía sobre las preguntas de entrevista más frecuentes.

Preguntas de entrevista habituales para Ingeniero DevOps

Preguntas conductuales para puestos de Ingeniero DevOps

Preguntas técnicas para candidatos a Ingeniero DevOps

Lo que buscan los reclutadores en las entrevistas para Ingeniero DevOps

Lo que los responsables de selección buscan realmente en los candidatos a ingeniero DevOps:

Experiencia real en producción. Las historias de guerra sobre incidentes, interrupciones y migraciones valen más que cualquier certificación.
Pensamiento sistémico. Los mejores ingenieros DevOps entienden cómo todo está conectado: código, infraestructura, monitorización, seguridad y costes interactúan.
Habilidades de comunicación. Los ingenieros DevOps están en la intersección de desarrollo y operaciones. La capacidad de traducir entre ambos es tan importante como la profundidad técnica.
Instintos de seguridad primero. Los candidatos que tratan la seguridad como un añadido en lugar de una base levantan señales de alarma en la mayoría de organizaciones maduras.
Contribución cultural. Pregúntate si esta persona ayudará al equipo a desplegar con más seguridad y a aprender de los fallos, no solo si conoce Terraform.

Preguntas que puedes hacer al entrevistador

→¿Cómo es la configuración CI/CD actual y cuáles son los mayores puntos de fricción en el proceso de despliegue?
→¿Cómo está estructurada la guardia y cuántos incidentes ha gestionado el equipo en los últimos tres meses?
→¿Cuál es el equilibrio entre construir nuevas herramientas y mantener la infraestructura existente?
→¿Cómo aborda el equipo los post-mortems y el aprendizaje a partir de incidentes?
→¿Con qué plataformas cloud y componentes de infraestructura principales trabajaría?

Practica estas preguntas antes de tu entrevista

El simulador de entrevista prepara una sesión de práctica basada en una oferta de empleo concreta y tu perfil, para que repases las preguntas con más probabilidad de aparecer.

Empezar a practicar

Gratis durante la beta. Sin compromiso.

Puestos relacionados

Ingeniero de software

Tech9 preguntas

Especialista en ciberseguridad

Tech9 preguntas

Data scientist

Tech9 preguntas