Google PCA: Computação, Plataformas de Aplicação e Arquitetura de Cargas de Trabalho — 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

Este domínio abrange como selecionar e projetar plataformas de computação no Google Cloud, como empacotar e implantar aplicações e como operar cargas de trabalho para confiabilidade, desempenho, segurança e eficiência de custo. Ele abrange máquinas virtuais, Kubernetes, runtimes serverless, balanceamento de carga, estratégias de rollout, computação com estado (stateful) e especializada, e padrões de modernização que reduzem a dívida técnica enquanto atendem à demanda variável.

Compute Engine e Arquiteturas Baseadas em VM

O Compute Engine oferece controle granular sobre sistemas operacionais, redes e formatos de máquina. Escolha famílias de máquinas com base nas características da carga de trabalho:

E2: otimizada para custos e de uso geral; boa para dev/test, aplicações com picos de uso (bursty).
N2/N2D: preço/desempenho balanceado para a maioria das cargas de trabalho de produção; a N2D usa CPUs AMD com forte largura de banda de memória.
C2/C2D/C3: otimizada para computação para tarefas intensivas em CPU (ex: APIs com alto QPS, computação em lote).
M3: otimizada para memória para grandes conjuntos de dados em memória (caches, análise em memória).
A3: otimizada para GPU (NVIDIA) para treinamento/inferência; também é possível anexar GPUs a outras famílias.
Confidential VMs (em CPUs compatíveis) criptografam dados em uso com alterações mínimas no código.

Grupos de instâncias gerenciadas (MIGs) trazem elasticidade e resiliência:

Use Instance Templates para configuração imutável e MIGs para escalar horizontalmente entre zonas.
Políticas de autoscaling: CPU, utilização do balanceador de carga, métricas do Cloud Monitoring ou profundidade da fila por meio de métricas personalizadas. Defina réplicas mínimas/máximas e cooldown para evitar instabilidade (thrash) sob cargas com picos.
Atualizações contínuas (rolling updates) e canaries reduzem o risco; mantenha as configurações de surge e unavailable conservadoras para serviços com estado (stateful) ou com inicialização a frio (cold-start) pesada.

Balanceamento de carga e verificações de integridade (health checks):

O Global external HTTP(S) load balancer termina o TLS, suporta mapeamento de URL e é o front-end padrão para APIs web; o internal HTTP(S) LB é para tráfego leste-oeste (east-west).
As verificações de integridade devem alcançar os backends. Uma falha comum são sondas (probes) bloqueadas, causando reinicializações perpétuas de instâncias e queda de tráfego. Permita os intervalos de origem da verificação de integridade para as portas do backend com regras de firewall da VPC e tags de destino.

Exemplo para permitir verificações de integridade HTTP para um MIG:

gcloud compute firewall-rules create allow-lb-health-checks –network=my-net –direction=INGRESS –action=ALLOW –rules=tcp:80 –source-ranges=35.191.0.0/16,130.211.0.0/22 –target-tags=web-backend

Considerações sobre o ciclo de vida da VM:

Use scripts de inicialização (startup scripts) ou metadados da imagem para o bootstrap; armazene a configuração de tempo de execução no Secret Manager, não embutida (baked) nas imagens.
Para VMs preemptible/Spot, adicione um shutdown-script para drenar o trabalho ao receber o aviso de encerramento.
Aplique patches por meio de imagens pré-configuradas (baked images) e substituição contínua (rolling replacement) para evitar desvio de configuração (configuration drift).
O redimensionamento do Persistent Disk é online: aumente o tamanho do disco e, em seguida, expanda o sistema de arquivos (ex: resize2fs em ext4) com tempo de inatividade mínimo.

Exemplo de redimensionamento de PD:

gcloud compute disks resize my-disk –size=500GB –zone=us-central1-a
sudo resize2fs /dev/sdb

Identidade segura e observabilidade:

Anexe service accounts com privilégio mínimo (least-privilege) às instâncias; não incorpore credenciais estáticas.
Instale o Ops Agent para o Cloud Logging e o Cloud Monitoring. Use o Cloud Trace e o Cloud Profiler para reduzir a latência de cauda (tail latency) e os pontos de acesso intenso (hot spots).
Exporte dados de auditoria e métricas para o BigQuery ou Cloud Storage para retenção e análise de longo prazo.

Computação em lote e especializada:

