Google PCA: Confiabilidade, Recuperação de Desastres e Continuidade de Negócios — Guia de estudos

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

Faz parte do Google Professional Cloud Architect — Guia de estudos. Pratique com respostas verificadas no centro de exames da Google, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

Confiabilidade, recuperação de desastres (DR) e continuidade dos negócios garantem que os serviços continuem a atender aos objetivos acordados apesar de falhas de componentes, zonas ou regiões. No Google Cloud, a confiabilidade é projetada por meio do entendimento dos domínios de falha (zonal, regional e global), da definição de objetivos de recuperação (RTO/RPO), da seleção de arquiteturas de serviço resilientes (por exemplo, ativo-ativo) e do teste rigoroso dos planos de recuperação. Seu design deve mapear a criticidade do serviço para metas de disponibilidade explícitas, garantias de durabilidade e caminhos de recuperação validados, equilibrando disponibilidade, consistência, custo e complexidade operacional. Os temas principais incluem o isolamento de pontos únicos de falha, o uso de replicação gerenciada sempre que possível, a automação de decisões de failover e a validação contínua de que as premissas se mantêm em condições semelhantes às de produção.

Domínios de Falha, Localizações e Serviços Multirregionais

• Zonas de disponibilidade e regiões:
  • Zonas são domínios de falha independentes dentro de uma região. Falhas zonais são os eventos de grande escala mais comuns para os quais você projeta.
  • Regiões são conjuntos de zonas com links de baixa latência. Falhas regionais são mais raras, mas devem ser consideradas para sistemas de alta criticidade.
  • Padrões de design:
    • Intrarregional: posicione a computação sem estado (stateless) em pelo menos duas zonas por meio de grupos de instâncias gerenciadas (MIGs) regionais.
    • Inter-regional: replique o estado e faça o failover do tráfego para serviços críticos que não toleram a perda de uma região.
• Serviços multirregionais e globais:
  • Planos de controle globais: redes VPC, Cloud DNS, balanceamento de carga HTTP(S) externo global e Cloud IAM são serviços de escopo global usados para reduzir o acoplamento regional.
  • O posicionamento do plano de dados é importante:
    • Cloud Storage: escolha buckets regionais, de região dupla (dual-region) ou multirregionais alinhados aos padrões de acesso e às necessidades de DR.
    • BigQuery: os datasets residem em uma região ou multirregião; a multirregião melhora a disponibilidade da superfície de análise, mas considere a residência dos dados e o egresso para junções externas.
    • Spanner: a configuração da instância (regional ou multirregional) define a topologia da réplica e o comportamento de consistência.
• Análise de domínio de falha:
  • Mapeie cada componente ao seu raio de impacto (blast radius). Exemplos:
    • Zonal: VM única, pool de nós zonal do GKE, PD de SSD zonal.
    • Regional: o primário e o standby do Cloud SQL HA são regionais; alguns eventos de manutenção podem impactar uma região.
    • Global: uma configuração incorreta do IAM ou do Cloud DNS afeta todas as regiões.
  • Identifique falhas correlacionadas, como dependências compartilhadas (por exemplo, um único gateway NAT, uma única instância do Memorystore) ou risco induzido por humanos (conta de serviço compartilhada, um único estado do Terraform).
  • Considere as cotas como domínios de falha; um autoscaler que atinge o limite de uma cota regional está funcionalmente fora do ar.

Trade-offs:

• A replicação entre zonas (cross-zone) reduz o tempo de inatividade, mas adiciona tráfego e custo entre zonas.
• Designs entre regiões (cross-region) reduzem o RTO, mas aumentam a latência, a complexidade e os gastos.
• O balanceamento de carga anycast global simplifica o failover, mas mascara back-ends não íntegros apenas se as verificações de integridade (health checks) forem precisas.

Objetivos, Mapeamento de Dependências e Validação de DR

• RTO e RPO:
  • Recovery Time Objective (RTO): tempo alvo para restaurar o serviço. Impulsiona a profundidade da automação, a postura de standby e os detalhes do runbook.
  • Recovery Point Objective (RPO): janela de perda de dados aceitável. Impulsiona a escolha da replicação e da cadência de backup.
• Criticidade e classificação de serviços (tiering):
  • Defina níveis (tiers) (por exemplo, Tier 0: impacto na segurança/financeiro; Tier 1: receita; Tier 2: ferramentas internas) com SLOs, RTO/RPO e frequência de testes alvo.
  • Vincule os gastos e a complexidade ao nível (tier); nem todo serviço precisa ser inter-regional (cross-region).
• Mapeamento de dependências:
  • Faça um inventário das dependências upstream e downstream: identidade (Cloud IAM, SAML IdP), segredos (Secret Manager, KMS), rede (DNS, Cloud Interconnect/VPN), armazenamento e bancos de dados, observabilidade, CI/CD e APIs de terceiros.
  • Documente a região, a zona e o SLA para cada dependência; defina controles compensatórios para os elos mais fracos.
