Google PCA: Fiabilidad, Recuperación ante Desastres y Continuidad del Negocio — Guía de estudio

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

Forma parte de la Google Professional Cloud Architect — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Google, o realiza tests cronometrados en ExamRoll.io.

Descripción general

La fiabilidad, la recuperación ante desastres (DR) y la continuidad del negocio garantizan que los servicios continúen cumpliendo los objetivos acordados a pesar de fallos de componentes, zonas o regiones. En Google Cloud, la fiabilidad se diseña comprendiendo los dominios de fallo (zonales, regionales y globales), definiendo los objetivos de recuperación (RTO/RPO), seleccionando arquitecturas de servicio resilientes (p. ej., activo-activo) y probando rigurosamente los planes de recuperación. Tu diseño debe asignar la criticidad del servicio a objetivos de disponibilidad explícitos, garantías de durabilidad y rutas de recuperación validadas, equilibrando la disponibilidad, la consistencia, el costo y la complejidad operativa. Los temas clave incluyen aislar los puntos únicos de fallo, usar replicación gestionada siempre que sea posible, automatizar las decisiones de conmutación por error (failover) y validar continuamente que las suposiciones se mantienen en condiciones similares a las de producción.

Dominios de fallo, ubicaciones y servicios multirregionales

• Zonas de disponibilidad y regiones:
  • Las zonas son dominios de fallo independientes dentro de una región. Los fallos zonales son los eventos a gran escala más comunes para los que se diseña.
  • Las regiones son colecciones de zonas con enlaces de baja latencia. Los fallos regionales son más raros, pero deben considerarse para sistemas de alta criticidad.
  • Patrones de diseño:
    • Intrarregional: Ubica la computación sin estado (stateless) en al menos dos zonas mediante grupos de instancias gestionados (MIGs) regionales.
    • Interregional: Replica el estado y conmuta por error el tráfico para servicios críticos que no pueden tolerar la pérdida de una región.
• Servicios multirregionales y globales:
  • Planos de control globales: Las redes VPC, Cloud DNS, el balanceo de carga HTTP(S) externo global y Cloud IAM son servicios de alcance global que se utilizan para reducir el acoplamiento regional.
  • La ubicación del plano de datos es importante:
    • Cloud Storage: elige buckets regionales, birregionales o multirregionales alineados con los patrones de acceso y las necesidades de DR.
    • BigQuery: los datasets residen en una región o multirregión; la multirregión mejora la disponibilidad de la superficie de análisis, pero considera la residencia de los datos y el egreso para las uniones (joins) externas.
    • Spanner: la configuración de la instancia (regional o multirregional) define la topología de las réplicas y el comportamiento de la consistencia.
• Análisis de dominios de fallo:
  • Asigna a cada componente su radio de impacto (blast radius). Ejemplos:
    • Zonal: una sola VM, un pool de nodos de GKE zonal, un PD de SSD zonal.
    • Regional: la instancia principal y la de reserva (standby) de Cloud SQL HA son regionales; algunos eventos de mantenimiento pueden afectar a una región.
    • Global: una configuración incorrecta de IAM o Cloud DNS afecta a todas las regiones.
  • Identifica fallos correlacionados, como dependencias compartidas (p. ej., una única puerta de enlace NAT, una única instancia de Memorystore) o riesgos inducidos por humanos (cuenta de servicio compartida, un único estado de Terraform).
  • Considera las cuotas como dominios de fallo; un autoescalador que alcanza el límite de cuota regional está funcionalmente caído.

Compensaciones (Trade-offs):

• La replicación entre zonas reduce el tiempo de inactividad, pero añade tráfico y costo entre zonas.
• Los diseños entre regiones reducen el RTO, pero aumentan la latencia, la complejidad y el gasto.
• El balanceo de carga global anycast simplifica la conmutación por error, pero solo enmascara los backends en mal estado si las comprobaciones de estado (health checks) son precisas.

Objetivos, mapeo de dependencias y validación de DR

• RTO y RPO:
  • Recovery Time Objective (RTO): tiempo objetivo para restaurar el servicio. Impulsa la profundidad de la automatización, la postura de los sistemas de reserva (standby) y el detalle de los manuales de operaciones (runbooks).
  • Recovery Point Objective (RPO): ventana de pérdida de datos aceptable. Impulsa la elección de la replicación y la cadencia de las copias de seguridad.
• Criticidad y clasificación de servicios (tiering):
  • Define niveles (p. ej., Nivel 0: impacto en la seguridad/financiero; Nivel 1: ingresos; Nivel 2: herramientas internas) con SLOs, RTO/RPO y frecuencia de pruebas objetivo.
  • Vincula el gasto y la complejidad al nivel; no todos los servicios necesitan ser interregionales.
• Mapeo de dependencias:
  • Haz un inventario de las dependencias ascendentes (upstream) y descendentes (downstream): identidad (Cloud IAM, SAML IdP), secretos (Secret Manager, KMS), redes (DNS, Cloud Interconnect/VPN), almacenamiento y bases de datos, observabilidad, CI/CD y APIs de terceros.
  • Documenta la región, la zona y el SLA para cada dependencia; define controles de compensación para los eslabones más débiles.
• Planes de recuperación:
  • Crea manuales de operaciones (runbooks) y automatización para la conmutación por error (failover) y la recuperación (failback), restauraciones de datos y promoción de configuraciones (DNS, backends de balanceadores de carga, firewall).
  • Preaprovisiona permisos y cuentas de servicio; prepara las definiciones de infraestructura para eliminar las barreras manuales.
  • Mantén un acceso de emergencia (break-glass) con elevación de privilegios auditable.