Use o Cloud Batch ou MIGs com VMs preemptible para processamento em lote tolerante a falhas para reduzir custos; implemente checkpointing.
Anexe GPUs/TPUs onde a aceleração de ML for necessária. Use node pools dedicados ou sole-tenant nodes para atender a requisitos de conformidade/isolamento.
As Confidential VMs protegem dados sensíveis em memória; meça a sobrecarga (overhead) em relação aos requisitos.

Considerações sobre estado:

Mantenha as instâncias da aplicação sem estado (stateless); externalize as sessões para um armazenamento compartilhado (ex: Memorystore, Cloud SQL) para evitar anomalias visíveis ao usuário durante o escalonamento.
Para estado vinculado à VM, use persistent disks regionais ou bancos de dados replicados; teste os caminhos de failover.

Kubernetes e Plataformas de Contêineres (GKE)

O GKE fornece um plano de controle gerenciado com pools de nós de trabalho (worker nodes) flexíveis:

Clusters regionais replicam o plano de controle e os nós entre zonas para alta disponibilidade; clusters zonais concentram recursos para menor custo e sensibilidade à latência.
Use múltiplos pools de nós para segmentar cargas de trabalho (ex: uso geral, GPU, alta memória, spot). Aplique taints/tolerations e affinity/anti-affinity para controlar o posicionamento e reduzir os efeitos de “vizinho barulhento” (noisy-neighbor).
Camadas de autoscaling: o cluster autoscaler adiciona/remove nós; o Horizontal Pod Autoscaler (HPA) dimensiona as réplicas com base em métricas de CPU/personalizadas; o Vertical Pod Autoscaler (VPA) ajusta o tamanho das solicitações (requests). Combine o HPA com o cluster autoscaler para obter elasticidade.

Agendamento de cargas de trabalho e serviços:

Dimensione corretamente as solicitações/limites (requests/limits) de CPU/memória para minimizar o risco de evicção e maximizar a eficiência do empacotamento (binpacking).
Use PodDisruptionBudgets para preservar a disponibilidade durante as atualizações.
Tipos de Service: ClusterIP (dentro do cluster), NodePort/LoadBalancer (norte-sul) e Ingress para roteamento HTTP(S) com o LB global. Para canaries, direcione o tráfego por meio de Services/backends de Ingress separados ou uma malha de serviço (service mesh).

Atualizações e resiliência:

Use atualizações do tipo surge e maxUnavailable para controlar a rotatividade (churn); fixe cargas de trabalho críticas em múltiplas zonas e pools.
Defina janelas/exclusões de manutenção para períodos críticos de negócio.
Valide com um ambiente de pré-produção e pools de nós canary antes de uma implantação ampla.

Imagens e segurança:

Armazene imagens de contêiner no Artifact Registry; habilite a verificação de vulnerabilidades e configure a autorização binária (binary authorization) ou atestados (attestations) para proveniência.
Use o Workload Identity para mapear GSA para KSA para acesso sem credenciais e com privilégio mínimo às APIs do Google.
Busque a configuração de tempo de execução do Secret Manager via driver CSI; evite Kubernetes Secrets para valores altamente sensíveis, a menos que criptografados com CMEK e com RBAC restrito.

Implantações (rollouts) e reversão (rollback):

Prefira atualizações contínuas (rolling updates) de Deployments com passos pequenos e sondas de saúde (health probes); para sistemas de baixa tolerância, use blue-green por meio de dois Deployments atrás de um único Service e alterne os labels/selector.
Sempre defina sondas de prontidão (readiness) e atividade (liveness); sondas mal configuradas causam reinicializações em cascata ou blackholes durante as implantações.

Plataformas Serverless e Orientadas a Eventos

O serverless do Google Cloud abstrai a infraestrutura ao mesmo tempo que fornece controles robustos sobre escala, segurança e custo:

Cloud Run: nativo para contêineres, acionado por requisições HTTP ou pelo Eventarc. Escala até zero; concorrência configurável; divisão de tráfego por revisão para canary e rollback. Defina um número mínimo de instâncias (min instances) para reduzir cold starts em endpoints sensíveis à latência. Integre com a VPC via Serverless VPC Access para saída (egress) privada.
App Engine: PaaS opinativo. O ambiente Standard oferece escalonamento rápido e restrições de concorrência por requisição por linguagem; o ambiente Flexible executa contêineres em VMs com mais controle. Evite estado de sessão local à instância; externalize para um armazenamento compartilhado para prevenir experiências de usuário obsoletas ou duplicadas sob carga.
Cloud Functions: granularidade no nível de função para lógica orientada a eventos. Use gatilhos (triggers) do Pub/Sub, Cloud Storage ou Eventarc para micro-operações leves; mantenha as funções idempotentes e sem estado (stateless). Para pipelines combinados de lote/streaming sem código existente, o Dataflow fornece processamento unificado com autoscaling.

