DevOps - Senior

Información del candidato

Nombre completo

Teléfono (opcional)

Años de experiencia

CV / Currículum Formatos aceptados: PDF, DOC, DOCX. Máximo 5MB

Preguntas de conocimiento

Esta policy IAM tiene un problema de seguridad: `{ "Effect": "Allow", "Action": "s3:*", "Resource": "*" }`. ¿Cuál es?

Wildcard `*` en Resource y Action otorga acceso total a TODOS los buckets S3. Viola el principio de least privilege. Solución: especificar ARNs exactos del bucket y solo las acciones necesarias (ej: `s3:GetObject` en `arn:aws:s3:::my-bucket/*`)

Falta el campo `Principal` en la policy, sin el cual IAM no puede determinar a quién se aplica el permiso y la policy es ignorada completamente

El problema es usar formato JSON en vez de YAML para definir policies IAM; AWS recomienda YAML por ser más legible y menos propenso a errores

Las policies IAM no soportan el uso de wildcards (`*`) en ningún campo; cada acción y recurso debe ser especificado individualmente sin excepciones

¿Cómo se estructura una estrategia multi-cuenta con AWS Organizations?

Una sola cuenta de AWS para todos los entornos y equipos es suficiente si se usan IAM policies granulares para separar el acceso

Landing Zone con OUs (Organizational Units): Security, Workloads (dev/staging/prod), Sandbox. SCPs para guardrails a nivel de OU. Cuenta de logging centralizada, cuenta de seguridad separada, y SSO para acceso federado

AWS Organizations es exclusivamente un servicio de facturación consolidada y no proporciona funcionalidades de seguridad ni governance

Se necesita crear una cuenta de AWS individual por cada desarrollador del equipo para garantizar el aislamiento completo de recursos

¿Cuándo usar ALB vs NLB vs API Gateway en AWS?

Son servicios completamente intercambiables que proporcionan exactamente la misma funcionalidad con diferente nombre comercial

API Gateway reemplaza completamente a ALB y NLB en todos los casos de uso y es siempre la opción más económica y eficiente

ALB: HTTP/HTTPS con routing por path/host/headers (microservicios web). NLB: TCP/UDP de ultra-baja latencia y millones de conexiones (gaming, IoT). API Gateway: REST/WebSocket APIs con auth, throttling, transformaciones y monetización

NLB es exclusivamente para bases de datos y no puede usarse para balancear tráfico de aplicaciones web o APIs REST

¿Cómo se usa Azure AD (Entra ID) para federar identidades en una organización?

Azure AD solo funciona con aplicaciones desarrolladas por Microsoft (Office 365, Teams) y no es compatible con aplicaciones de terceros o custom

Entra ID solo sirve para gestionar cuentas de correo electrónico corporativo y no tiene capacidades de autenticación ni autorización para aplicaciones

No es posible integrar Azure AD con AWS o GCP; cada cloud provider requiere su propio sistema de identidad completamente independiente

Entra ID actúa como Identity Provider (IdP) central: SSO con SAML/OIDC para apps cloud y on-premise, Conditional Access policies, MFA, integración con AWS/GCP via federation trust, y sincronización con AD on-premise via Azure AD Connect

¿Cuándo elegir BigQuery (GCP) vs Redshift (AWS) vs Athena (AWS) para analytics?

BigQuery: serverless, pago por query, ideal para análisis ad-hoc y ML integrado. Redshift: cluster dedicado, mejor para workloads predecibles y alto volumen constante. Athena: serverless sobre S3, ideal para queries ocasionales sin infraestructura dedicada

Son servicios exactamente iguales con diferente nombre en cada cloud provider; la elección es puramente por preferencia de proveedor

Athena es siempre más rápido que BigQuery en todos los escenarios porque opera directamente sobre S3 sin overhead de procesamiento adicional

Redshift es un servicio serverless como BigQuery y no requiere gestión de clusters ni configuración de nodos por parte del usuario

Esta imagen Docker tiene vulnerabilidades: `FROM node:14 ARG DB_PASSWORD RUN echo $DB_PASSWORD > /tmp/config COPY . /app RUN npm install`. ¿Cuáles son los problemas?

