Google PCD: Arquitetura de Aplicações Nativas da Nuvem e Seleção de Serviços — Guia de estudos

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

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

Padrões de Fronteiras, Compatibilidade e Confiabilidade

• Fronteiras de domínio e propriedade

  • Use o design orientado a domínio (domain-driven design) para definir contextos delimitados. Cada serviço é dono de seus próprios dados e publica APIs/eventos como contratos.
  • Evite bancos de dados compartilhados entre serviços; use interfaces bem definidas e propagação de eventos.
  • A propriedade implica em sobreaviso (on-call), SLOs, cadência de releases e responsabilidade pelo orçamento por serviço.

• Contratos de API e retrocompatibilidade

  • Versione as APIs explicitamente (ex: v1 no caminho ou no cabeçalho). Prefira mudanças aditivas; evite quebrar campos ou comportamentos.
  • Use testes de contrato orientados ao consumidor (consumer-driven contract tests) e canary releases. Deprecie com cronogramas e telemetria de uso.
  • Para clientes móveis, espere versões de cauda longa; mantenha múltiplas versões da API simultaneamente.

• Isolamento de falhas e resiliência

  • Bulkheads: Isole recursos por serviço ou classe de prioridade (pools de nós, grupos de instâncias, cotas separados). Evite que uma funcionalidade best-effort esgote os recursos dos caminhos críticos.
  • Circuit breakers: Dispare após falhas consecutivas em uma dependência; alivie a carga e permita uma janela de recuperação. Implemente via service mesh (ex: Envoy), políticas de gateway ou bibliotecas.
  • Timeouts e retentativas: Use exponential backoff truncado com jitter; garanta que os handlers sejam idempotentes.
  • Degradação graciosa: Omita componentes de UI não críticos em caso de timeouts; sirva dados em cache ou aproximados em vez de erros.
  • Verificações de saúde (health checks) e sondas de prontidão (readiness probes): Roteie tráfego apenas para instâncias prontas; use liveness para autorrecuperação.

Exemplo de exponential backoff truncado (HTTP 429): retry = 0 max_retry = 5 base = 0.5 while retry < max_retry: resp = fetch_gcs_object() if resp.status_code == 200: break if resp.status_code in (429, 500, 503): sleep = min(8, base * (2 ** retry)) + random.uniform(0, 0.25) time.sleep(sleep) retry += 1 else: raise Exception(“Erro não passível de retentativa”)

Considerações Globais e Operacionais

• Padrões multirregionais para usuários globais

  • Front-end global: Use o balanceamento de carga HTTP(S) externo e global com IP anycast e Cloud CDN para conteúdo estático. Configure o cache negativo e a validação para reduzir a carga na origem.
  • Plano de dados:
    • Para disponibilidade de banco de dados de 5 noves e latência de leitura global minimizada, use uma instância multirregional do Cloud Spanner (ex: nam-asia-eur1) e provisione nós suficientes para computação e quórum (mínimo de três nós para produção).
    • Para padrões com uso intenso de leitura sem consistência global estrita, considere uma região primária com réplicas de leitura entre regiões; aceite maior latência de escrita entre continentes.
  • Plano de aplicação:
    • Implante serviços stateless em múltiplas regiões com autoescalonamento (GKE ou Cloud Run). Use serviços de backend e grupos de endpoints de rede por região.
    • Roteie por latência, respeitando as restrições de residência de dados e conformidade.
  • Caches: Posicione o Memorystore ou caches de borda perto dos usuários para absorver o tráfego de leitura e proteger as origens.

• Gerenciado vs. autogerenciado

  • Use o Cloud Monitoring para métricas, o Cloud Logging para logs, e o Cloud Trace/Profiler para latência e pontos de acesso de CPU/memória. Crie políticas de alerta para taxas de queima de SLO e verificações de tempo de atividade (uptime checks) para disponibilidade externa.
  • Se uma plataforma de observabilidade existente precisar continuar sendo o sistema de registro (system of record), ingira os dados primeiro com o Cloud Logging para alertas de baixa latência e, em seguida, exporte via sinks para a plataforma externa.

• Modernização e migração incremental

  • Padrão Strangler: Coloque um gateway na frente do monólito; roteie endpoints específicos para novos serviços. Substitua as funcionalidades gradualmente.
  • Branch by abstraction: Introduza uma interface em torno de uma dependência e troque a implementação por trás dela (ex: banco de dados ou armazenamento).
  • Camada anticorrupção: Traduza entre modelos de dados legados e novos contextos delimitados (bounded contexts).
  • Migração de dados: Use gravações duplas com verificação ou event sourcing para preencher dados retroativamente (backfill); planeje as transições (cutovers) com controles de contrapressão (backpressure).
  • Entrega em fases: Substitua funcionalidades em estágios para minimizar o risco de negócio; meça continuamente os SLOs.

• Revisões de design e avaliação de trade-offs

  • Segurança: Modelagem de ameaças, princípio do menor privilégio no IAM, contas de serviço em vez de chaves incorporadas (use Application Default Credentials no GCE/GKE/Cloud Run), CMEK onde necessário, conectividade privada, WAF e limites de taxa (rate limits), verificação de vulnerabilidades e de segurança da web.
  • Confiabilidade: Defina SLOs e orçamentos de erro, planos de failover multirregionais, capacidade de reserva (headroom), exercícios de caos (chaos drills), mapas de dependência.
  • Performance: Análise de latência de cauda (tail latency), testes de carga na borda e na origem, reutilização de conexão (HTTP/2, gRPC), compressão, estratégia de cache.
  • Custo: Dimensionar recursos corretamente (right-sizing), políticas de autoescalonamento, descontos por uso contínuo, escalar para zero para cargas de trabalho intermitentes, redução de custos de egress com CDN.
  • Operações: Runbooks, rollbacks, entrega progressiva (canary, blue/green), política como código, backups e testes de DR, integração da resposta a incidentes.

