Professional Cloud Developer — Questões de prática e simulado

A certificação Professional Cloud Developer valida a capacidade de projetar, construir, testar e implantar aplicações cloud-native no Google Cloud. Ela cobre arquitetura de aplicações, integração com CI/CD, containerização com Cloud Run e GKE, além do uso de serviços do Google Cloud para armazenamento, mensageria e IA. No guia do exame, o maior peso fica com o projeto de aplicações cloud-native escaláveis, seguras e confiáveis (cerca de 32%), e o papel do desenvolvedor agora inclui explicitamente APIs de IA generativa e ferramentas de desenvolvimento com IA.

É uma credencial de nível professional para engenheiros de software e desenvolvedores que constroem aplicações cloud-native no Google Cloud. O Google recomenda mais de 3 anos de experiência no mercado, incluindo pelo menos 1 ano projetando e gerenciando soluções em nuvem no Google Cloud. Ela abre caminho para vagas de cloud developer, full-stack developer e application architect.

O design de aplicações é o bloco mais pesado, com 32%: escolher a plataforma de compute entre Compute Engine, GKE e Cloud Run, arquitetar APIs com caching e load balancing, manter as chamadas entre serviços restritas ao menor privilégio possível e definir um schema de banco que caiba no volume dos dados e nas necessidades de consistência. Depois vem a configuração de aplicações para deploy, com 24%: testar se uma release no Cloud Run entra no ar corretamente e se um rollout containerizado no GKE continua saudável e disponível sob autoscaling. Build e testes ficam com 23%: o loop de desenvolvimento local, imagens de container construídas e registradas via Artifact Registry e Cloud Build, além da escrita de testes com apoio de IA. A integração com o resto do Google Cloud fecha o blueprint com 21%, cobrindo conexões de dados e mensageria, padrões de consumo de APIs e instrumentação de observabilidade para troubleshooting.

A ênfase em design, e não em sintaxe pura, diz tudo sobre a premissa da prova: ela parte do princípio de que você já sabe escrever o código e vai testar se você arquitetaria a solução corretamente sob restrições reais de latência, custo e modos de falha. Não é sobre decorar a API de um framework específico.

A prova traz de 50 a 60 questões de múltipla escolha e de múltipla seleção numa janela de 120 minutos, com proporção aproximada de 80% de resposta única para 20% de seleção múltipla. Cada questão apresenta um cenário de desenvolvimento e pede que você escolha a arquitetura, o serviço ou a abordagem certa, quase sempre envolvendo Cloud Run, GKE, Cloud Functions, Pub/Sub, Firestore ou algum controle de segurança de aplicação.

Cada domínio do exame GCP-PCD tem questões suficientes no banco para você praticar a fundo. Um simulado apresenta 55 questões seguidas, no mesmo cronômetro de 120 minutos do dia do exame.

Quanto tempo você precisa depende da experiência prática que já tem. O resto é definido pelo fornecedor: como a prova é aplicada, quando você pode refazê-la e por quanto tempo a certificação continua válida.

A prova é aplicada pela Pearson VUE, com proctoring online ou em um centro de testes, e está disponível em inglês e japonês. A certificação vale 2 anos, e a renovação fica liberada durante o período de elegibilidade para renovação.

A prova pressupõe uma base sólida de desenvolvimento de software, então quem vem de um background mais voltado a infraestrutura costuma subestimar as questões sobre padrões de design de aplicações, gestão de APIs e estrutura de pipelines de CI/CD. Escolher entre Cloud Run, Cloud Functions e App Engine para uma determinada carga de trabalho é um ponto de decisão recorrente, e o erro quase sempre vem de não pesar o comportamento de cold start ou os limites de tempo de execução. Com banco de dados acontece a mesma coisa: Firestore, Cloud SQL, Spanner e Bigtable atendem perfis diferentes de consistência e escala, e a prova espera que esse mapeamento seja automático para você. Pub/Sub, Eventarc e Cloud Tasks resolvem problemas de processamento assíncrono que se sobrepõem bastante, e é fácil deixar passar o scanning de imagens de container e os padrões de acesso do Artifact Registry enquanto sua cabeça está toda na lógica da aplicação.