diciembre 21, 2025
15 min de lectura

Preguntas de entrevista para ingeniero DevOps senior en producción

interview
career-advice
job-search
Preguntas de entrevista para ingeniero DevOps senior en producción
Milad Bonakdar

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)
Loading diagram...

Cómo funciona:

  1. El usuario envía la implementación a través de kubectl
  2. API Server valida y almacena en etcd
  3. Scheduler asigna pods a nodos
  4. kubelet en el nodo crea contenedores
  5. 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:

# 1. Comprobar el estado y los eventos del pod
kubectl describe pod <nombre-del-pod>
# Buscar: Errores de extracción de imágenes, límites de recursos, comprobaciones de salud fallidas

# 2. Comprobar los logs
kubectl logs <nombre-del-pod>
kubectl logs <nombre-del-pod> --previous  # Logs del contenedor anterior

# 3. Comprobar las restricciones de recursos
kubectl top pod <nombre-del-pod>
kubectl describe node <nombre-del-nodo>

# 4. Comprobar las sondas de liveness/readiness
kubectl get pod <nombre-del-pod> -o yaml | grep -A 10 livenessProbe

# 5. Ejecutar dentro del contenedor (si se mantiene activo brevemente)
kubectl exec -it <nombre-del-pod> -- /bin/sh

# 6. Comprobar la imagen
kubectl get pod <nombre-del-pod> -o jsonpath='{.spec.containers[*].image}'
docker pull <imagen>  # Probar localmente

# 7. Comprobar ConfigMaps/Secrets
kubectl get configmap
kubectl get secret

# 8. Revisar la especificación de la implementación/pod
kubectl get deployment <nombre-de-la-implementacion> -o yaml

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:

# Aumentar los límites de recursos
resources:
  limits:
    memory: "512Mi"
    cpu: "500m"
  requests:
    memory: "256Mi"
    cpu: "250m"

# Ajustar el tiempo de la sonda
livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30  # Dar tiempo a la app para que arranque
  periodSeconds: 10
  failureThreshold: 3

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:

# ClusterIP (solo interno)
apiVersion: v1
kind: Service
metadata:
  name: backend
spec:
  type: ClusterIP
  selector:
    app: backend
  ports:
    - port: 80
      targetPort: 8080

# NodePort (acceso externo a través de la IP del nodo)
spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 30080

# LoadBalancer (balanceador de carga en la nube)
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 8080

Ingress: Enrutamiento HTTP/HTTPS:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: api-v1
            port:
              number: 80
      - path: /v2
        pathType: Prefix
        backend:
          service:
            name: api-v2
            port:
              number: 80
  tls:
  - hosts:
    - api.example.com
    secretName: api-tls

Network Policies: Controlar la comunicación pod-a-pod:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database
    ports:
    - protocol: TCP
      port: 5432

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):

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 50
        periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
      - type: Percent
        value: 100
        periodSeconds: 15

Vertical Pod Autoscaler (VPA):

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: app-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app
  updatePolicy:
    updateMode: "Auto"  # or "Recreate", "Initial", "Off"
  resourcePolicy:
    containerPolicies:
    - containerName: app
      minAllowed:
        cpu: 100m
        memory: 128Mi
      maxAllowed:
        cpu: 2
        memory: 2Gi

Cluster Autoscaler: Ajusta automáticamente el tamaño del clúster basándose en los pods pendientes:

# Ejemplo de AWS
apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-autoscaler-config
data:
  min-nodes: "2"
  max-nodes: "10"
  scale-down-delay-after-add: "10m"
  scale-down-unneeded-time: "10m"

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:

# backend.tf
terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
}

Bloqueo de Estado:

# Tabla DynamoDB para el bloqueo de estado
resource "aws_dynamodb_table" "terraform_locks" {
  name         = "terraform-locks"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "LockID"

  attribute {
    name = "LockID"
    type = "S"
  }
}

Mejores Prácticas:

1. Nunca subas archivos de estado a Git

# .gitignore
*.tfstate
*.tfstate.*
.terraform/

2. Usa workspaces para entornos

terraform workspace new dev
terraform workspace new staging
terraform workspace new prod

terraform workspace select dev
terraform apply

3. Importa recursos existentes