Cenário de Problema Prático

A Nimbus Retail está lançando uma plataforma global de e-commerce com imagens personalizadas, metas rígidas de latência abaixo de 200 ms no p95 em todo o mundo e um requisito de disponibilidade de 99,999% para o banco de dados de pedidos. Eles também precisam manter seu SIEM existente enquanto melhoram a velocidade dos alertas.

1. Estabelecer um banco de dados global e de alta disponibilidade usando o Cloud Spanner

• Ação: Criar uma instância multirregional do Spanner em nam-asia-eur1 com pelo menos três nós e dividir as tabelas em esquemas intercalados (interleaved) apropriados para localidade.
• Justificativa: O Spanner multirregional oferece 5 noves de disponibilidade e baixa latência de leitura por meio de réplicas em três continentes; três ou mais nós garantem capacidade de computação e de quórum de réplicas suficientes.

Exemplo: gcloud spanner instances create nimbus-orders
–config=nam-asia-eur1 –description=“Pedidos globais” –nodes=3

2. Implantação global do frontend e da API

• Ação: Usar o balanceamento de carga HTTP(S) externo e global com Cloud CDN para ativos estáticos e roteamento dinâmico para backends regionais (serviços GKE em us-central1, europe-west1, asia-east1).
• Justificativa: O VIP Anycast minimiza o RTT; o CDN armazena imagens em cache perto dos usuários; os serviços de backend distribuem as solicitações para a região íntegra mais próxima.

3. Serviços stateless no GKE com descoberta dentro do cluster

• Ação: Implantar os serviços de redimensionamento de imagem e de API no GKE com Horizontal Pod Autoscaling e ClusterIP Services para acesso baseado em nome dentro do cluster; expor endpoints públicos por meio de um Ingress.
• Justificativa: Pods stateless permitem escalonamento elástico; o Kubernetes Service abstrai os IPs dos pods e fornece DNS estável, reduzindo o acoplamento do cliente.

4. Processamento de imagens orientado a eventos

• Ação: Publicar tarefas de processamento de imagem no Pub/Sub; executar serviços do Cloud Run inscritos via push para processar objetos armazenados no Cloud Storage. Implementar backoff exponencial truncado com jitter em erros 429/5xx do GCS.
• Justificativa: O Pub/Sub absorve picos de tráfego e isola falhas; o Cloud Run escala por mensagem; o backoff reduz a amplificação de erros e ajuda no aquecimento gradual dos buckets.

5. Observabilidade e alertas rápidos

• Ação: Usar o Cloud Logging e o Cloud Monitoring para ingerir logs e métricas, definir verificações de tempo de atividade (uptime checks) para as APIs e criar políticas de alerta sobre taxas de erro e latência. Configurar um log sink para exportar para o SIEM existente.
• Justificativa: A telemetria nativa fornece alertas de baixa latência e verificações de tempo de atividade gerenciadas; a exportação preserva o SIEM centralizado sem sacrificar a velocidade dos alertas.

6. Configuração e segredos externalizados

• Ação: Armazenar configurações não secretas em ConfigMaps; segredos e chaves de API no Secret Manager com Workload Identity para GKE. Para quaisquer jobs baseados no Compute Engine, usar metadados da instância para valores por implantação.
• Justificativa: A configuração externalizada permite imagens imutáveis e configurações específicas do ambiente; evita incorporar segredos; os metadados suportam variações de VM sem alterações no código.

7. Isolamento de falhas e degradação graciosa

• Ação: Aplicar bulkheads com pools de nós separados para cargas de trabalho de personalização de melhor esforço (best-effort); impor orçamentos de requisição e circuit breakers para os serviços de personalização. Na UI, omitir widgets não críticos em timeouts de dependência.
• Justificativa: Isolar a capacidade impede que funcionalidades de melhor esforço (best-effort) sufoquem o checkout; circuit breakers limitam o raio de alcance da falha (blast radius); a degradação graciosa preserva as jornadas principais.

8. Contratos de API e compatibilidade

• Ação: Definir contratos gRPC para clientes móveis (v1) com transcodificação para HTTP/JSON para a web; adotar mudanças aditivas e manter pelo menos duas versões durante o lançamento para dispositivos móveis.
• Justificativa: O gRPC reduz o consumo de banda e fornece tipagem forte; a transcodificação facilita a integração com navegadores e parceiros; o versionamento preserva a retrocompatibilidade.

9. Segurança e identidade

• Ação: Usar contas de serviço do Google por serviço (per-service) com o princípio do menor privilégio no IAM; depender do Application Default Credentials. Habilitar o Cloud Armor para proteções de borda e impor TLS em todos os lugares.
• Justificativa: O Workload Identity remove os riscos de gerenciamento de chaves; WAF e limites de taxa mitigam abusos; a criptografia em trânsito é padrão e obrigatória.

10. Entrega contínua e segurança no lançamento

• Ação: Implementar lançamentos canary com divisão de tráfego baseada em porcentagem no balanceador de carga e rollback automático em alertas de queima de SLO. Manter ambientes blue/green por região.
• Justificativa: A entrega progressiva limita o risco; o blue/green regional acelera o rollback e permite migrações de esquema seguras, alinhadas com as APIs versionadas.

Todos os domínios · Computação →

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

Navegar Google →