El único problema es que falta declarar `WORKDIR /app` antes del COPY para establecer el directorio de trabajo correctamente

Base image desactualizada (node:14 EOL con CVEs conocidos), secret en build args (queda en el historial de capas), secret escrito en filesystem de la imagen. Solución: imagen actualizada, multi-stage, secrets via runtime env vars o Docker secrets, no en build time

El problema es usar npm en vez de yarn como package manager; yarn es más seguro porque verifica checksums de todos los paquetes instalados

ARG es más seguro que ENV para manejar secrets en Docker porque los valores de ARG se eliminan automáticamente después del build

Un Pod está en CrashLoopBackOff. Los logs muestran `OOMKilled` y el liveness probe falla. ¿Qué está pasando?

El cluster no tiene suficientes nodos disponibles y el scheduler no puede encontrar un nodo con recursos libres para ejecutar el Pod

CrashLoopBackOff es siempre un error de red causado por problemas de DNS o conectividad entre el Pod y el Service que lo expone

El contenedor excede su memory limit (OOMKilled por el kernel) y se reinicia. El liveness probe falla durante el reinicio, causando el loop. Solución: aumentar `resources.limits.memory`, optimizar consumo de memoria, o revisar si el liveness probe es demasiado pesado

La única solución es eliminar el Pod manualmente con `kubectl delete pod` y esperar a que el Deployment lo recree con una configuración limpia

¿Cómo lograr zero-downtime deployments en Kubernetes?

Solo ejecutar `kubectl apply` con el nuevo manifiesto es suficiente para lograr zero-downtime sin configuración adicional de ningún tipo

Zero-downtime es técnicamente imposible en Kubernetes debido a la naturaleza efímera de los Pods y el tiempo de startup de los contenedores

Solo se necesita aumentar el número de réplicas del Deployment; con suficientes réplicas el downtime se vuelve imperceptible automáticamente

Rolling update con `maxSurge`/`maxUnavailable`, readiness probes (no recibir tráfico hasta estar listo), preStop hooks (graceful shutdown), PodDisruptionBudget (mínimo de pods disponibles), y connection draining en el Service/Ingress

¿Qué es un Service Mesh (Istio/Linkerd) y qué problemas resuelve?

Capa de infraestructura que gestiona comunicación service-to-service: mTLS automático (seguridad), circuit breaking y retries (resiliencia), observabilidad (métricas, traces), traffic management (canary, A/B) — todo sin modificar código de la aplicación

Es un tipo de red física especializada para data centers que requiere hardware dedicado y no puede implementarse en entornos cloud

Solo sirve para centralizar logging de aplicaciones distribuidas y no proporciona funcionalidades de seguridad ni gestión de tráfico

Reemplaza completamente a Kubernetes como orquestador de contenedores y no puede usarse junto con él en la misma infraestructura

Terraform plan muestra cambios inesperados en un recurso que no se modificó en el código. ¿Qué pasó?

Terraform tiene un bug conocido que causa cambios fantasma en el plan; se resuelve actualizando a la última versión del CLI

Drift: alguien modificó el recurso manualmente (consola/CLI) fuera de Terraform. El state no coincide con la realidad. Solución: `terraform refresh` para actualizar state, luego decidir si importar el cambio manual o revertirlo con `terraform apply`

Hay que borrar completamente el state file y recrearlo desde cero con `terraform import` de todos los recursos existentes

Los cambios inesperados en el plan son comportamiento normal de Terraform y pueden ignorarse sin riesgo al hacer apply

¿Cómo gestionar el state de Terraform en equipo?

Cada desarrollador debe mantener su propio state file local en su máquina y sincronizarlo manualmente con el equipo via chat o email

Commitear el state file al repositorio Git es suficiente para la colaboración en equipo; Git gestiona los conflictos automáticamente

Remote backend (S3 + DynamoDB para locking en AWS, o Terraform Cloud). Locking previene escrituras concurrentes. Workspaces o directorios separados para cada entorno. State encryption at rest y acceso controlado via IAM