Trade-offs na seleção da plataforma:

Controle operacional: Compute Engine > GKE > Cloud Run/App Engine > Cloud Functions.
Portabilidade: baseada em contêineres (GKE/Cloud Run/App Engine Flex) > imagens de VM > funções e App Engine Standard.
Latência: Cloud Run com instâncias mínimas (min instances) ou GKE para baixa latência de cauda (tail latency); evite cold starts para cargas de trabalho interativas.
Escalonamento: Cloud Functions/Run escalam mais rápido; HPA do GKE mais cluster autoscaler; MIGs exigem aquecimento (warm-up) e verificações de saúde (health checks).
Custo: serverless com pagamento por uso (pay-per-use) para picos/baixo estado estacionário; GKE/VMs com descontos por uso contínuo (committed use discounts) para serviços estáveis e de alta vazão; preemptible/Spot para processamento em lote (batch).

Identidade e configuração:

Cada serviço deve usar uma conta de serviço (service account) dedicada com o mínimo de privilégios. Para Cloud Run e Functions, defina a conta de serviço de tempo de execução explicitamente.
Armazene segredos no Secret Manager e vincule o acesso via IAM; injete por meio de variáveis de ambiente ou montagens de volume.

Padrões de Arquitetura, Entrega e Operações

Decomposição e limites de serviços:

Monólito (Monolith): implantação e transações mais simples, mas limita o escalonamento independente e o controle do raio de impacto (blast-radius); pode mascarar problemas de desempenho em partes profundas das cadeias de chamadas.
Monólito modular (Modular monolith): módulos internos claros, processo compartilhado; um bom passo intermediário — impõe o uso de interfaces sem as penalidades da distribuição.
Microsserviços (Microservices): capacidade de implantação e escalonamento independentes; introduz latência de rede, transações distribuídas e desafios de consistência. Defina contextos delimitados (bounded contexts) e propriedade de dados claros; evite bancos de dados compartilhados para prevenir o acoplamento.

Padrões de modernização:

Strangler-fig: roteie incrementalmente uma parte do tráfego para novos componentes, desative os endpoints legados gradualmente.
Lift and shift: primeiro, containerize ou migre para VMs para estabilizar e, em seguida, refatore.
Camada anticorrupção/fachada (Anti-corruption layer/facade): isole os contratos legados enquanto constrói novos serviços.
Priorize primeiro os domínios de alta mudança e alto atrito para maximizar o valor de negócio e reduzir o risco.

Entrega e implantações (rollouts):

CI/CD com testes automatizados e ambientes de homologação (staged environments) reduz a necessidade de reversões (rollbacks). Adicione análise canário (canary analysis), orçamentos de erro (error budgets) e entrega progressiva.
Blue-green minimiza o tempo de inatividade (downtime) e simplifica a reversão (rollback) ao custo de duplicar a capacidade.
Divisão de tráfego (Traffic splitting): O Cloud Run/App Engine suporta roteamento baseado em porcentagem entre revisões/versões; teste sob tráfego real com orçamentos de erro de SLO (SLO error budgets) rigorosos.

Balanceamento de carga e saúde (health):

Use L7 global para HTTP e proxy TCP para protocolos não-HTTP; LBs internos para serviços privados. Configure a afinidade de sessão (session affinity) apenas quando necessário e externalize o estado da sessão.
As verificações de saúde (health checks) devem refletir a disponibilidade da aplicação (ex: saúde das dependências); um simples 200 OK que mascara uma falha no datastore pode causar um direcionamento de tráfego incorreto.

Observabilidade e governança:

Instrumente traces para atribuição de latência de ponta a ponta entre os serviços; habilite o registro de IDs de requisição (request IDs) para correlacionar logs e traces.
Exporte logs/métricas/trilhas de auditoria para o BigQuery ou Cloud Storage para necessidades de retenção e auditoria; proteja o acesso por meio de views e do IAM.
Para logs de VMs, instale o Ops Agent; defina a retenção e os coletores (sinks) para controlar custos e conformidade.

Cadeia de suprimentos de software segura (Secure software supply chain):

Use o Artifact Registry com verificação de vulnerabilidades (scanning); mantenha as imagens mínimas. Otimize os Dockerfiles: prefira imagens base ‘slim’, instale as dependências primeiro e depois copie o código-fonte para aproveitar o cache de build.

