Preguntas de entrevista para arquitecto cloud: arquitectura y seguridad

Introducción

En una entrevista de arquitecto cloud suelen evaluar cómo tomas decisiones de equilibrio: fiabilidad frente a coste, servicios gestionados frente a portabilidad, estándares centrales frente a autonomía de equipos y controles de seguridad frente a velocidad de entrega. Una buena respuesta explica el objetivo de negocio, las restricciones, la arquitectura objetivo, los riesgos y el modelo operativo después del lanzamiento.

Usa esta guía para practicar preguntas frecuentes sobre estrategia multi-nube, planificación de migración, microservicios, service mesh, recuperación ante desastres, zero trust y optimización de costes.

Estrategia Multi-Nube

1. ¿Cómo diseña una estrategia multi-nube?

Respuesta: Multi-nube aprovecha múltiples proveedores de nube para la resiliencia, la optimización de costes y evitar el bloqueo del proveedor.

Consideraciones Clave:

Patrones de Arquitectura:

1. Activo-Activo:

• Las cargas de trabajo se ejecutan simultáneamente en múltiples nubes
• Balanceo de carga entre proveedores
• Máxima disponibilidad

2. Activo-Pasivo:

• Nube primaria para producción
• Secundaria para recuperación ante desastres
• Rentable

3. Servicios Agnostic a la Nube:

• Utilizar Kubernetes para la portabilidad
• Terraform para IaC en todas las nubes
• Pipelines CI/CD estandarizados

Desafíos:

• Complejidad en la gestión
• Costes de transferencia de datos
• Requisitos de habilidades
• Políticas de seguridad consistentes

Rareza: Común Dificultad: Difícil

2. ¿Cómo planifica y ejecuta una migración a la nube?

Respuesta: La migración a la nube requiere una planificación cuidadosa, evaluación de riesgos y ejecución por fases.

Las 7 R de la Migración:

Estrategias de Migración:

1. Rehost (Lift and Shift):

• Mover la aplicación con cambios mínimos
• Útil para salir rápido de un centro de datos
• Suele requerir optimización después de migrar

2. Relocate:

• Mover una plataforma o carga virtualizada sin cambiar la aplicación
• Útil cuando la nube destino ofrece una ruta compatible de traslado
• Validar red, identidad, backup y licencias

3. Replatform:

• Hacer cambios limitados, como pasar a una base de datos gestionada o a contenedores
• Equilibra velocidad de migración y mejora operativa

4. Refactor/Re-architect:

• Rediseñar para escalado cloud-native, resiliencia o velocidad de entrega
• Mayor esfuerzo, reservado para sistemas de alto valor

5. Repurchase:

• Sustituir la aplicación por SaaS
• Ejemplo: reemplazar un CRM propio por una plataforma CRM gestionada

6. Retire:

• Retirar aplicaciones que ya no aportan valor de negocio

7. Retain:

• Mantener un sistema donde está por cumplimiento, latencia, coste o secuencia del programa

Fases de Migración:

# Herramienta de evaluación de la migración
class MigrationAssessment:
    def __init__(self, application):
        self.app = application
        self.score = 0
    
    def assess_cloud_readiness(self):
        factors = {
            'architecture': self.check_architecture(),
            'dependencies': self.check_dependencies(),
            'data_volume': self.check_data_volume(),
            'compliance': self.check_compliance(),
            'performance': self.check_performance_requirements()
        }
        
        # Calcular la complejidad de la migración
        complexity = sum(factors.values()) / len(factors)
        
        if complexity < 3:
            return "Rehost - Baja complejidad"
        elif complexity < 6:
            return "Replatform - Complejidad media"
        else:
            return "Refactor - Alta complejidad"
    
    def generate_migration_plan(self):
        return {
            'phase_1': 'Evaluación y Planificación',
            'phase_2': 'Prueba de Concepto',
            'phase_3': 'Migración de Datos',
            'phase_4': 'Migración de Aplicaciones',
            'phase_5': 'Pruebas y Validación',
            'phase_6': 'Puesta en Marcha y Lanzamiento',
            'phase_7': 'Optimización'
        }