No se necesita locking del state si el equipo es pequeño (menos de 10 personas); los conflictos son extremadamente raros en la práctica

¿Cómo estructurar módulos Terraform para multi-entorno (dev/staging/prod)?

Módulos reutilizables con variables para diferencias entre entornos. Estructura: `modules/` (lógica compartida) + `environments/dev|staging|prod/` (configuración específica con tfvars). Usar workspaces o directorios separados, con remote state por entorno

Copiar y pegar el código completo de Terraform para cada entorno en directorios separados sin compartir módulos ni configuración

Un solo archivo main.tf para todos los entornos con condicionales `if/else` para diferenciar la configuración de cada uno

Terraform no soporta múltiples entornos de forma nativa; se necesita una herramienta externa como Terragrunt obligatoriamente

Este playbook Ansible no es idempotente: `- name: Configure app shell: echo "DB_HOST=prod" >> /etc/app.conf`. ¿Por qué y cómo arreglarlo?

Ansible es siempre idempotente por diseño independientemente del módulo utilizado; el módulo `shell` garantiza que el comando solo se ejecute una vez

El problema es usar el comando `echo` en vez de `cat`; cambiando a `cat` el playbook se vuelve idempotente automáticamente

Solo hay que añadir `become: yes` para ejecutar como root; el problema de idempotencia se resuelve con permisos elevados

`shell` con `>>` añade la línea cada vez que se ejecuta (duplicados). Solución: usar módulo `lineinfile` con `line` y `regexp`, o `template` con un archivo Jinja2. Alternativa: añadir `creates:` o `when:` para condicionar la ejecución

¿Cómo implementar canary deployments con rollback automático basado en métricas?

Canary deployment es simplemente desplegar la nueva versión al 50% de los servidores simultáneamente sin monitoreo de métricas

Canary solo funciona como parte de una estrategia blue-green y no puede implementarse de forma independiente como patrón de deployment

Desplegar nueva versión a un % pequeño de tráfico (5-10%), monitorear métricas clave (error rate, latencia p99, saturación). Si métricas superan threshold → rollback automático. Herramientas: Flagger/Argo Rollouts en K8s, AWS CodeDeploy con CloudWatch alarms

No es posible implementar rollback automático basado en métricas; siempre se requiere intervención humana para decidir si revertir un deployment

¿Cómo integrar feature flags en un pipeline de despliegue?

Feature flags (LaunchDarkly, Unleash, Flagsmith) permiten separar deploy de release: desplegar código con features desactivadas, activar gradualmente por segmento de usuarios, rollback instantáneo sin redeploy. Integrar en CI/CD para activar flags post-deploy exitoso

Feature flags son simplemente variables de entorno estáticas que se configuran en el servidor y requieren redeploy para cambiar su valor

Feature flags reemplazan completamente al versionado de código con Git y hacen innecesario el uso de ramas y tags para gestionar releases

Solo funcionan con aplicaciones frontend (JavaScript/React) y no son aplicables a servicios backend o APIs debido a limitaciones técnicas

¿Cómo gestionar secrets de forma segura en infraestructura?

Definir variables de entorno directamente en el código fuente es suficiente si el repositorio es privado y tiene acceso restringido al equipo

Encriptar el archivo `.env` con GPG y commitearlo al repositorio es una práctica segura aceptada por los estándares de la industria

HashiCorp Vault (dynamic secrets, rotation), AWS Secrets Manager/Parameter Store (integración nativa), Sealed Secrets en K8s (encriptados en repo, desencriptados en cluster). Principios: rotación automática, audit logging, least privilege, nunca en código/repos

Los secrets no necesitan rotación periódica si son suficientemente largos y complejos; la rotación solo introduce riesgo de downtime innecesario

Esta NetworkPolicy de Kubernetes tiene un problema: `apiVersion: networking.k8s.io/v1 kind: NetworkPolicy spec: podSelector: {} policyTypes: ["Ingress"] ingress: - from: - podSelector: matchLabels: app: frontend`. ¿Qué falta?

La policy está completamente correcta y no tiene ningún problema de seguridad; restringe adecuadamente todo el tráfico no autorizado

