Preguntas de entrevista DevOps — Docker, Kubernetes, AWS (40+)

Preguntas de entrevista DevOps — Docker, Kubernetes y AWS (40+)

Si tenés una entrevista de DevOps Engineer en el radar — ya sea en una startup LATAM, una empresa remota que paga en dólares o una consultora global — este artículo es tu hoja de ruta.

Acá no hay respuestas genéricas. Cada pregunta viene con la respuesta que espera un entrevistador senior, el razonamiento detrás y, donde aplica, código real que podés copiar y adaptar.

Las preguntas están organizadas por tecnología: Docker, Kubernetes, AWS, CI/CD e Infraestructura como Código. Cubrí todos los niveles — desde conceptos fundamentales que siempre caen hasta preguntas de diseño de sistemas que separan a los mid de los seniors.

Docker (Preguntas 1–12)

1. ¿Cuál es la diferencia entre una imagen y un contenedor Docker?

Una imagen es una plantilla de solo lectura — el snapshot del sistema de archivos con el código, las dependencias y la configuración. Un contenedor es una instancia en ejecución de esa imagen: tiene su propio proceso, red y sistema de archivos efímero.

Analogía útil: la imagen es la clase en POO; el contenedor es el objeto instanciado. Podés tener decenas de contenedores corriendo desde la misma imagen.

2. ¿Qué es un Dockerfile y cuáles son las instrucciones más importantes?

Un Dockerfile es el script declarativo que define cómo construir una imagen. Las instrucciones clave:

# Base image — elegí siempre la variante más liviana posible
FROM node:20-alpine

# Directorio de trabajo dentro del contenedor
WORKDIR /app

# Copiá primero solo los archivos de dependencias (aprovecha el cache de layers)
COPY package*.json ./
RUN npm ci --only=production

# Después copiá el resto del código
COPY . .

# Puerto que expone el contenedor (documentativo, no lo publica)
EXPOSE 3000

# Comando por defecto al arrancar el contenedor
CMD ["node", "server.js"]

El orden importa porque Docker cachea por layer. Si ponés COPY . . antes del npm ci, cualquier cambio en el código invalida el cache de dependencias.

3. ¿Qué es un multi-stage build y cuándo lo usarías?

Un multi-stage build usa múltiples bloques FROM en el mismo Dockerfile para separar el entorno de compilación del artefacto final de producción:

# Stage 1: compilación
FROM golang:1.22 AS builder
WORKDIR /src
COPY . .
RUN go build -o /app/server .

# Stage 2: imagen final (solo el binario, sin el SDK de Go)
FROM alpine:3.19
COPY --from=builder /app/server /app/server
CMD ["/app/server"]