Ejecución de la Migración:

1. Evaluación:

• Inventariar aplicaciones y dependencias
• Analizar costes (TCO)
• Identificar riesgos y restricciones

2. Planificación:

• Elegir la estrategia de migración por aplicación
• Definir los criterios de éxito
• Crear planes de reversión

3. Migración Piloto:

• Comenzar con una aplicación no crítica
• Validar el enfoque
• Refinar los procesos

4. Migración de Datos:

# Ejemplo: Migración de base de datos con AWS DMS
aws dms create-replication-instance \
    --replication-instance-identifier migration-instance \
    --replication-instance-class dms.t2.medium

# Crear tarea de migración
aws dms create-replication-task \
    --replication-task-identifier db-migration \
    --source-endpoint-arn arn:aws:dms:region:account:endpoint/source \
    --target-endpoint-arn arn:aws:dms:region:account:endpoint/target \
    --migration-type full-load-and-cdc

5. Estrategia de Transición:

• Big Bang: Todo de una vez (arriesgado)
• Por Fases: Migración gradual (más seguro)
• Ejecución Paralela: Ejecutar ambos entornos

Mitigación de Riesgos:

• Pruebas exhaustivas
• Procedimientos de reversión automatizados
• Líneas de base de rendimiento
• Validación de seguridad
• Monitorización de costes

Rareza: Muy Común Dificultad: Media-Difícil

Arquitectura de Microservicios

3. ¿Cómo diseña una arquitectura de microservicios?

Respuesta: Los microservicios descomponen las aplicaciones en servicios pequeños e independientes.

Arquitectura:

Principios Clave:

1. Independencia del Servicio:

• Cada servicio posee sus datos
• Despliegue independiente
• Se permite la diversidad tecnológica

2. Comunicación:

# Síncrono (REST API)
import requests

def get_user(user_id):
    response = requests.get(f'http://user-service/api/users/{user_id}')
    return response.json()

# Asíncrono (Cola de Mensajes)
import pika

def publish_order_event(order_data):
    connection = pika.BlockingConnection(pika.ConnectionParameters('rabbitmq'))
    channel = connection.channel()
    channel.queue_declare(queue='orders')
    channel.basic_publish(
        exchange='',
        routing_key='orders',
        body=json.dumps(order_data)
    )
    connection.close()

3. API Gateway:

• Punto de entrada único
• Autenticación/autorización
• Limitación de velocidad
• Enrutamiento de solicitudes

4. Descubrimiento de Servicios:

• Registro dinámico de servicios
• Comprobaciones de salud
• Balanceo de carga

Beneficios:

• Escalado independiente
• Flexibilidad tecnológica
• Aislamiento de fallos
• Despliegue más rápido

Desafíos:

• Complejidad del sistema distribuido
• Consistencia de datos
• Complejidad de las pruebas
• Sobrecarga operativa

Rareza: Muy Común Dificultad: Difícil

4. ¿Cómo implementa una malla de servicio en microservicios?

Respuesta: Una malla de servicio proporciona una capa de infraestructura para la comunicación servicio a servicio, gestionando el tráfico, la seguridad y la observabilidad.

Arquitectura:

Características Clave:

1. Gestión del Tráfico:

• Balanceo de carga
• Circuit breaking
• Reintentos y timeouts
• Despliegues canary
• Pruebas A/B

2. Seguridad:

• Cifrado mTLS
• Autenticación
• Políticas de autorización

3. Observabilidad:

• Trazado distribuido
• Recolección de métricas
• Registro de acceso

Implementación de Istio:

# Servicio Virtual para el enrutamiento del tráfico
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews-route
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        user-type:
          exact: premium
    route:
    - destination:
        host: reviews
        subset: v2
      weight: 100
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 90
    - destination:
        host: reviews
        subset: v2
      weight: 10