Solo restringe ingress pero no egress — los pods pueden comunicarse con cualquier destino externo (exfiltración de datos posible). Falta `policyTypes: ["Ingress", "Egress"]` con reglas de egress explícitas limitando destinos permitidos

Falta especificar el namespace en el podSelector; sin namespace la policy no se aplica a ningún pod del cluster

`podSelector: {}` es sintaxis inválida en NetworkPolicy y debería especificar al menos un label para seleccionar los pods afectados

¿Cuál es la diferencia entre logs, métricas y traces, y cómo se correlacionan con OpenTelemetry?

Son tres formas diferentes de hacer exactamente lo mismo; elegir una es suficiente para tener observabilidad completa del sistema

OpenTelemetry es exclusivamente una herramienta de tracing distribuido y no tiene capacidad de gestionar logs ni métricas

Las métricas reemplazan completamente a los logs en sistemas modernos; mantener logs es una práctica legacy que añade overhead innecesario

Logs: eventos discretos con contexto (qué pasó). Métricas: valores numéricos agregables en el tiempo (cómo está el sistema). Traces: seguimiento de una request a través de servicios (dónde está el problema). OpenTelemetry unifica con trace_id/span_id compartido entre los tres

¿Cómo implementar auto-scaling con métricas custom en Kubernetes?

HPA (Horizontal Pod Autoscaler) con métricas custom via Prometheus Adapter o KEDA (Kubernetes Event-Driven Autoscaling). KEDA escala basado en eventos externos (queue length, HTTP requests, cron). Configurar: metric server → HPA/KEDA → scale target con cooldown periods

Solo HPA con métricas de CPU y memoria es suficiente para cualquier caso de uso; las métricas custom no proporcionan beneficio adicional

Kubernetes no soporta métricas custom para auto-scaling; solo puede escalar basándose en CPU y memoria del contenedor

Auto-scaling con métricas custom solo funciona en clusters cloud gestionados (EKS, GKE, AKS) y no es posible en clusters on-premise

¿Cómo automatizar la respuesta a incidentes usando webhooks y herramientas como n8n?

La respuesta a incidentes siempre debe ser completamente manual porque la automatización introduce riesgos de acciones incorrectas sin supervisión humana

Alertas (Prometheus/CloudWatch) → webhook a n8n/PagerDuty → workflow automático: crear ticket, notificar Slack con contexto, escalar si no hay ACK en X minutos, ejecutar runbooks automáticos (restart pod, scale up), y documentar timeline del incidente

n8n es exclusivamente una herramienta de marketing automation y no tiene capacidades para gestionar incidentes de infraestructura o aplicaciones

Los webhooks no son suficientemente confiables para gestionar incidentes críticos porque pueden perderse mensajes sin garantía de entrega

Desafío de código

Diseña e implementa infraestructura completa con Terraform: VPC con subnets públicas/privadas, cluster EKS o ECS con auto-scaling, RDS con réplica de lectura, y pipeline CI/CD con estrategia canary. Incluye diagrama de arquitectura y documentación de decisiones.

Requisitos

Terraform modular: VPC (public/private subnets, NAT), EKS/ECS con auto-scaling policies
RDS PostgreSQL con réplica de lectura en otra AZ y backups automáticos
Pipeline CI/CD con canary deployment y rollback automático basado en métricas
Diagrama de arquitectura (draw.io, Mermaid, o similar)
Documentación de decisiones técnicas (ADRs) y estimación de costes

Ejemplos

Entrada: terraform apply -var-file=environments/prod.tfvars

Salida:

Infraestructura completa desplegada: VPC con 3 AZs, EKS cluster con 2-10 nodos auto-scaling, RDS multi-AZ, ALB con WAF, y pipeline funcional

Tecnologías aceptadas

Terraform
AWS (EKS/ECS, RDS, VPC)
GitHub Actions / GitLab CI
Helm charts para K8s
Prometheus + Grafana para observabilidad

Envío de solución

URL del repositorio * Plataformas soportadas: GitHub, GitLab, Bitbucket Introduce una URL válida de repositorio (https://github.com, gitlab.com o bitbucket.org seguido de usuario/repositorio)