Rede e segmentação:

Imponha o acesso em camadas por meio de tags e regras de firewall da VPC para permitir apenas os fluxos esperados (ex: web → API → BD). Negue o acesso direto de web → BD.

Capacidade, Desempenho e Computação Especializada

Projetar para demanda variável:

GCE: escalone automaticamente (autoscale) MIGs com base em indicadores preditivos (tamanho da fila) para se antecipar à saturação de CPU; adicione limitação de taxa de requisições e contrapressão (backpressure) para proteger os serviços downstream.
GKE: combine o HPA com base em requisições por segundo ou métricas personalizadas e o cluster autoscaler; provisione um pequeno buffer para evitar atrasos no escalonamento.
Serverless: ajuste a simultaneidade (concurrency) e o número mínimo de instâncias (min instances) para equilibrar custo versus latência; use implantação regional para latência próxima ao usuário.

Resiliência e testes:

Execute cargas sintéticas para validar o autoscaling e os SLOs; inclua testes de caos (por exemplo, encerrar instâncias/pods aleatórios) para garantir que o sistema mantenha a disponibilidade durante falhas e atualizações.
Configure PodDisruptionBudgets e hooks de encerramento gradual (graceful termination) para drenar conexões antes do desligamento de pods/VMs.

Desempenho e seleção de armazenamento:

A ingestão de séries temporais e clickstream de alta vazão e baixa latência se encaixa bem no Bigtable; projete linhas largas e chaves agrupadas por tempo (time-bucketed) para evitar hotspots.
Para Spark/Hadoop com mínimas mudanças operacionais, use o Dataproc; dimensione corretamente os clusters com autoscaling.
Para combinar processamento em lote (batch) por hora e streaming sem código existente, use o Dataflow com autoscaling e janelamento (windowing) para unificar os pipelines.

Movimentação e conectividade de dados:

Para replicação privada, sustentada e de alta largura de banda (por exemplo, bancos de dados de múltiplos terabytes), considere o Dedicated Interconnect; use anexos de VLAN (VLAN attachments) e o Cloud Router para roteamento dinâmico. Para uso ad hoc ou de menor vazão, o Cloud VPN é suficiente.

Cargas de trabalho com estado (stateful):

No GKE, use StatefulSets com volumes persistentes (PDs regionais para alta disponibilidade - HA) e identidades ordenadas e estáveis; considere o Filestore para semântica NFS.
Use bancos de dados gerenciados (Cloud SQL, AlloyDB, Spanner) para durabilidade e escalonamento sempre que possível; planeje réplicas de leitura e failover.

Segurança e conformidade:

Considere Confidential VMs para proteger dados em uso com sobrecarga de desempenho limitada; avalie em relação aos requisitos da carga de trabalho.
Use CMEK onde as chaves devem ser controladas pelo cliente; imponha o isolamento por ambiente e separe projetos para dev/test/prod.

Controles de custo:

Use descontos por uso comprometido (committed use) e por uso prolongado (sustained use) para computação em estado de equilíbrio (steady-state); use instâncias preemptivas/Spot para processamento em lote tolerante a falhas; use autoscaling para zero em serverless.
Dimensione os recursos corretamente com as recomendações do Monitoring; remova serviços ociosos e defina cotas para métricas baseadas em logs para evitar surpresas com custos.

Solução de problemas de latência:

Use o Cloud Trace para identificar o microsserviço que adiciona mais latência; otimize o caminho do código (code path), o cache ou os índices do banco de dados desse serviço. Valide as melhorias com canaries A/B.

Cenário de Problema Prático

A FerroLine Logistics planeja modernizar um monólito J2EE que lida com rastreamento de remessas e notificações a clientes. A carga de trabalho tem picos (é “bursty”) durante os horários de corte regionais, deve atender a uma meta de disponibilidade de 99,9% e a equipe deseja portabilidade com mínimo esforço operacional (toil), ao mesmo tempo em que introduz funcionalidades orientadas a eventos.

Estabilizar e observar o sistema atual

Justificativa: Antes de fazer alterações, estabeleça uma linha de base (baseline) do comportamento e dos erros para reduzir o risco de rollback. Implante o Ops Agent nas VMs existentes para o Cloud Logging e o Monitoring, e instrumente o rastreamento distribuído (distributed tracing) nos caminhos de requisição de alta latência. Exporte logs e métricas para o BigQuery para análise histórica e relatórios de SLO.

Escolher uma landing zone e um mix de plataformas em estágios