---
# Regla de Destino para el balanceo de carga
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews-destination
spec:
  host: reviews
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 50
        maxRequestsPerConnection: 2
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

Configuración del Circuit Breaker:

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: circuit-breaker
spec:
  host: payment-service
  trafficPolicy:
    outlierDetection:
      consecutiveErrors: 5
      interval: 30s
      baseEjectionTime: 30s
      maxEjectionPercent: 50

Seguridad mTLS:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT

---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-read
spec:
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/frontend"]
    to:
    - operation:
        methods: ["GET"]

Observabilidad con Kiali:

# Instalar Istio con addons de observabilidad
istioctl install --set profile=demo

# Desplegar Kiali, Prometheus, Grafana, Jaeger
kubectl apply -f samples/addons/

# Acceder al dashboard de Kiali
istioctl dashboard kiali

Comparación de Mallas de Servicio:

Cuándo Usar:

• Entornos de microservicios donde políticas compartidas de tráfico, identidad y observabilidad justifican la complejidad operativa
• Necesidad de gestión avanzada del tráfico
• Requisitos de seguridad (mTLS)
• Despliegues multi-cluster
• Requisitos de observabilidad

Rareza: Común Dificultad: Difícil

Patrones de Diseño

5. Explique el patrón Circuit Breaker y cuándo usarlo.

Respuesta: El Circuit Breaker previene fallos en cascada en sistemas distribuidos.

Estados:

1. Cerrado: Operación normal
2. Abierto: Fallos detectados, las solicitudes fallan rápidamente
3. Semi-Abierto: Probando si el servicio se ha recuperado

from enum import Enum
import time

class CircuitState(Enum):
    CLOSED = "cerrado"
    OPEN = "abierto"
    HALF_OPEN = "semi-abierto"

class CircuitBreaker:
    def __init__(self, failure_threshold=5, timeout=60, success_threshold=2):
        self.failure_threshold = failure_threshold
        self.timeout = timeout
        self.success_threshold = success_threshold
        self.failures = 0
        self.successes = 0
        self.last_failure_time = None
        self.state = CircuitState.CLOSED
    
    def call(self, func, *args, **kwargs):
        if self.state == CircuitState.OPEN:
            if time.time() - self.last_failure_time > self.timeout:
                self.state = CircuitState.HALF_OPEN
                self.successes = 0
            else:
                raise Exception("El circuit breaker está ABIERTO")
        
        try:
            result = func(*args, **kwargs)
            self.on_success()
            return result
        except Exception as e:
            self.on_failure()
            raise e
    
    def on_success(self):
        self.failures = 0
        if self.state == CircuitState.HALF_OPEN:
            self.successes += 1
            if self.successes >= self.success_threshold:
                self.state = CircuitState.CLOSED
    
    def on_failure(self):
        self.failures += 1
        self.last_failure_time = time.time()
        if self.failures >= self.failure_threshold:
            self.state = CircuitState.OPEN

# Uso
breaker = CircuitBreaker()
result = breaker.call(external_api_call, user_id=123)

Casos de Uso:

• Llamadas a APIs externas
• Conexiones a bases de datos
• Comunicación entre microservicios
• Integraciones de terceros

Rareza: Común Dificultad: Media-Difícil

Arquitectura Dirigida por Eventos

6. Explique la arquitectura dirigida por eventos y cuándo usarla.

Respuesta: La Arquitectura Dirigida por Eventos (EDA) utiliza eventos para activar y comunicarse entre servicios desacoplados.

Arquitectura:

Conceptos Centrales:

1. Evento:

• Hecho inmutable que sucedió
• Contiene datos relevantes
• Con marca de tiempo

2. Productor de Eventos:

• Publica eventos
• No conoce a los consumidores

3. Consumidor de Eventos:

• Se suscribe a eventos
• Procesa asíncronamente

4. Bus/Broker de Eventos:

