Google Cloud Professional Cloud Architect
Última revisão: maio de 2026
Uma referência rápida dos padrões arquiteturais que o exame PCA avalia. Leia de cima a baixo ou pule para uma seção.
Uma aplicação global requer baixa latência e alta disponibilidade para usuários em todo o mundo.
Use um Global HTTP(S) Load Balancer com backends multi-região (MIGs/GKE), Cloud CDN para conteúdo estático e Cloud Armor para proteção contra DDoS.
Por quê: O Global Load Balancer fornece um único IP anycast que roteia os usuários para o backend saudável mais próximo. O CDN armazena conteúdo em cache na borda, reduzindo a carga de origem e a latência.
Ingerir e processar dados de alta vazão e em tempo real de dispositivos IoT para análise imediata.
Use Pub/Sub para ingestão escalável de mensagens, um pipeline de streaming Dataflow para processamento em tempo real e detecção de anomalias, e grave os resultados no BigQuery para análises.
Por quê: Este é o padrão serverless canônico para dados em tempo real. O Pub/Sub desacopla a ingestão, o Dataflow lida com processamento complexo com autoescalabilidade, e o BigQuery suporta inserções de streaming para análises em tempo real.
Um backend de jogos precisa armazenar o estado do jogador e tabelas de classificação com latência de leitura submilissegundos e alta vazão.
Use Cloud Bigtable para estado do jogo/tabelas de classificação e Memorystore (Redis) para cache de sessão.
Por quê: O Bigtable oferece latência de milissegundos de dígito único para leituras/gravações de alta vazão, ideal para séries temporais ou grandes conjuntos de dados analíticos. O Memorystore oferece latência de microssegundos para o estado da sessão.
Uma aplicação distribuída globalmente requer um banco de dados com forte consistência transacional e escalabilidade horizontal.
Use Cloud Spanner com uma configuração multi-região.
Por quê: Spanner é o único serviço que oferece transações globais e fortemente consistentes com semântica SQL e escalabilidade horizontal. O Cloud SQL requer sharding manual para esta escala.
Migrar um banco de dados Oracle ou PostgreSQL on-premises exigente, que requer alta disponibilidade, desempenho e refatoração mínima.
Use AlloyDB for PostgreSQL.
Por quê: AlloyDB é um banco de dados totalmente gerenciado e compatível com PostgreSQL, com desempenho superior, 99.99% de disponibilidade e recursos de compatibilidade com Oracle, tornando-o ideal para migrações corporativas.
Conectar um data center on-premises ao GCP com requisitos consistentes de baixa latência (<10ms) e alta largura de banda (10+ Gbps).
Use Dedicated Interconnect com conexões redundantes.
Por quê: Dedicated Interconnect fornece uma conexão física privada, de alta largura de banda e baixa latência. O Cloud VPN funciona sobre a internet pública e não pode garantir SLAs de latência ou largura de banda a este nível.
Projetar uma rede para múltiplas equipes/projetos que requerem gerenciamento de rede centralizado, mas propriedade de projeto descentralizada.
Implemente um modelo hub-and-spoke usando um Shared VPC. A equipe de rede central gerencia o projeto host, e as equipes de aplicação usam projetos de serviço.
Por quê: Shared VPC permite controle centralizado sobre os recursos de rede (sub-redes, firewalls) enquanto delega o gerenciamento de recursos em projetos de serviço. Isso é mais escalável e seguro do que VPC peering.
Gerenciar clusters Kubernetes de forma consistente em ambientes Google Cloud, AWS, Azure e on-premises.
Use Anthos para fornecer um plano de controle unificado para gerenciamento de clusters multi-nuvem e híbridos, aplicação de políticas e observabilidade.
Por quê: Anthos estende o GKE para outros ambientes, permitindo operações consistentes e gerenciamento de configuração baseado em GitOps (Config Management) em toda a sua frota.
Uma equipe de ciência de dados precisa treinar modelos complexos de ML com aceleração por GPU sem gerenciar a infraestrutura.
Use Vertex AI Training com contêineres personalizados e Vertex AI Experiments para rastrear iterações de modelo.
Por quê: O Vertex AI oferece um serviço de treinamento totalmente gerenciado que lida com o provisionamento de infraestrutura, escalabilidade e gerenciamento de GPU. Ele se integra a experimentos para rastrear e comparar o desempenho do modelo.
Servir um grande modelo de ML com baixa latência e alta disponibilidade, capaz de autoescalar.
Use Vertex AI Prediction com um contêiner personalizado, implantado em um endpoint gerenciado com autoescalamento habilitado.
Por quê: O Vertex AI Prediction é otimizado para o serviço de modelos com baixa latência. Ele lida com autoescalamento, divisão de tráfego (para testes A/B) e gerenciamento de infraestrutura, abstraindo a complexidade dos desenvolvedores.
Um serviço Cloud Function ou Cloud Run precisa se conectar de forma segura a uma instância do Cloud SQL com um IP privado.
Configure um Serverless VPC Access Connector para interligar o ambiente serverless com sua VPC.
Por quê: O conector cria um túnel para sua VPC, permitindo que os serviços serverless acessem recursos internos por seus endereços IP privados sem expô-los à internet.
Migrar uma aplicação stateful que usa armazenamento de sessão local para uma plataforma stateless e autoescalável como Cloud Run ou GKE.
Externalize o estado da sessão para um armazenamento gerenciado em memória como Memorystore (Redis).
Por quê: A computação sem estado requer que os dados da sessão sejam armazenados externamente para que qualquer instância possa lidar com qualquer solicitação do usuário. O Memorystore fornece uma solução compartilhada e de baixa latência para isso.
Criar um pipeline de entrega contínua gerenciado para promover lançamentos entre múltiplos ambientes (staging, produção) com aprovações.
Use Cloud Deploy para definir um pipeline de entrega que orquestra implantações para ambientes de destino (GKE, Cloud Run) com portões de aprovação incorporados.
Por quê: O Cloud Deploy é um serviço totalmente gerenciado para CD, fornecendo gerenciamento de lançamentos, auditabilidade e recursos de rollback automatizados sem a sobrecarga operacional de hospedar ferramentas como Spinnaker.
Implantar uma aplicação conteinerizada em um cluster Kubernetes pronto para produção com mínima sobrecarga operacional e de gerenciamento.
Use um cluster GKE Autopilot.
Por quê: O Autopilot gerencia o plano de controle e os nós do cluster, incluindo provisionamento, escalabilidade e proteção de segurança. Você paga apenas pelos recursos de pod que solicita, simplificando as operações e o gerenciamento de custos.
Migrar incrementalmente uma aplicação monolítica grande para uma arquitetura de microsserviços com risco mínimo e tempo de inatividade.
Aplique o padrão Strangler Fig. Coloque um proxy na frente do monólito e redirecione gradualmente o tráfego para funcionalidades específicas para novos microsserviços à medida que são construídos e validados.
Por quê: Este padrão evita uma reescrita de "big bang" de alto risco, permitindo uma transição gradual e controlada. O monólito é lentamente "estrangulado" à medida que novos serviços assumem suas funcionalidades.
Migrar um grande número de VMs on-premises para o Google Cloud com tempo de inatividade mínimo.
Use Migrate to Virtual Machines (anteriormente Migrate for Compute Engine) para realizar replicação contínua em nível de bloco de on-premises para GCP, seguida por uma rápida transição.
Por quê: Esta ferramenta foi projetada para migrações "lift-and-shift", minimizando o tempo de inatividade para minutos, mantendo as VMs de origem e destino sincronizadas até a transição final.
Uma equipe está adotando os princípios de SRE e precisa estabelecer seus SLOs iniciais.
Defina primeiro Service Level Indicators (SLIs) centrados no usuário (por exemplo, disponibilidade, latência). Analise dados históricos de desempenho para definir Service Level Objectives (SLOs) iniciais realistas.
Por quê: Os SLOs devem ser baseados na experiência do usuário (SLIs) e ser alcançáveis. Defini-los com base em dados históricos garante que o orçamento de erros inicial seja realista e não seja violado imediatamente.
Automatizar a criação de novos projetos GCP com uma configuração padronizada (APIs, IAM, rede, segurança).
Use um padrão "Project Factory" com um módulo Terraform, acionado pelo Cloud Build. Use o Service Catalog para fornecer uma interface de autoatendimento.
Por quê: Isso garante que todos os novos projetos sigam os padrões organizacionais e as linhas de base de segurança, reduzindo o esforço manual e a deriva de configuração. Habilita a governança em escala.
Prevenir alterações manuais (desvio de configuração) na infraestrutura gerenciada pelo Terraform.
Use um pipeline de CI/CD (por exemplo, Cloud Build) para todas as aplicações, bloqueio de estado do Terraform (via backend GCS), Organization Policies para restringir ações do console e detecção regular de desvio.
Por quê: É necessária uma abordagem em várias camadas. O pipeline impõe um único caminho para as alterações, o bloqueio impede aplicações concorrentes e as Org Policies fornecem uma barreira preventiva.
Gerenciar código de infraestrutura (Terraform) para múltiplos ambientes (desenvolvimento, staging, produção) com módulos compartilhados, mas configurações diferentes.
Use um único conjunto de módulos Terraform reutilizáveis e forneça configurações específicas do ambiente por meio de arquivos `.tfvars` separados ou workspaces.
Por quê: Isso segue o princípio "Don't Repeat Yourself" (DRY). Os módulos garantem a consistência, enquanto os arquivos de variáveis oferecem a flexibilidade para adaptar cada ambiente.
Implementar um fluxo de trabalho GitOps para implantar automaticamente manifestos Kubernetes de um repositório Git para clusters GKE.
Use Anthos Config Management (ou o Config Sync standalone) para reconciliar continuamente o estado do cluster com a configuração em um repositório Git.
Por quê: O Config Sync fornece uma solução GitOps totalmente gerenciada que detecta e corrige o desvio de configuração, garantindo que o repositório Git seja a única fonte de verdade para o estado do cluster.
Implementar uma implantação azul-verde para uma aplicação web com zero tempo de inatividade e capacidade de rollback instantâneo.
Use dois Managed Instance Groups idênticos (ou GKE Deployments) atrás de um HTTP(S) Load Balancer. Realize a transição redirecionando o tráfego no serviço de backend do balanceador de carga.
Por quê: A divisão de tráfego no nível do balanceador de carga é instantânea e permite um rollback fácil, simplesmente trocando o tráfego de volta para o backend original. Isso é superior a métodos mais lentos baseados em DNS.
Armazenar, gerenciar e auditar com segurança o acesso a segredos como chaves de API e senhas de banco de dados para aplicações.
Use Secret Manager com IAM para controle de acesso e Workload Identity para autenticação sem chave de GKE/Cloud Run.
Por quê: Secret Manager é um serviço centralizado e gerenciado com versionamento, políticas de rotação e registro de auditoria. O uso de Workload Identity evita o gerenciamento e a distribuição de chaves de conta de serviço.
Impedir que dados sensíveis em serviços como BigQuery e Cloud Storage sejam acessados ou copiados para projetos ou locais não autorizados.
Use VPC Service Controls para criar um perímetro de serviço em torno de projetos sensíveis e restringir o fluxo de dados.
Por quê: VPC Service Controls atuam como um firewall para serviços gerenciados pelo Google, prevenindo a exfiltração de dados no nível da API. Esta é uma camada crítica de defesa em profundidade além do IAM e firewalls de rede.
Criptografar dados em repouso nos serviços Google Cloud, mantendo controle total sobre as chaves de criptografia.
Use Customer-Managed Encryption Keys (CMEK), com chaves armazenadas e gerenciadas no Cloud KMS.
Por quê: O CMEK permite usar suas próprias chaves via Cloud KMS para proteger dados em outros serviços GCP. Você controla a rotação das chaves e pode revogar o acesso desativando a chave, fornecendo apagamento criptográfico.
Projetar uma arquitetura para lidar com Informações de Saúde Protegidas (PHI) em conformidade com o HIPAA.
Use CMEK para controle de criptografia, VPC Service Controls para prevenir exfiltração, Assured Workloads para limites de conformidade, Cloud Audit Logs e Access Transparency para auditoria.
Por quê: O HIPAA exige uma combinação de controles técnicos. O CMEK fornece controle de chaves, o VPC-SC impede vazamentos de dados e o registro extensivo (Audit Logs, Access Transparency) fornece a auditabilidade necessária.
Um pod GKE precisa se conectar a um banco de dados Cloud SQL de forma segura, sem usar senhas ou gerenciar chaves de conta de serviço.
Use Workload Identity para vincular uma Service Account do Kubernetes a uma Service Account do Google. Conecte-se usando o sidecar Cloud SQL Auth Proxy e a autenticação de banco de dados IAM.
Por quê: Este padrão "sem senha" é o mais seguro. Workload Identity fornece autenticação sem chave, o Auth Proxy criptografa o tráfego, e a autenticação de banco de dados IAM usa IAM para acesso ao banco de dados em vez de credenciais estáticas.
Impor uma política de que todos os recursos da nuvem devem ser criados apenas em regiões geográficas específicas (por exemplo, UE).
Configure uma restrição de Organization Policy (`gcp.resourceLocations`) no nível da organização ou pasta, especificando as regiões permitidas.
Por quê: Este é um controle preventivo que bloqueia a criação de recursos não conformes no nível da API. É a maneira autoritária de impor políticas de residência de dados em toda a organização.
Garantir que apenas imagens de contêineres confiáveis, verificadas e autorizadas sejam implantadas em clusters GKE de produção.
Use Artifact Registry para varredura de vulnerabilidades e Binary Authorization para impor políticas de implantação que exigem atestações (assinaturas) válidas.
Por quê: Isso cria uma cadeia de suprimentos de software segura. O Artifact Registry verifica vulnerabilidades, e o Binary Authorization atua como um ponto de aplicação de políticas, verificando criptograficamente se uma imagem passou por todas as verificações necessárias.
Fornecer acesso seguro e ciente do contexto a aplicações web internas para funcionários remotos sem usar uma VPN tradicional.
Use BeyondCorp Enterprise com Identity-Aware Proxy (IAP), Access Context Manager para políticas e Endpoint Verification para postura do dispositivo.
Por quê: Isso implementa um modelo de confiança zero onde o acesso é concedido com base na identidade do usuário e na confiança do dispositivo, não na localização da rede. O IAP atua como um proxy de autenticação para cada solicitação.
Uma carga de trabalho regulamentada exige que as chaves de criptografia sejam armazenadas e processadas dentro de um Hardware Security Module (HSM) certificado FIPS 140-2 Nível 3.
Use Cloud KMS com o nível de proteção `HSM` para chaves.
Por quê: O Cloud HSM é um serviço totalmente gerenciado que oferece HSMs certificados FIPS 140-2 Nível 3. As chaves geradas com este nível de proteção nunca saem do limite do HSM em texto puro.
Descobrir e desidentificar automaticamente dados sensíveis (como PII) no Cloud Storage ou BigQuery.
Use Cloud Data Loss Prevention (DLP) para procurar dados sensíveis e aplicar técnicas de desidentificação como mascaramento, tokenização ou redação.
Por quê: O DLP fornece detectores pré-construídos e personalizados para uma ampla gama de tipos de dados sensíveis, permitindo proteção de dados automatizada e escalável sem scripts personalizados.
Permitir que funcionários de múltiplos provedores de identidade (por exemplo, Okta, Azure AD) acessem recursos do Google Cloud sem criar contas Google.
Use Workforce Identity Federation para conectar provedores de identidade externos ao Google Cloud IAM.
Por quê: Isso permite que você aproveite seus sistemas de identidade existentes como a fonte da verdade, evitando a necessidade de sincronizar usuários ou gerenciar identidades Google separadas para sua força de trabalho.
Processar dados altamente sensíveis onde os dados devem permanecer criptografados mesmo em uso (na memória).
Use Confidential VMs.
Por quê: A Computação Confidencial criptografa dados durante o processamento usando recursos de hardware dedicados (AMD SEV). Isso protege contra ataques de raspagem de memória e fornece uma camada extra de segurança para cargas de trabalho sensíveis.
Otimizar o custo e o desempenho do BigQuery para um grande data warehouse.
Implemente particionamento por data e agrupamento em colunas frequentemente filtradas. Use BI Engine para dashboards e materialized views para agregações comuns e caras.
Por quê: Particionamento e agrupamento são fundamentais para reduzir a quantidade de dados verificados por consulta, o que diminui diretamente os custos e melhora a velocidade. BI Engine e MVs reduzem computações redundantes.
Executar jobs de processamento em lote de grande escala e tolerantes a falhas com o menor custo de computação possível.
Use Spot VMs em um Managed Instance Group. Garanta que a aplicação seja tolerante a falhas e possa lidar com preemptions.
Por quê: Spot VMs oferecem até 91% de economia em relação às instâncias sob demanda. São ideais para cargas de trabalho sem estado, tolerantes a falhas, que podem ser interrompidas e reiniciadas, como muitas tarefas de processamento em lote.
Implementar práticas de FinOps para fornecer visibilidade de custos e responsabilidade a diferentes equipes ou departamentos.
Use uma hierarquia de recursos (pastas por equipe), aplique rótulos para alocação de custos e exporte dados de faturamento detalhados para o BigQuery para análise e visualização no Looker Studio.
Por quê: Esta combinação oferece uma maneira estruturada de organizar recursos, rastrear custos granularmente via rótulos e construir dashboards personalizados e específicos para equipes para showback/chargeback.
Otimizar o custo e o desempenho do cluster GKE para aplicações com carga variável.
Use Horizontal Pod Autoscaler (HPA) para escalar pods com base em métricas e Cluster Autoscaler para adicionar/remover nós conforme necessário.
Por quê: Essa abordagem de autoescalamento de dois níveis garante que tanto a aplicação (pods) quanto a infraestrutura (nós) escalem em conjunto com a demanda, prevenindo o superprovisionamento e garantindo o desempenho.
Um job de treinamento de ML apresenta baixa utilização da GPU (<30%), indicando um gargalo.
Diagnosticar e otimizar o pipeline de entrada de dados. Use `tf.data` com prefetching e leituras paralelas, ou Cloud Storage FUSE para melhorar o desempenho de I/O.
Por quê: Baixa utilização da GPU é quase sempre um gargalo de I/O de dados. A GPU fica ociosa enquanto espera pelo próximo lote de dados. Otimizar o carregamento de dados é o primeiro passo para melhorar a eficiência do treinamento.
Reduzir altos custos de saída de rede ao servir dados para a internet ou entre regiões.
Use Cloud CDN para armazenar conteúdo estático em cache. Para tráfego inter-regiões, use o Standard Network Service Tier para cargas de trabalho não sensíveis à latência.
Por quê: O CDN serve dados da borda, o que é mais barato do que a saída da origem. O Standard Tier roteia o tráfego pela internet pública em vez da rede premium do Google, oferecendo um custo menor para transferência de dados em massa.
Reduzir custos para VMs de desenvolvimento e teste que são necessárias apenas durante o horário comercial.
Use Cloud Scheduler para acionar Cloud Functions que iniciam e param instâncias automaticamente em um cronograma predefinido.
Por quê: Este padrão de "agendamento de instâncias" automatiza o processo de desligamento de recursos quando não estão em uso, reduzindo significativamente os custos para ambientes não-produção.
Uma aplicação crítica requer um banco de dados relacional com failover automático em caso de falha de zona.
Configure a instância do Cloud SQL com a opção de Alta Disponibilidade (HA).
Por quê: A configuração HA cria uma instância de espera em uma zona diferente com replicação síncrona. Em caso de falha da instância primária ou da zona, o failover é automático e geralmente leva menos de 60 segundos.
Detectar e recuperar automaticamente de instâncias do Compute Engine que não respondem ou falham.
Implante instâncias em um Managed Instance Group (MIG) e configure o autohealing com uma verificação de saúde baseada em aplicação.
Por quê: O autohealing do MIG sonda ativamente a aplicação em cada instância. Se a aplicação falhar em sua verificação de saúde, o MIG recria automaticamente a instância, garantindo a confiabilidade do serviço.
Projetar um plano de recuperação de desastres com um RTO de < 1 hora e RPO de < 15 minutos.
Implemente um warm standby em uma região secundária. Use réplicas entre regiões do Cloud SQL, Cloud Storage multi-regional e templates de instância pré-configurados para computação.
Por quê: Essa abordagem equilibra custo e tempo de recuperação. Os dados são replicados quase que sincronamente para atender ao RPO, e uma infraestrutura mínima está em execução (warm) para permitir um rápido aumento de escala para atender ao RTO.
Implementar observabilidade abrangente para uma aplicação de microsserviços para permitir solução de problemas rápida.
Use logging estruturado com IDs de correlação, Cloud Trace para rastreamento distribuído, Cloud Monitoring para métricas e Cloud Error Reporting para agrupamento automático de erros.
Por quê: Uma combinação de logs, traces e métricas (os "três pilares da observabilidade") é essencial. IDs de correlação e rastreamento distribuído são críticos para seguir uma única requisição em múltiplos serviços.
Prevenir que uma falha em um microsserviço cause uma falha em cascata em toda a aplicação.
Implemente padrões de resiliência como circuit breakers, retries com backoff exponencial e timeouts agressivos em cada ponto de comunicação entre serviços.
Por quê: Esses padrões isolam falhas. Um circuit breaker interrompe as chamadas para um serviço com falha, evitando que o serviço chamador esgote seus recursos e falhe por sua vez.
Implementar as melhores práticas de SRE para reduzir o risco de interrupções na produção causadas por novas implantações.
Use implantações canary para lançar mudanças gradualmente, feature flags para desacoplar a implantação do lançamento e gatilhos de rollback automatizados baseados no monitoramento de SLO.
Por quê: Essas práticas limitam o "raio de explosão" de uma implantação ruim. As canaries expõem a nova versão a um pequeno subconjunto de usuários primeiro, e o rollback automatizado minimiza o Mean Time to Recovery (MTTR).
Usar orçamentos de erro SRE para equilibrar a velocidade de recursos com a confiabilidade.
Defina uma política de orçamento de erro: quando o orçamento estiver quase esgotado, congele novas implantações de recursos e priorize o trabalho que melhora a confiabilidade.
Por quê: O orçamento de erro é um mecanismo baseado em dados para tomar decisões de trade-off. Ele dá às equipes permissão para correr riscos quando o orçamento está saudável e impõe um foco na estabilidade quando não está.
Uma aplicação distribuída globalmente usando Cloud Spanner experimenta alta latência de escrita em certas regiões.
Analise os padrões de escrita da aplicação e configure a região líder da instância do Spanner para ser geograficamente próxima da maioria das operações de escrita.
Por quê: No Spanner, todas as escritas são roteadas pela região líder para garantir a consistência. A colocação da região líder próxima à fonte primária de escritas minimiza a latência da rede para essas transações.