# Importar una instancia EC2 existente
terraform import aws_instance.web i-1234567890abcdef0

# Verificar
terraform plan

4. Manipulación del estado (usar con cuidado)

# Listar los recursos en el estado
terraform state list

# Mostrar un recurso específico
terraform state show aws_instance.web

# Mover un recurso en el estado
terraform state mv aws_instance.old aws_instance.new

# Eliminar un recurso del estado (no lo borra)
terraform state rm aws_instance.web

5. Hacer una copia de seguridad del estado antes de grandes cambios

terraform state pull > backup.tfstate

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:

terraform/
├── environments/
│   ├── dev/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   ├── terraform.tfvars
│   │   └── backend.tf
│   ├── staging/
│   └── prod/
├── modules/
│   ├── vpc/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   ├── outputs.tf
│   │   └── README.md
│   ├── eks/
│   ├── rds/
│   └── s3/
└── global/
    ├── iam/
    └── route53/

Ejemplo de Módulo:

# modules/vpc/main.tf
resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = merge(
    var.tags,
    {
      Name = "${var.environment}-vpc"
    }
  )
}

resource "aws_subnet" "private" {
  count             = length(var.private_subnet_cidrs)
  vpc_id            = aws_vpc.main.id
  cidr_block        = var.private_subnet_cidrs[count.index]
  availability_zone = var.availability_zones[count.index]

  tags = merge(
    var.tags,
    {
      Name = "${var.environment}-private-${count.index + 1}"
      Type = "private"
    }
  )
}

# modules/vpc/variables.tf
variable "vpc_cidr" {
  description = "Bloque CIDR para VPC"
  type        = string
}

variable "environment" {
  description = "Nombre del entorno"
  type        = string
}

variable "private_subnet_cidrs" {
  description = "Bloques CIDR para subredes privadas"
  type        = list(string)
}

variable "availability_zones" {
  description = "Zonas de disponibilidad"
  type        = list(string)
}

variable "tags" {
  description = "Tags comunes"
  type        = map(string)
  default     = {}
}

# modules/vpc/outputs.tf
output "vpc_id" {
  value = aws_vpc.main.id
}

output "private_subnet_ids" {
  value = aws_subnet.private[*].id
}

Usando Módulos:

# environments/prod/main.tf
module "vpc" {
  source = "../../modules/vpc"

  vpc_cidr             = "10.0.0.0/16"
  environment          = "prod"
  private_subnet_cidrs = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  availability_zones   = ["us-east-1a", "us-east-1b", "us-east-1c"]

  tags = {
    Project   = "MyApp"
    ManagedBy = "Terraform"
  }
}

module "eks" {
  source = "../../modules/eks"

  cluster_name    = "prod-cluster"
  vpc_id          = module.vpc.vpc_id
  subnet_ids      = module.vpc.private_subnet_ids
  node_group_size = 3
}

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:

Loading diagram...

Componentes Clave:

1. DNS y Gestión del Tráfico:

# Route 53 con comprobaciones de salud
resource "aws_route53_health_check" "primary" {
  fqdn              = "api.example.com"
  port              = 443
  type              = "HTTPS"
  resource_path     = "/health"
  failure_threshold = 3
  request_interval  = 30
}

resource "aws_route53_record" "api" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "api.example.com"
  type    = "A"

  failover_routing_policy {
    type = "PRIMARY"
  }

  set_identifier = "primary"
  health_check_id = aws_route53_health_check.primary.id

  alias {
    name                   = aws_lb.primary.dns_name
    zone_id                = aws_lb.primary.zone_id
    evaluate_target_health = true
  }
}

2. Replicación de la Base de Datos:

# RDS con réplica de lectura entre regiones
resource "aws_db_instance" "primary" {
  identifier           = "prod-db-primary"
  engine               = "postgres"
  instance_class       = "db.r5.xlarge"
  multi_az             = true
  backup_retention_period = 7

  provider = aws.us-east-1
}

resource "aws_db_instance" "replica" {
  identifier             = "prod-db-replica"
  replicate_source_db    = aws_db_instance.primary.arn
  instance_class         = "db.r5.xlarge"
  auto_minor_version_upgrade = false

  provider = aws.us-west-2
}