• Enruta eventos
• Ejemplos: Kafka, RabbitMQ, AWS EventBridge

Implementación de Kafka:

from kafka import KafkaProducer, KafkaConsumer
import json
from datetime import datetime
import uuid

# Productor de Eventos
class OrderEventProducer:
    def __init__(self):
        self.producer = KafkaProducer(
            bootstrap_servers=['localhost:9092'],
            value_serializer=lambda v: json.dumps(v).encode('utf-8')
        )
    
    def publish_order_created(self, order_id, customer_id, items, total):
        event = {
            'event_type': 'OrderCreated',
            'event_id': str(uuid.uuid4()),
            'timestamp': datetime.utcnow().isoformat(),
            'data': {
                'order_id': order_id,
                'customer_id': customer_id,
                'items': items,
                'total': total
            }
        }
        self.producer.send('order-events', value=event)
        self.producer.flush()

# Consumidor de Eventos
class InventoryEventConsumer:
    def __init__(self):
        self.consumer = KafkaConsumer(
            'order-events',
            bootstrap_servers=['localhost:9092'],
            value_deserializer=lambda m: json.loads(m.decode('utf-8')),
            group_id='inventory-service'
        )
    
    def process_events(self):
        for message in self.consumer:
            event = message.value
            if event['event_type'] == 'OrderCreated':
                self.reserve_inventory(event['data'])
    
    def reserve_inventory(self, order_data):
        # Lógica para reservar el inventario
        print(f"Reservando inventario para el pedido {order_data['order_id']}")
        # Publicar el evento InventoryReserved

Patrón de Event Sourcing:

# Almacenar eventos en lugar del estado actual
class EventStore:
    def __init__(self):
        self.events = []
    
    def append(self, event):
        self.events.append(event)
    
    def get_events(self, aggregate_id):
        return [e for e in self.events if e['aggregate_id'] == aggregate_id]

# Reconstruir el estado a partir de los eventos
class OrderAggregate:
    def __init__(self, order_id):
        self.order_id = order_id
        self.status = 'pending'
        self.items = []
        self.total = 0
    
    def apply_event(self, event):
        if event['type'] == 'OrderCreated':
            self.items = event['data']['items']
            self.total = event['data']['total']
        elif event['type'] == 'OrderPaid':
            self.status = 'paid'
        elif event['type'] == 'OrderShipped':
            self.status = 'shipped'
    
    def rebuild_from_events(self, events):
        for event in events:
            self.apply_event(event)

CQRS (Command Query Responsibility Segregation):

Beneficios:

• Acoplamiento débil
• Escalabilidad
• Flexibilidad
• Pista de auditoría (event sourcing)
• Procesamiento en tiempo real

Desafíos:

• Consistencia eventual
• Evolución del esquema de eventos
• Complejidad de la depuración
• Manejo de eventos duplicados

Casos de Uso:

• Procesamiento de pedidos de comercio electrónico
• Analítica en tiempo real
• Procesamiento de datos de IoT
• Comunicación entre microservicios
• Sistemas de auditoría y cumplimiento

Rareza: Común Dificultad: Difícil

Recuperación ante Desastres

7. ¿Cómo diseña una estrategia de recuperación ante desastres?

Respuesta: La recuperación ante desastres (DR) asegura la continuidad del negocio durante las interrupciones.

Métricas Clave:

• RTO (Recovery Time Objective): Tiempo máximo aceptable de inactividad
• RPO (Recovery Point Objective): Pérdida máxima aceptable de datos

Estrategias de DR:

Ejemplo de Implementación:

Automatización:

# Script de failover automatizado
def initiate_failover():
    # 1. Detener las escrituras en la primaria
    stop_primary_writes()
    
    # 2. Promocionar la base de datos secundaria
    promote_secondary_to_primary()
    
    # 3. Actualizar el DNS
    update_route53_failover()
    
    # 4. Iniciar los servicios de la región de DR
    start_dr_services()
    
    # 5. Verificar la salud
    verify_dr_health()
    
    # 6. Notificar al equipo
    send_alert("Failover completado a la región de DR")