Justificativa: Equilibrar controle e velocidade. Migre o monólito como um contêiner para Cloud Run jobs para os componentes em lote (batch) e para serviços do Cloud Run para as APIs HTTP sem estado (stateless), definindo um número mínimo de instâncias (min instances) para endpoints críticos em termos de latência. Mantenha o banco de dados Oracle com estado (stateful) no Compute Engine inicialmente, precedido por um LB HTTP(S) interno regional para APIs internas, e planeje uma futura migração para o AlloyDB.

Externalizar o estado de sessão e configuração

Justificativa: Evitar problemas de sessão local na instância e permitir o autoscaling seguro. Armazene segredos no Secret Manager com contas de serviço por serviço para acesso com privilégio mínimo. Mova o estado da sessão para o Memorystore e arquivos compartilhados para o Cloud Storage. Isso evita que os usuários vejam dados obsoletos sob carga de pico.

Estabelecer controles de identidade e de registro (registry)

Justificativa: Impor o princípio do menor privilégio e a proveniência. Armazene imagens no Artifact Registry com a verificação de vulnerabilidades ativada. Atribua uma conta de serviço de tempo de execução (runtime) exclusiva para cada serviço do Cloud Run e carga de trabalho do GKE (para componentes decompostos posteriormente) e conceda apenas os papéis necessários (por exemplo, Pub/Sub Publisher).

Implementar CI/CD com estratégias de implantação (rollout) seguras

Justificativa: Reduzir rollbacks não planejados. Construa um pipeline que execute testes de unidade/integração e implante em um ambiente de homologação (staging). Use a divisão de tráfego (traffic splitting) do Cloud Run para fazer o canary de 5 a 10% do tráfego para novas revisões e permitir um rollback rápido. Para as alterações no banco de dados baseado em VM, use padrões de migração de esquema blue-green para desacoplar as implantações da aplicação e do banco de dados.

Decompor primeiro os domínios de alta mudança

Justificativa: Valor incremental com menor risco. Aplique o padrão Strangler (Strangler Fig Pattern): separe a entrega de notificações como um microsserviço no GKE para aproveitar o HPA para picos e o Pub/Sub para desacoplamento. Mantenha o restante do monólito como um monólito modular no Cloud Run enquanto as interfaces se estabilizam.

Projetar autoscaling e descarte de carga (load shedding)

Justificativa: Lidar com picos sem causar falhas em cascata. Configure a simultaneidade (concurrency) e o número mínimo de instâncias (min instances) do Cloud Run por endpoint; defina limites de taxa no Cloud Armor no LB HTTP(S) global para proteger contra picos de tráfego não autenticado. Para serviços do GKE, habilite o HPA com base em métricas personalizadas (requisições por segundo) e provisione um pequeno buffer de nós através do cluster autoscaler.

Preparar serviços com estado (stateful) e caminhos de dados

Justificativa: Garantir durabilidade e desempenho. Para as tentativas de notificação no GKE, use uma tabela do Bigtable com chave por cliente-região e agrupamentos de tempo (time buckets) para armazenar o estado de entrega transitório com altas taxas de escrita. Para conectividade privada e consistente com o ERP on-premises durante a transição, use o Dedicated Interconnect com o Cloud Router.

Executar testes de resiliência e desempenho

Justificativa: Validar os SLOs antes da migração completa (cutover). Execute fluxos de usuário sintéticos e aleatórios para acionar as camadas de autoscaling. Injete caos encerrando instâncias aleatórias do Cloud Run (permitindo que o plano de controle as recrie) e removendo pods do GKE para verificar os PodDisruptionBudgets e os readiness gates. Use o Trace para identificar o maior contribuidor para a latência de cauda (tail latency) e corrigi-lo.

Operar com barreiras de proteção (guardrails) de custo e conformidade

Justificativa: Executar em produção de forma sustentável. Defina orçamentos e alertas por serviço, habilite o CMEK em armazenamento sensível onde necessário e use descontos por uso comprometido para os node pools do GKE e para o AlloyDB assim que o estado de equilíbrio (steady-state) for compreendido. Configure políticas de retenção de logs e visualizações (views) do BigQuery para compartilhar dados de auditoria com auditores internos de forma segura.

Essa abordagem em fases proporciona estabilidade e observabilidade imediatas, introduz práticas de implantação seguras, decompõe progressivamente o monólito ao longo de fronteiras de serviço naturais e alinha as escolhas de plataforma com os objetivos de controle, latência, portabilidade, escalonamento e custo.

← Design Organizacional · Todos os domínios · Armazenamento de Dados →

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