3. Replicación de Datos:

# Replicación S3 entre regiones
resource "aws_s3_bucket_replication_configuration" "replication" {
  bucket = aws_s3_bucket.source.id
  role   = aws_iam_role.replication.arn

  rule {
    id     = "replicate-all"
    status = "Enabled"

    destination {
      bucket        = aws_s3_bucket.destination.arn
      storage_class = "STANDARD"
    }
  }
}

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:

  1. Configuración declarativa en Git
  2. Sincronización automatizada
  3. Control de versiones para todos los cambios
  4. Reconciliación continua

Implementación de ArgoCD:

# Manifiesto de la aplicación
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/org/app-manifests
    targetRevision: main
    path: k8s/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
      allowEmpty: false
    syncOptions:
    - CreateNamespace=true
    retry:
      limit: 5
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m

Estructura de Directorios:

app-manifests/
├── base/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── kustomization.yaml
└── overlays/
    ├── dev/
    │   ├── kustomization.yaml
    │   └── patches/
    ├── staging/
    └── production/
        ├── kustomization.yaml
        ├── replicas.yaml
        └── resources.yaml

Kustomization:

# overlays/production/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

bases:
- ../../base

replicas:
- name: myapp
  count: 5

resources:
- ingress.yaml

patches:
- path: resources.yaml
  target:
    kind: Deployment
    name: myapp

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:

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

2. RBAC (Control de Acceso Basado en Roles):