Pruebas:

• Simulacros regulares de DR según la criticidad de la carga
• Pruebas automatizadas
• Documentar los runbooks
• Revisiones post-incidente

Rareza: Muy Común Dificultad: Difícil

Seguridad y Cumplimiento

8. ¿Cómo implementa la seguridad de confianza cero en la arquitectura de la nube?

Respuesta: La Confianza Cero asume que no hay confianza implícita, verifica todo.

Principios:

1. Verificar explícitamente
2. Acceso con el mínimo privilegio
3. Asumir la brecha

Implementación:

Componentes:

1. Identidad y Acceso:

# Ejemplo: Política de acceso condicional
policies:
  - name: "Requerir MFA para aplicaciones sensibles"
    conditions:
      applications: ["finance-app", "hr-system"]
      users: ["all"]
    controls:
      - require_mfa: true
      - require_compliant_device: true
      - allowed_locations: ["corporate-network", "vpn"]

2. Segmentación de la Red:

• Micro-segmentación
• Malla de servicio (Istio, Linkerd)
• Políticas de red

3. Cifrado:

• Datos en reposo
• Datos en tránsito
• Cifrado de extremo a extremo

4. Monitorización Continua:

• Detección de amenazas en tiempo real
• Analítica del comportamiento
• Respuesta automatizada

Rareza: Común Dificultad: Difícil

Optimización de Costes

9. ¿Cómo optimiza los costes entre múltiples proveedores de nube?

Respuesta: Estrategias de optimización de costes multi-nube:

1. Colocación de Cargas de Trabajo:

• Analizar modelos de precios
• Considerar los costes de transferencia de datos
• Aprovechar las diferencias de precios regionales

2. Capacidad Reservada:

• Instancias Reservadas de AWS
• Instancias de VM Reservadas de Azure
• Descuentos por Uso Comprometido de GCP

3. Instancias Spot/Preemptibles:

# Comparación de costes: rellenar con calculadoras cloud actuales
def compare_options(options):
    return sorted(options, key=lambda option: (
        option["monthly_cost"],
        option["operational_risk"],
        option["commitment_months"]
    ))

4. Monitorización y Gobernanza:

• Paneles de control de costes unificados
• Alertas de presupuesto
• Asignación de costes basada en etiquetas
• Limpieza automatizada de recursos

5. Optimización de la Arquitectura:

• Serverless para cargas de trabajo variables
• Políticas de auto-escalado
• Niveles de almacenamiento
• CDN para contenido estático

Rareza: Muy Común Dificultad: Media-Difícil

Conclusión

Las entrevistas de arquitecto cloud valoran más la toma de decisiones práctica que los diagramas memorizados. Prepárate para explicar:

1. Multi-nube: Por qué una carga necesita más de un proveedor y qué complejidad añade
2. Migración: Opciones 7R, descubrimiento de dependencias, cutover por fases, rollback y optimización posterior
3. Microservicios: Límites, propiedad de datos, contratos de API, resiliencia y coste operativo
4. Service mesh: Cuándo mTLS, políticas de tráfico y observabilidad justifican una capa adicional
5. Patrones de diseño: Circuit breaker, saga, CQRS, idempotencia, reintentos y timeouts
6. Sistemas event-driven: Contratos de eventos, orden, duplicados, evolución de esquemas y consistencia eventual
7. Recuperación ante desastres: RTO/RPO, estrategia regional, runbooks, pruebas y evidencia de recuperación
8. Seguridad: Acceso basado en identidad, mínimo privilegio, cifrado, segmentación, logging y mentalidad assume breach
9. Optimización de costes: Rightsizing, compromisos, etiquetado, limpieza de recursos inactivos, transferencia de datos y gobierno FinOps

Al responder, empieza por la restricción de negocio, nombra el trade-off y explica cómo validarías el diseño en producción.