Resultado: una imagen de 8 MB en lugar de 800 MB. Usalo siempre que tengas lenguajes compilados (Go, Java, Rust, C#) o builds de frontend.

4. ¿Cómo funciona el sistema de layers en Docker?

Cada instrucción RUN, COPY o ADD crea una nueva layer de solo lectura. Las layers se apilan y cada una registra el diff respecto a la anterior. Cuando construís la imagen, Docker compara el hash de cada instrucción — si coincide con el cache, reutiliza la layer existente en lugar de reconstruirla.

En producción esto significa que si solo cambiaste el código de la app (no las dependencias), solo se reconstruye la layer de COPY . . y la imagen se pushea mucho más rápido al registry.

5. ¿Cuál es la diferencia entre CMD y ENTRYPOINT?

• ENTRYPOINT define el ejecutable principal del contenedor. Es difícil de sobreescribir (necesitás --entrypoint).
• CMD proporciona los argumentos por defecto. Se puede sobreescribir fácilmente en docker run.

# Patrón recomendado: ENTRYPOINT fijo + CMD overrideable
ENTRYPOINT ["python", "app.py"]
CMD ["--env", "production"]  # override: docker run myimage --env staging

6. ¿Cómo manejarías variables de entorno sensibles en Docker?

Nunca en el Dockerfile (quedan en el historial de la imagen). Las opciones correctas:

# En desarrollo: archivo .env (no commitear)
docker run --env-file .env myapp

# En producción: usar Docker Secrets (Swarm) o inyectar desde el orquestador
docker run -e DB_PASSWORD="$(aws secretsmanager get-secret-value ...)" myapp

# O directamente desde el orchestrator (Kubernetes Secrets, AWS Secrets Manager)

7. ¿Qué es Docker Compose y cuándo lo usás?

Docker Compose define y corre aplicaciones multi-contenedor con un archivo YAML. Es la herramienta estándar para desarrollo local y entornos de staging simples:

services:
  api:
    build: .
    ports:
      - "3000:3000"
    environment:
      - DATABASE_URL=postgres://postgres:secret@db:5432/mydb
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: secret
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      retries: 5
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:

8. ¿Cómo debuggeás un contenedor que falla al arrancar?

# Ver logs del contenedor (incluso si ya murió)
docker logs <container_id> --tail 100

# Inspeccionar el estado y configuración
docker inspect <container_id>

# Entrar al contenedor con una shell (si el proceso sigue corriendo)
docker exec -it <container_id> sh

# Si el contenedor muere inmediatamente, sobreescribí el entrypoint
docker run -it --entrypoint sh myimage

# Ver el exit code
docker inspect <container_id> --format "{{.State.ExitCode}}"

9. ¿Qué son los volúmenes de Docker y cuándo usarlos vs. bind mounts?

• Volúmenes (docker volume create): gestionados por Docker, portables, ideales para datos de producción (bases de datos, uploads).
• Bind mounts (-v /host/path:/container/path): sincronizan un directorio del host. Útil en desarrollo para hot-reload.

Regla: en producción siempre volúmenes; en desarrollo local bind mounts para el código.

10. ¿Cómo reducirías el tamaño de una imagen Docker?

Checklist:

1. 1Partí de una base alpine o distroless en lugar de ubuntu.
2. 2Usá multi-stage builds — el stage final solo contiene el artefacto.
3. 3Combiná comandos RUN con && para reducir layers.
4. 4Limpiá el cache del gestor de paquetes en el mismo RUN: apt-get install -y curl && rm -rf /var/lib/apt/lists/*.
5. 5Usá .dockerignore para no copiar node_modules, .git, tests.

11. ¿Qué es Docker BuildKit y por qué importa?

BuildKit es el backend de construcción moderno de Docker. Habilita builds en paralelo, mejor uso del cache (incluyendo cache remoto), --secret para secretos que no quedan en layers y --ssh para clonar repos privados durante el build. Es el default en Docker 23+.

# Ejemplo: mount de secreto que no queda en la imagen
RUN --mount=type=secret,id=npm_token \
    NPM_TOKEN=$(cat /run/secrets/npm_token) npm ci

12. ¿Cuál es la diferencia entre COPY y ADD en un Dockerfile?

COPY simplemente copia archivos o directorios. ADD hace lo mismo pero además puede extraer tarballs (.tar.gz) automáticamente y descargar desde URLs. La recomendación es siempre usar COPY — es explícito y predecible. Usá ADD solo si necesitás extraer un tarball local.

Kubernetes (Preguntas 13–28)

13. Explicá la arquitectura de Kubernetes: control plane vs. worker nodes.

Control Plane (el cerebro):

• API Server: punto de entrada de todas las operaciones; expone la API REST.
• etcd: base de datos distribuida que almacena el estado del cluster.
• Scheduler: asigna Pods a nodos según recursos disponibles y restricciones.
• Controller Manager: bucles de reconciliación que mantienen el estado deseado (ReplicaSet, Deployment, etc.).

Worker Nodes (los músculos):

• kubelet: agente en cada nodo; recibe instrucciones del control plane y gestiona los Pods.
• kube-proxy: reglas de red para enrutar tráfico entre Pods y Services.
• Container Runtime (containerd, CRI-O): ejecuta los contenedores.

14. ¿Qué es un Pod y cuál es su relación con los contenedores?

Un Pod es la unidad mínima desplegable en Kubernetes. Puede contener uno o más contenedores que comparten la misma red (misma IP) y volúmenes. En la práctica, el patrón más común es un contenedor por Pod. Los contenedores adicionales se usan para el patrón sidecar (logging, proxy, init tasks).

15. ¿Cuál es la diferencia entre Deployment, ReplicaSet, StatefulSet y DaemonSet?

| Recurso | Cuándo usarlo |

|---|---|

| Deployment | Apps stateless (APIs, frontends). Gestiona rolling updates y rollbacks. |

| ReplicaSet | Raramente directo; Deployment lo gestiona internamente. |

| StatefulSet | Apps con estado: bases de datos, colas. Garantiza identidad estable (nombre, red, storage) por Pod. |

| DaemonSet | Un Pod por cada nodo del cluster: agentes de logging, monitoring (Fluentd, Datadog Agent). |

16. ¿Cómo funciona un rolling update en Kubernetes?

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # pods extra durante el update
      maxUnavailable: 0  # ningún pod fuera de servicio en ningún momento

Kubernetes crea un nuevo Pod con la versión nueva, espera que pase los health checks, y solo entonces termina uno viejo. Con maxUnavailable: 0 garantizás zero-downtime. Si el nuevo Pod no levanta, el rollout se detiene automáticamente y podés hacer kubectl rollout undo deployment/myapp.

17. Explicá qué es un Service y los tipos principales.

Un Service expone un conjunto de Pods bajo una IP y DNS estables (independientes del ciclo de vida de los Pods):

• ClusterIP (default): accesible solo dentro del cluster. Ideal para comunicación interna entre microservicios.
• NodePort: expone un puerto en cada nodo del cluster. Útil para desarrollo y testing.
• LoadBalancer: provisiona un load balancer externo en el cloud provider. El estándar para producción en EKS/GKE/AKS.
• ExternalName: mapea el Service a un CNAME. Útil para integrar servicios externos (RDS, etc.).

18. ¿Qué es un Ingress y cuándo lo usarías en lugar de un LoadBalancer?

Un Ingress es un recurso de L7 (HTTP/HTTPS) que permite enrutar tráfico a múltiples Services según el host o el path, con un solo LoadBalancer externo:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: api.miapp.com
    http:
      paths:
      - path: /users
        pathType: Prefix
        backend:
          service:
            name: users-service
            port:
              number: 80
      - path: /orders
        pathType: Prefix
        backend:
          service:
            name: orders-service
            port:
              number: 80

Usás LoadBalancer cuando necesitás TCP/UDP o una IP fija por servicio. Usás Ingress cuando manejás múltiples microservicios HTTP — ahorrás costos (un solo LB) y centralizás TLS.

19. ¿Cómo configurarías los recursos de CPU y memoria en un Pod?

resources:
  requests:
    memory: "128Mi"  # mínimo garantizado (el scheduler lo usa para ubicar el Pod)
    cpu: "100m"      # 0.1 cores
  limits:
    memory: "256Mi"  # si supera esto, el contenedor es killed (OOMKilled)
    cpu: "500m"      # si supera esto, el proceso es throttled (no killed)

Regla práctica: los requests deberían reflejar el consumo en steady state; los limits de memoria deberían ser 2x los requests. Nunca pongas limits de CPU muy bajos — el throttling de CPU es silencioso y genera latencia inesperada.

20. ¿Qué son los readinessProbe y livenessProbe?

• livenessProbe: determina si el contenedor está vivo. Si falla, Kubernetes lo reinicia.
• readinessProbe: determina si el contenedor está listo para recibir tráfico. Si falla, el Pod se saca del Service (sin reiniciarlo).

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 15
  periodSeconds: 10
  failureThreshold: 3

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5

Error clásico: no configurar readinessProbe y que el tráfico llegue a un Pod que aún está inicializando la base de datos.

21. ¿Cómo funciona el scheduling en Kubernetes? ¿Qué son taints, tolerations y affinity?

El Scheduler elige el nodo óptimo para un Pod basándose en recursos disponibles, restricciones y políticas:

• Taints: marcan un nodo para repeler Pods (ej.: key=gpu:NoSchedule).
• Tolerations: permiten que un Pod acepte un taint específico.
• NodeAffinity: reglas para preferir o requerir nodos con ciertos labels.
• PodAntiAffinity: distribuye Pods del mismo Deployment en distintos nodos para alta disponibilidad.

# Distribuir réplicas en distintos nodos
affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 100
      podAffinityTerm:
        labelSelector:
          matchLabels:
            app: myapp
        topologyKey: kubernetes.io/hostname

22. ¿Cómo manejarías secretos en Kubernetes?

Kubernetes Secrets en base64 NO son encriptados por defecto (solo ofuscados). Las opciones seguras en producción:

1. 1Encriptación en reposo (EncryptionConfiguration en el API Server) — básico en EKS con KMS.
2. 2External Secrets Operator: sincroniza secretos desde AWS Secrets Manager, HashiCorp Vault, etc., al cluster. Es el estándar actual.
3. 3Sealed Secrets: encripta los secretos para poder commitearlos en git (GitOps).

Nunca commitees un Secret de Kubernetes en git sin encriptar.

23. ¿Qué es un HorizontalPodAutoscaler (HPA)?

El HPA escala automáticamente el número de réplicas de un Deployment basándose en métricas:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70  # escala cuando CPU promedio > 70%

El HPA requiere que el Metrics Server esté instalado en el cluster. Para escalado por métricas de negocio (requests por segundo, largo de cola SQS), usás KEDA.

24. ¿Cómo debuggeás un Pod que está en CrashLoopBackOff?

# 1. Ver el error inmediato
kubectl describe pod <pod-name>  # Events al final, muy informativos

# 2. Ver los logs de la corrida anterior (antes del crash)
kubectl logs <pod-name> --previous

# 3. Ver logs en tiempo real
kubectl logs <pod-name> -f

# 4. Entrar al pod si sigue corriendo brevemente
kubectl exec -it <pod-name> -- /bin/sh

# 5. Comprobar si es un problema de config/secrets
kubectl get events --sort-by=.metadata.creationTimestamp

Causas comunes: variable de entorno faltante, secret no montado, puerto ya en uso, OOMKilled (límite de memoria muy bajo), liveness probe muy agresivo.

25. ¿Qué es un Namespace y para qué sirve?

Los Namespaces son clusters virtuales dentro del mismo cluster físico. Separan recursos por equipo, ambiente (dev/staging/prod) o producto. Permiten aplicar ResourceQuotas (máximo de CPU/memoria por namespace) y NetworkPolicies para aislar la red.

En empresas pequeñas: un namespace por ambiente. En empresas grandes: un cluster por ambiente.

26. ¿Qué es un ConfigMap y cuándo lo preferís sobre variables de entorno directas?

Un ConfigMap almacena datos de configuración no sensibles como pares clave-valor o archivos completos. Lo usás cuando la config es grande, compartida entre Pods o necesitás actualizarla sin reconstruir la imagen:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  DATABASE_HOST: "db.production.svc.cluster.local"
  FEATURE_FLAGS: |
    enable_new_ui=true
    max_upload_size=50mb

27. ¿Qué es un PersistentVolume (PV) y un PersistentVolumeClaim (PVC)?

Separan el aprovisionamiento del storage de su uso:

• PV: recurso de storage provisionado por el admin (o dinámicamente por un StorageClass). Es independiente del ciclo de vida del Pod.
• PVC: solicitud de storage por parte de una app. Kubernetes busca un PV compatible y lo vincula.

En AWS, un PVC con storageClassName: gp3 provisiona automáticamente un EBS volume.

28. ¿Qué es Helm y por qué se usa?

Helm es el gestor de paquetes de Kubernetes. Un chart es una colección de templates YAML parametrizables con values.yaml. Permite:

# Instalar Nginx Ingress Controller
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm install ingress-nginx ingress-nginx/ingress-nginx \
  --set controller.replicaCount=2

# Deploy de tu propia app con valores por ambiente
helm upgrade --install myapp ./chart \
  --values ./chart/values-production.yaml \
  --set image.tag=v1.2.3

Sin Helm, tendrías docenas de archivos YAML con los mismos valores repetidos para cada ambiente.

AWS para DevOps (Preguntas 29–42)

29. ¿Cuál es la diferencia entre EC2, ECS y EKS? ¿Cuándo usás cada uno?

| Servicio | Cuándo usarlo |

|---|---|

| EC2 | Control total del SO, cargas específicas (bases de datos, HPC), VMs tradicionales. Más operación. |

| ECS (Elastic Container Service) | Containers en AWS sin querer gestionar Kubernetes. Más simple, integrado nativo con ALB, IAM, CloudWatch. |

| EKS (Elastic Kubernetes Service) | Necesitás Kubernetes real — portabilidad, ecosistema K8s, multi-cloud. Más complejo pero el estándar enterprise. |

Para startups que recién adoptan containers: ECS Fargate elimina la gestión de nodos. Para equipos con experiencia en K8s: EKS.

30. Explicá cómo funciona IAM: users, roles, policies y el principio de mínimo privilegio.

• Users: identidades para personas o sistemas que necesitan credenciales de largo plazo.
• Roles: identidades temporales asumidas por servicios AWS (EC2, Lambda, ECS task) o usuarios federated. Sin credenciales de largo plazo — las mejores prácticas de seguridad prefieren roles.
• Policies: documentos JSON que definen permisos. Se adjuntan a users, groups o roles.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "s3:GetObject",
      "s3:PutObject"
    ],
    "Resource": "arn:aws:s3:::mi-bucket-produccion/*"
  }]
}

Mínimo privilegio: otorgá solo los permisos necesarios para la tarea específica. Nunca *:* en producción.

31. ¿Cómo funciona VPC? Explicá subnets públicas, privadas, NAT Gateway e Internet Gateway.

Una VPC (Virtual Private Cloud) es tu red aislada en AWS:

• Internet Gateway: conecta la VPC a internet (entrada y salida).
• Subnet pública: tiene una ruta al Internet Gateway. Los recursos aquí son accesibles desde internet (load balancers, bastion hosts).
• Subnet privada: sin ruta directa a internet. Acá van las instancias de backend, bases de datos.
• NAT Gateway: en subnet pública; permite que instancias en subnets privadas inicien conexiones salientes a internet (para descargar actualizaciones) sin ser accesibles desde fuera.

Arquitectura típica de 3 capas: ALB en subnet pública → EC2/ECS en subnet privada → RDS en subnet privada (sin NAT, solo tráfico interno).

32. ¿Qué es un Application Load Balancer (ALB) y cómo lo configurarías para un microservicio?

El ALB es un load balancer de Layer 7 que enruta por path, header o host a distintos Target Groups:

# Target Group para el servicio de usuarios
aws elbv2 create-target-group \
  --name users-tg \
  --protocol HTTP \
  --port 8080 \
  --vpc-id vpc-xxx \
  --health-check-path /health

# Listener rule: /api/users/* → users-tg
aws elbv2 create-rule \
  --listener-arn arn:aws:elasticloadbalancing:... \
  --conditions Field=path-pattern,Values="/api/users/*" \
  --actions Type=forward,TargetGroupArn=arn:...

En ECS/EKS, el AWS Load Balancer Controller crea esto automáticamente al aplicar un Ingress o Service de tipo LoadBalancer.

33. ¿Cómo funciona S3? ¿Qué son las storage classes?

S3 es almacenamiento de objetos con durabilidad 99.999999999% (11 nueves). Las storage classes principales:

| Clase | Cuándo usarla | Costo |

|---|---|---|

| Standard | Datos accedidos frecuentemente | Alto |

| Standard-IA | Acceso infrecuente, recuperación rápida | Medio |

| Glacier Instant Retrieval | Archivos con acceso ocasional, milisegundos | Bajo |

| Glacier Deep Archive | Backups a largo plazo, horas de recuperación | Muy bajo |

Usá S3 Lifecycle Policies para mover objetos automáticamente entre clases según antigüedad.

34. ¿Qué es CloudFormation y cómo se compara con Terraform?

• CloudFormation: IaC nativo de AWS. YAML/JSON. Integración perfecta con todos los servicios AWS. Stacks con rollback automático.
• Terraform: IaC multi-cloud (HCL). Más popular, mejor DX, state management explícito, providers para AWS, GCP, Azure, Datadog, etc.

En la práctica: si tu infra es 100% AWS y el equipo ya lo conoce, CloudFormation está bien. Para cualquier otra situación o equipo nuevo, Terraform es el estándar de la industria.

35. ¿Qué es AWS RDS y cómo garantizarías alta disponibilidad?

RDS es el servicio de bases de datos relacionales gestionadas (PostgreSQL, MySQL, Aurora, etc.).

Para alta disponibilidad:

• Multi-AZ: RDS mantiene una réplica sincrónica en otra zona de disponibilidad. En caso de fallo, el failover es automático (~30-60s) y transparente para la app (mismo endpoint).
• Read Replicas: réplicas asincrónicas para escalar lecturas (reportes, analytics).
• Aurora: storage distribuido por diseño, más rápido en failover (~10s), hasta 15 read replicas.

36. ¿Cómo funciona Auto Scaling en EC2?

Auto Scaling Groups (ASG) mantienen el número deseado de instancias y escalan automáticamente:

aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name mi-asg \
  --launch-template LaunchTemplateName=mi-template \
  --min-size 2 \
  --max-size 10 \
  --desired-capacity 2 \
  --vpc-zone-identifier "subnet-xxx,subnet-yyy"

# Política de scaling basada en CPU
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name mi-asg \
  --policy-name scale-on-cpu \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration "TargetValue=70,PredefinedMetricSpecification={PredefinedMetricType=ASGAverageCPUUtilization}"

37. ¿Qué es CloudWatch y cómo lo usarías para monitoreo y alertas?

CloudWatch es el servicio central de observabilidad de AWS: métricas, logs, trazas y dashboards.

# Crear una alarma: alerta si CPU > 80% por 5 minutos
aws cloudwatch put-metric-alarm \
  --alarm-name "HighCPU-Production" \
  --metric-name CPUUtilization \
  --namespace AWS/EC2 \
  --statistic Average \
  --period 300 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 2 \
  --alarm-actions arn:aws:sns:...:mi-topic

Para aplicaciones en containers, usá Container Insights (ECS/EKS) que agrega métricas a nivel de contenedor, tarea y cluster automáticamente.

38. ¿Qué es AWS Lambda y cuándo lo usarías en un stack DevOps?

Lambda es compute serverless — corré código en respuesta a eventos sin gestionar servidores. En un contexto DevOps:

• Automatización de operaciones (notificaciones de deploys, limpiezas de recursos).
• Procesamiento de eventos de S3, SQS, DynamoDB Streams.
• Webhooks y APIs de baja frecuencia.
• Custom resources en CloudFormation.

No es ideal para: procesos que corren más de 15 minutos, workloads con estado, cargas predecibles y constantes (EC2 es más barato).

39. ¿Cómo diseñarías una arquitectura AWS altamente disponible?

Pilar a pilar:

1. 1Multi-AZ por defecto: distribuí instancias EC2 y RDS en al menos 2 AZs.
2. 2Stateless application tier: guardá el estado en RDS/ElastiCache, no en la instancia. Así podés escalar y reemplazar instancias sin pérdida de datos.
3. 3ALB health checks: el LB saca del pool cualquier instancia que falle.
4. 4Auto Scaling: reemplaza instancias unhealthy automáticamente.
5. 5Route 53 Health Checks: failover DNS entre regiones para disaster recovery.
6. 6S3 + CloudFront: para assets estáticos, durabilidad y baja latencia global.

40. ¿Qué es AWS ECR y cómo lo integrarías con un pipeline de CI/CD?

ECR (Elastic Container Registry) es el registry privado de imágenes Docker de AWS, integrado nativo con ECS/EKS e IAM:

# Autenticar Docker con ECR
aws ecr get-login-password --region us-east-1 | \
  docker login --username AWS --password-stdin \
  123456789.dkr.ecr.us-east-1.amazonaws.com

# Tag y push
docker build -t myapp .
docker tag myapp:latest 123456789.dkr.ecr.us-east-1.amazonaws.com/myapp:$GIT_SHA
docker push 123456789.dkr.ecr.us-east-1.amazonaws.com/myapp:$GIT_SHA

En un pipeline de GitHub Actions, usás la action aws-actions/amazon-ecr-login con OIDC (sin credenciales hardcodeadas).

CI/CD e Infraestructura como Código (Preguntas 41–48)

41. ¿Cómo diseñarías un pipeline de CI/CD para una app Dockerizada en AWS?

Pipeline completo:

# .github/workflows/deploy.yml
on:
  push:
    branches: [main]

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write  # para OIDC con AWS

    steps:
    - uses: actions/checkout@v4

    - name: Configure AWS credentials (OIDC, sin secrets de larga vida)
      uses: aws-actions/configure-aws-credentials@v4
      with:
        role-to-assume: arn:aws:iam::123456789:role/github-actions-deploy
        aws-region: us-east-1

    - name: Login to ECR
      uses: aws-actions/amazon-ecr-login@v2

    - name: Build, tag, push
      run: |
        docker build -t $ECR_REGISTRY/myapp:$GITHUB_SHA .
        docker push $ECR_REGISTRY/myapp:$GITHUB_SHA

    - name: Deploy to ECS
      uses: aws-actions/amazon-ecs-deploy-task-definition@v1
      with:
        task-definition: task-definition.json
        service: myapp-service
        cluster: production
        wait-for-service-stability: true

42. ¿Qué es Terraform y cómo manejarías el state en equipo?

Terraform es IaC declarativo: describís el estado deseado de la infra y Terraform calcula el plan de cambios (terraform plan) y lo aplica (terraform apply).

Para trabajo en equipo, el state NUNCA va en git:

# Backend en S3 + DynamoDB para locking
terraform {
  backend "s3" {
    bucket         = "mi-empresa-tfstate"
    key            = "production/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-lock"  # evita que dos devs apliquen a la vez
  }
}

43. ¿Qué es GitOps y cómo funciona con ArgoCD?

GitOps es el patrón donde git es la única fuente de verdad de la infra y las apps. Los cambios se aplican creando un PR, nunca con kubectl apply manual.

ArgoCD es el operador que implementa GitOps para Kubernetes:

1. 1Definís el estado deseado en un repo git (manifests YAML o chart Helm).
2. 2ArgoCD monitorea el repo y detecta divergencias entre el estado en git y el estado en el cluster.
3. 3Sincroniza automáticamente (o bajo aprobación manual) el cluster al estado en git.

Beneficios: auditoría completa (cada cambio es un commit), rollback trivial (git revert), no necesitás dar permisos de kubectl al pipeline de CI.

44. ¿Cómo manejarías un incidente de producción? Describí el proceso.

1. 1Detección: alerta de CloudWatch/PagerDuty. Asignar un incident commander.
2. 2Contención: mitigar el impacto YA, aunque no sepas la causa. Ej.: rollback del último deploy (helm rollback, kubectl rollout undo).
3. 3Diagnóstico: logs (kubectl logs --previous, CloudWatch Logs Insights), métricas (CloudWatch, Datadog), trazas.
4. 4Remediación: fix o workaround aplicado al problema raíz.
5. 5Comunicación: status page actualizado, stakeholders informados.
6. 6Post-mortem blameless: dentro de las 48h. Qué pasó, por qué, qué previene la recurrencia. Sin culpas a personas.

45. ¿Qué es la observabilidad y cuáles son sus tres pilares?

Observabilidad es la capacidad de entender el estado interno de un sistema desde sus salidas externas.

Los tres pilares:

• Logs: registros de eventos discretos con timestamp y contexto. Herramientas: CloudWatch Logs, Loki, Elasticsearch.
• Métricas: valores numéricos agregados en el tiempo (CPU, latencia p99, requests/s). Herramientas: Prometheus, CloudWatch Metrics, Datadog.
• Trazas (Distributed Tracing): seguimiento de una request a través de múltiples microservicios. Herramientas: AWS X-Ray, Jaeger, Tempo.

46. ¿Qué es la regla del 12-Factor App y por qué importa para DevOps?

El 12-Factor es una metodología para construir apps cloud-native. Los factores más relevantes para DevOps:

• Config en variables de entorno (no hardcodeada): facilita deploys entre ambientes.
• Procesos stateless: la instancia puede morir y ser reemplazada sin pérdida de datos.
• Logs como streams: la app escribe a stdout; la infraestructura se encarga de capturar y enrutar.
• Dev/prod parity: los ambientes son lo más similares posible — Docker y docker-compose son la implementación práctica.
• Build, release, run separados: el artefacto (imagen Docker) es inmutable entre stages.

47. ¿Qué es el shift-left en seguridad (DevSecOps)?

Shift-left es mover los controles de seguridad lo más temprano posible en el ciclo de desarrollo:

• En el IDE: SAST — ESLint con reglas de seguridad, Semgrep.
• En el PR: escaneo de dependencias vulnerables (Dependabot, Snyk), secrets scanning (git-secrets, truffleHog).
• En CI: escaneo de imágenes Docker (Trivy, Grype) antes del push a ECR.
• En producción: DAST, WAF (AWS WAF), guardia de runtime (Falco).

# Escanear imagen antes de deployar
trivy image --exit-code 1 --severity HIGH,CRITICAL myapp:$SHA

48. Pregunta de diseño: diseñá la infraestructura para una API REST en AWS con alta disponibilidad, auto scaling y zero-downtime deploys.

Arquitectura:

Internet → Route 53 → CloudFront (cache, WAF)
                          ↓
              Application Load Balancer (multi-AZ)
                    ↓              ↓
          ECS Fargate (us-east-1a)  ECS Fargate (us-east-1b)
                    ↓              ↓
              RDS Aurora PostgreSQL (Multi-AZ, writer + 2 readers)
                          ↓
              ElastiCache Redis (cluster mode, session/cache)

Deploys zero-downtime: Blue/Green con ALB — el pipeline crea un nuevo Target Group (green), corre smoke tests, y el ALB cambia el tráfico al nuevo TG de una. Rollback en segundos. IaC en Terraform, pipeline en GitHub Actions con OIDC, secretos en AWS Secrets Manager inyectados por ECS al arrancar la tarea.

Tip final: cómo practicar antes de la entrevista

Leer es necesario pero no suficiente. Los entrevistadores senior hacen preguntas de seguimiento ("¿y qué pasa si el nodo falla ahí?") que solo podés responder si lo viste funcionar.

Armate un lab casero: un cluster local con kind o minikube, una cuenta AWS Free Tier, y un repo con un docker-compose.yml real. Practicá respondiendo en voz alta — la fluidez técnica se construye hablando, no leyendo.