# Rol para desarrolladores
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: developer
rules:
- apiGroups: ["", "apps"]
  resources: ["pods", "deployments", "services"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["pods/log"]
  verbs: ["get"]

# RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-binding
  namespace: production
subjects:
- kind: Group
  name: developers
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer
  apiGroup: rbac.authorization.k8s.io

3. Network Policies:

# Denegar por defecto todo el ingreso
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress

4. Gestión de Secretos:

# External Secrets Operator
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: app-secrets
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: SecretStore
  target:
    name: app-secrets
    creationPolicy: Owner
  data:
  - secretKey: database-password
    remoteRef:
      key: prod/database
      property: password

5. Security Context:

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 2000
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: myapp:1.0
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
        - ALL
    volumeMounts:
    - name: tmp
      mountPath: /tmp
  volumes:
  - name: tmp
    emptyDir: {}

6. Image Scanning:

# Controlador de admisión con OPA
apiVersion: v1
kind: ConfigMap
metadata:
  name: opa-policy
data:
  policy.rego: |
    package kubernetes.admission
    
    deny[msg] {
      input.request.kind.kind == "Pod"
      image := input.request.object.spec.containers[_].image
      not startswith(image, "registry.company.com/")
      msg := sprintf("La imagen %v no es de un registro aprobado", [image])
    }

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:

Loading diagram...

1. Métricas (Prometheus + Grafana):

# ServiceMonitor para métricas de la app
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: app-metrics
spec:
  selector:
    matchLabels:
      app: myapp
  endpoints:
  - port: metrics
    interval: 30s
    path: /metrics

2. Logging (Loki):

# Configuración de Promtail para la recolección de logs
apiVersion: v1
kind: ConfigMap
metadata:
  name: promtail-config
data:
  promtail.yaml: |
    server:
      http_listen_port: 9080
    
    clients:
      - url: http://loki:3100/loki/api/v1/push
    
    scrape_configs:
      - job_name: kubernetes-pods
        kubernetes_sd_configs:
          - role: pod
        relabel_configs:
          - source_labels: [__meta_kubernetes_pod_label_app]
            target_label: app
          - source_labels: [__meta_kubernetes_namespace]
            target_label: namespace

3. Tracing (Jaeger):

# Instrumentación de la aplicación
from opentelemetry import trace
from opentelemetry.exporter.jaeger.thrift import JaegerExporter
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor

# Configurar el tracing
trace.set_tracer_provider(TracerProvider())
jaeger_exporter = JaegerExporter(
    agent_host_name="jaeger-agent",
    agent_port=6831,
)
trace.get_tracer_provider().add_span_processor(
    BatchSpanProcessor(jaeger_exporter)
)

tracer = trace.get_tracer(__name__)

# Usar en el código
with tracer.start_as_current_span("process_request"):
    # Tu código aquí
    pass

4. Reglas de Alerta:

# PrometheusRule
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: app-alerts
spec:
  groups:
  - name: app
    interval: 30s
    rules:
    - alert: HighErrorRate
      expr: |
        sum(rate(http_requests_total{status=~"5.."}[5m]))
        /
        sum(rate(http_requests_total[5m]))
        > 0.05
      for: 5m
      labels:
        severity: critical
      annotations:
        summary: "Tasa de error alta detectada"
        description: "La tasa de error es {{ $value | humanizePercentage }}"
    
    - alert: HighLatency
      expr: |
        histogram_quantile(0.95,
          rate(http_request_duration_seconds_bucket[5m])
        ) > 1
      for: 10m
      labels:
        severity: warning
      annotations:
        summary: "Latencia alta detectada"

5. Monitorización de SLO:

# Definición de SLO
apiVersion: sloth.slok.dev/v1
kind: PrometheusServiceLevel
metadata:
  name: api-availability
spec:
  service: "api"
  labels:
    team: "platform"
  slos:
    - name: "requests-availability"
      objective: 99.9
      description: "Las peticiones a la API deberían tener éxito"
      sli:
        events:
          errorQuery: sum(rate(http_requests_total{status=~"5.."}[{{.window}}]))
          totalQuery: sum(rate(http_requests_total[{{.window}}]))
      alerting:
        pageAlert:
          labels:
            severity: critical
        ticketAlert:
          labels:
            severity: warning

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:

# Planificación de backup de Velero
apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: daily-backup
  namespace: velero
spec:
  schedule: "0 2 * * *"  # 2 AM diario
  template:
    includedNamespaces:
    - production
    - staging
    excludedResources:
    - events
    - events.events.k8s.io
    storageLocation: aws-s3
    volumeSnapshotLocations:
    - aws-ebs
    ttl: 720h  # 30 días

2. Backup de etcd:

#!/bin/bash
# Script automatizado de backup de etcd

ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /backup/etcd-snapshot-$(date +%Y%m%d-%H%M%S).db

# Subir a S3
aws s3 cp /backup/etcd-snapshot-*.db s3://etcd-backups/

# Limpiar backups antiguos
find /backup -name "etcd-snapshot-*.db" -mtime +7 -delete

3. Procedimiento de Restauración:

# Restaurar etcd desde la snapshot
ETCDCTL_API=3 etcdctl snapshot restore snapshot.db \
  --data-dir=/var/lib/etcd-restore \
  --initial-cluster=etcd-0=https://10.0.1.10:2380 \
  --initial-advertise-peer-urls=https://10.0.1.10:2380

# Restaurar la aplicación con Velero
velero restore create --from-backup daily-backup-20231125
velero restore describe <nombre-de-la-restauracion>

4. Failover Multi-Región:

# Terraform para configuración multi-región
module "primary_cluster" {
  source = "./modules/eks"
  region = "us-east-1"
  # ... configuración
}

module "dr_cluster" {
  source = "./modules/eks"
  region = "us-west-2"
  # ... configuración
}

# Comprobación de salud y failover de Route 53
resource "aws_route53_health_check" "primary" {
  fqdn              = module.primary_cluster.endpoint
  port              = 443
  type              = "HTTPS"
  resource_path     = "/healthz"
  failure_threshold = 3
}

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:

Loading diagram...

Implementación de Istio:

# Virtual Service para el enrutamiento del tráfico
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 80
    - destination:
        host: reviews
        subset: v2
      weight: 20

# Destination Rule
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST

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.

Newsletter subscription

Consejos de carrera semanales que realmente funcionan

Recibe las últimas ideas directamente en tu bandeja de entrada

Crea un Currículum que Te Contrate 60% Más Rápido

En minutos, crea un currículum personalizado y compatible con ATS que ha demostrado conseguir 6 veces más entrevistas.

Crea un mejor currículum

Compartir esta publicación

Supera la Tasa de Rechazo del 75% de los ATS

3 de cada 4 currículums nunca llegan a un ojo humano. Nuestra optimización de palabras clave aumenta tu tasa de aprobación hasta en un 80%, asegurando que los reclutadores realmente vean tu potencial.