• Planos de recuperação:
  • Crie runbooks e automação para failover/failback, restaurações de dados e promoção de configuração (DNS, back-ends do balanceador de carga, firewall).
  • Pré-provisione permissões e contas de serviço; prepare as definições de infraestrutura para eliminar barreiras manuais.
  • Mantenha um acesso de emergência (break-glass) com elevação auditável.
• Teste de recuperação:
  • Agende failovers de rotina para sistemas com estado (stateful) (por exemplo, Cloud SQL HA) para validar a promoção e a renegociação da conexão.
  • Realize game days que simulem uma interrupção zonal ou regional; inclua provedores upstream e falhas de IAM/KMS.
  • Use injeção de falhas para validar circuit breakers, timeouts e novas tentativas (retries); verifique se o autoescalonamento e o backpressure funcionam como o esperado.
  • Meça continuamente o RTO/RPO durante os testes; ajuste a arquitetura quando os objetivos não forem alcançados.

Padrões de Computação, Bancos de Dados e Armazenamento Resilientes

• Computação com autorrecuperação com MIGs regionais e balanceamento de carga:
  • Use MIGs regionais para distribuir instâncias entre zonas com autoscaling e autorrecuperação.
  • Use um balanceador de carga HTTP(S) externo global como front-end e uma verificação de integridade (health check) do serviço de backend alinhada à prontidão real (por exemplo, /healthz verifica as dependências).
  • Permita que as verificações de integridade passem pelos firewalls para evitar a reciclagem 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
    ```

  - Evite estado local; externalize as sessões para o Memorystore ou bancos de dados; use o esgotamento de conexão (connection draining) nos backends para preservar as solicitações em trânsito durante o scale-in.
  - Modos de falha comuns: verificações de integridade desalinhadas (verificando demais ou de menos), regras de firewall ausentes e bootstrapping que depende de serviços downstream com falha.
- Resiliência do Cloud SQL:
  - Alta disponibilidade: primário e standby em zonas separadas com replicação síncrona de disco e failover automático; selecione uma janela de manutenção e teste os failovers.
  - Réplicas de leitura: adicione réplicas de leitura na mesma região ou entre regiões para descarregar as leituras e reduzir o RTO para eventos regionais; promova as réplicas durante a DR (recuperação de desastres).
  - Backups e PITR:
    - Habilite backups diários automatizados e recuperação point-in-time (PITR) por meio de logs binários/de transação com retenção suficiente para conformidade e RPO.
    - Valide as restaurações em ambientes de não produção e ensaie os procedimentos de promoção e as atualizações da string de conexão da aplicação.
  - Rede: prefira IP privado para produção; garanta que os testes de failover validem o comportamento do DNS/pool de conexões.
  - Dica operacional: execute periodicamente um failover controlado para verificar se os pools da aplicação se reconectam corretamente.

gcloud sql instances failover prod-sql
```

• Configuração e resiliência do Spanner:
  • Instâncias regionais fornecem leituras/escritas de baixa latência e com consistência forte dentro de uma região usando Paxos entre zonas.
  • Instâncias multirregionais replicam entre regiões com escritas de quórum síncronas (consistência forte global) e réplicas somente leitura opcionais; escolha uma região líder próxima aos gravadores (writers).
  • Trade-offs: a configuração multirregional melhora o RTO/RPO e a disponibilidade de leitura, mas aumenta a latência de escrita e o custo. Use para cargas de trabalho distribuídas globalmente e com escrita intensiva que necessitam de consistência forte; caso contrário, considere o Spanner regional ou o Cloud SQL com réplicas.
• Padrões de durabilidade e recuperação do Cloud Storage:
  • Estratégia de localização: regional para localidade de computação, dual-region para arquitetura ativo-ativo entre duas regiões, multirregional para ampla disponibilidade para usuários globais.
  • Versionamento: habilite o versionamento de objetos para se recuperar de exclusões ou corrupções; combine com regras de ciclo de vida para gerenciar custos.
  • Retenção: aplique políticas de retenção no nível do bucket e, se necessário, bloqueios de retenção (retention locks) para conformidade; use retenções baseadas em eventos (event-based holds) para gerenciamento de registros.
  • Padrões de backup: buckets em projetos diferentes e com administração separada mitigam exclusões acidentais e escalonamento de privilégios. Para bancos de dados, exporte backups lógicos para o Cloud Storage em um projeto distinto.
  • Exemplo de regra de ciclo de vida para excluir versões com mais de 90 dias:

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

    Aplique com:

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

• Recuperação: mantenha catálogos de objetos críticos e teste as restaurações; para grandes conjuntos de dados, prepare as restaurações em buckets temporários para evitar colisões de nome e validar a integridade.

← Segurança · Todos os domínios · Migração →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →

Navegar Google →