• Pruebas de recuperación:
  • Programa conmutaciones por error (failovers) rutinarias para sistemas con estado (stateful) (p. ej., Cloud SQL HA) para validar la promoción y la renegociación de la conexión.
  • Realiza simulacros (game days) que simulen una interrupción zonal o regional; incluye proveedores ascendentes (upstream) y fallos de IAM/KMS.
  • Usa la inyección de fallos para validar los interruptores de circuito (circuit breakers), los tiempos de espera (timeouts) y los reintentos; verifica que el autoescalado y la contrapresión (backpressure) funcionen como se espera.
  • Mide continuamente el RTO/RPO durante las pruebas; ajusta la arquitectura cuando no se cumplan los objetivos.

Patrones de resiliencia para cómputo, bases de datos y almacenamiento

• Cómputo autorreparable con MIGs regionales y balanceo de carga:
  • Usa MIGs regionales para distribuir instancias entre zonas con autoescalado y autorreparación.
  • Utiliza un balanceador de carga HTTP(S) externo y global como front-end y una verificación de estado del servicio de backend alineada con la disponibilidad real (p. ej., /healthz que verifique las dependencias).
  • Permite las verificaciones de estado a través de los firewalls para evitar el reciclaje constante de VMs:

    gcloud compute firewall-rules create allow-lb-health-checks \
      --network=prod-vpc --action=ALLOW --direction=INGRESS \
      --rules=tcp:80,tcp:443 \
      --source-ranges=130.211.0.0/22,35.191.0.0/16 \
      --target-tags=web-backend
    ```

  - Evita el estado local; externaliza las sesiones a Memorystore o bases de datos; usa el drenado de conexiones (*connection draining*) en los *backends* para preservar las solicitudes en curso durante un escalado hacia adentro (*scale-in*).
  - Modos de fallo comunes: verificaciones de estado desalineadas (que comprueban demasiado o muy poco), reglas de firewall faltantes y un *bootstrapping* que depende de servicios dependientes (*downstreams*) no saludables.
- Resiliencia de Cloud SQL:
  - Alta disponibilidad: instancia principal y de reserva (*standby*) en zonas separadas con replicación síncrona de disco y conmutación por error (*failover*) automática; selecciona una ventana de mantenimiento y prueba las conmutaciones por error.
  - Réplicas de lectura: añade réplicas de lectura en la misma región o entre regiones para descargar las lecturas y reducir el RTO ante eventos regionales; promueve las réplicas durante un DR.
  - Copias de seguridad y PITR:
    - Habilita copias de seguridad diarias automatizadas y la recuperación a un momento dado (*point-in-time recovery* o PITR) a través de registros binarios/de transacciones con una retención suficiente para el cumplimiento normativo y el RPO.
    - Valida las restauraciones en entornos de no producción y ensaya los procedimientos de promoción y las actualizaciones de las cadenas de conexión de la aplicación.
  - Red: prefiere la IP privada para producción; asegúrate de que las pruebas de conmutación por error validen el comportamiento del DNS y del *pool* de conexiones.
  - Consejo operativo: ejecuta periódicamente una conmutación por error controlada para verificar que los *pools* de la aplicación se reconectan sin problemas.

gcloud sql instances failover prod-sql
```

• Configuración y resiliencia de Spanner:
  • Las instancias regionales proporcionan lecturas/escrituras de baja latencia y consistencia alta dentro de una región usando Paxos entre zonas.
  • Las instancias multirregionales se replican entre regiones con escrituras de quórum síncronas (consistencia alta global) y réplicas opcionales de solo lectura; elige una región líder cercana a los sistemas que realizan las escrituras (writers).
  • Compensaciones: la configuración multirregional mejora el RTO/RPO y la disponibilidad de lectura, pero aumenta la latencia de escritura y el costo. Úsala para cargas de trabajo distribuidas globalmente e intensivas en escritura que necesiten consistencia alta; de lo contrario, considera Spanner regional o Cloud SQL con réplicas.
• Patrones de durabilidad y recuperación de Cloud Storage:
  • Estrategia de ubicación: regional para la localidad del cómputo, birregional (dual-region) para un esquema activo-activo entre dos regiones, multirregional para una amplia disponibilidad para usuarios globales.
  • Control de versiones: habilita el control de versiones de objetos para recuperarte de eliminaciones o corrupciones; combínalo con reglas de ciclo de vida para gestionar los costos.
  • Retención: aplica políticas de retención a nivel de bucket y, si es necesario, bloqueos de retención para el cumplimiento normativo; usa retenciones basadas en eventos para la gestión de registros.
  • Patrones de copia de seguridad: los buckets en proyectos cruzados y con administración separada mitigan la eliminación accidental y la escalada de privilegios. Para las bases de datos, exporta copias de seguridad lógicas a Cloud Storage en un proyecto distinto.
  • Ejemplo de regla de ciclo de vida para eliminar versiones con más de 90 días de antigüedad:

    {
      "rule": [
        {
          "action": { "type": "Delete" },
          "condition": { "age": 90, "isLive": false }
        }
      ]
    }
    ```

    Aplícala con:

gsutil lifecycle set lifecycle.json gs://prod-backups
```

• Recuperación: mantén catálogos de objetos críticos y prueba las restauraciones; para conjuntos de datos grandes, prepara las restauraciones en buckets temporales para evitar colisiones de nombres y validar la integridad.

← Seguridad · Todos los dominios · Migración →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Explorar Google →