Google Cloud Professional Cloud Developer
225 perguntas de prática
Última revisão: April 2026
Notas pessoais e links de recursos para sua jornada de estudo
Filtrar por Certificação
O Google Cloud Professional Cloud Developer (PCD) valida a capacidade de construir aplicações escaláveis, seguras e nativas da nuvem no Google Cloud. O exame enfatiza engenharia real: escolher entre Cloud Run, GKE, App Engine e Cloud Functions para uma determinada carga de trabalho; projetar sistemas orientados a eventos com Pub/Sub e Eventarc; implementar observabilidade com Cloud Trace e Cloud Profiler; e integrar com Cloud SQL, Spanner, Firestore e Memorystore. O estilo das perguntas é baseado em cenários — pequenas histórias sobre os requisitos de uma equipe com quatro opções plausíveis, onde uma é a resposta mais idiomática do Google Cloud. O PCD é o análogo no GCP do AWS Developer Associate, um nível acima, ou do Azure AZ-204 com conteúdo de arquitetura mais profundo. Ele se destina a desenvolvedores backend, engenheiros full-stack e engenheiros de plataforma que realmente entregam código no GCP.
O maior domínio, com 25%. Padrões de 12 fatores, tradeoffs de microsserviços vs. monólitos, escolha da computação certa (Cloud Run vs. GKE vs. Cloud Functions vs. App Engine), design orientado a eventos com Pub/Sub. Forte em cenários de tradeoffs.
Desenvolvimento local com Cloud Code, builds de contêineres com Cloud Build e Buildpacks, padrões de testes unitários / de integração / de carga, gerenciamento de dependências. 20%.
Implantações blue-green e canary no Cloud Run e GKE, divisão de tráfego, Artifact Registry, padrões de pipeline de implantação com Cloud Build, identidade de serviço e Workload Identity. 20%.
Padrões Pub/Sub (push vs. pull, entrega exatamente uma vez), Eventarc, Cloud Tasks, Cloud Scheduler, integrações com Cloud SQL / Spanner / Firestore / Memorystore. 20% — forte em padrões idiomáticos.
Cloud Logging, Cloud Monitoring, Cloud Trace, Cloud Profiler, relatório de erros, ajuste de autoescalonamento, engenharia consciente de custos. 15%.
Serviços que você encontrará no exame e por que cada um importa.
Ambiente de execução de contêineres serverless totalmente gerenciado que escala para zero, com revisões, divisão de tráfego, ajuste de concorrência e cobrança baseada em solicitação.
Por que está no exame: O Domínio 1 (Designing Cloud-Native Applications) trata o Cloud Run como o primitivo de computação padrão para serviços conteinerizados sem estado — espere perguntas sobre concorrência, cold starts e reversão de revisão.
Computação serverless orientada a eventos (2ª geração construída sobre o Cloud Run) acionada por eventos HTTP, Pub/Sub, Cloud Storage, Eventarc e Firestore.
Por que está no exame: O Domínio 1 + Domínio 4 (Integrating Google Cloud Services) testam o Functions para integração leve entre serviços e padrões de mapeamento de fontes de eventos.
PaaS totalmente gerenciada para aplicativos web com ambientes Standard (escalonamento por solicitação) e Flexible (baseado em contêineres), divisão de tráfego e implantações versionadas.
Por que está no exame: O Domínio 3 (Deploying Applications) testa a divisão de tráfego do App Engine, implantações versionadas e a seleção Standard vs. Flexible — um distrator recorrente em relação ao Cloud Run.
Kubernetes gerenciado com modos Autopilot e Standard, Workload Identity, ingresso multi-cluster e malha de serviço Anthos integrada.
Por que está no exame: O Domínio 1 + Domínio 3 testam os trade-offs Autopilot vs. Standard do GKE, o Workload Identity para autenticação de pod-para-API do Google, e estratégias de implantação rolling vs. blue/green.
Serviço de CI gerenciado impulsionado por `cloudbuild.yaml` que constrói imagens de contêiner, executa testes, assina artefatos e envia para o Artifact Registry.
Por que está no exame: O Domínio 2 (Building and Testing Applications) nomeia o Cloud Build como o serviço de CI canônico — espere perguntas sobre etapas de build, substituições e gatilhos.
Repositórios Git privados gerenciados integrados com gatilhos do Cloud Build, Cloud Logging e acesso ao repositório baseado em IAM.
Por que está no exame: O Domínio 2 + Domínio 3 cobrem o CSR como a fonte nativa do Google para gatilhos do Cloud Build, frequentemente contrastado com repositórios espelhados do GitHub/GitLab.
Serviço de entrega contínua gerenciado para GKE, Cloud Run e Anthos com pipelines de entrega declarativos, portões de promoção e rollback automatizado.
Por que está no exame: O Domínio 3 (Deploying Applications) testa a progressão de pipeline do Cloud Deploy (dev → staging → prod), os portões de aprovação e a semântica de rollback.
Armazenamento unificado para imagens de contêiner, Maven, npm, Python, Go e pacotes de SO com acesso controlado por IAM, varredura de vulnerabilidades e repositórios remotos/virtuais.
Por que está no exame: O Domínio 2 + Domínio 3 esperam o Artifact Registry (sucessor do Container Registry) como o armazenamento de imagens consumido por implantações do Cloud Build → Cloud Run / GKE.
Banco de dados de documentos serverless (Firestore em modo Native ou Datastore) com ouvintes em tempo real, sincronização offline e regras de segurança; Firebase Realtime DB para aplicativos legados baseados em árvore JSON.
Por que está no exame: O Domínio 1 testa o Firestore para cargas de trabalho de documentos de baixa latência com push em tempo real para clientes móveis/web — um contraste recorrente com Cloud Spanner e Bigtable.
Banco de dados relacional globalmente distribuído e fortemente consistente com escalonamento horizontal, instâncias regionais/multi-regionais e suporte a dialetos SQL + GoogleSQL.
Por que está no exame: O Domínio 1 nomeia o Spanner sempre que uma pergunta exige semântica relacional em escala planetária ou disponibilidade de 5 noves — distinguindo-o do Cloud SQL e Firestore.
Mensagens assíncronas globais com entrega no mínimo uma vez, assinaturas push e pull, chaves de ordenação, tópicos de dead-letter e Pub/Sub Lite para cargas de trabalho regionais de alto throughput.
Por que está no exame: O Domínio 4 (Integrating Google Cloud Services) testa o Pub/Sub como o primitivo de desacoplamento canônico para backends orientados a eventos — a escolha entre pull vs. push e a semântica de DLQ são perguntas comuns.
Filas de tarefas assíncronas gerenciadas com agendamento por tarefa, controle de taxa/concorrência, retentativas com back-off exponencial e destinos HTTP / App Engine.
Por que está no exame: O Domínio 4 distingue o Cloud Tasks (controle explícito e deduplicado por tarefa) do Pub/Sub (fluxos de fan-out) — um par distrator recorrente no estilo DVA.
Orquestrador de fluxo de trabalho serverless usando uma DSL YAML/JSON para encadear APIs HTTP, Cloud Functions, Cloud Run e Google Cloud com retentativas e etapas paralelas.
Por que está no exame: O Domínio 4 contrasta Workflows (orquestração durável) com fan-out puro do Pub/Sub — as perguntas testam retentativas de etapa, branches paralelas e uso de conectores.
A Apigee fornece gerenciamento completo do ciclo de vida da API (proxies, monetização, análises, OAuth); o API Gateway é um gateway leve gerenciado para backends serverless.
Por que está no exame: O Domínio 4 testa a Apigee para o ciclo de vida de API corporativo (portal do desenvolvedor, cota, proxies OAuth) e o API Gateway para exposição de API serverless — escolher entre eles é um cenário recorrente.
Camada de gerenciamento de API OpenAPI/gRPC para backends App Engine, GKE e Compute Engine com proxy ESP/ESPv2, autenticação, monitoramento e imposição de cota.
Por que está no exame: O Domínio 4 mantém o Cloud Endpoints no escopo para backends auto-hospedados no GKE/Compute Engine onde a Apigee é um exagero, mas o API Gateway não se encaixa.
Infraestrutura de eventos para entregar mais de 130 fontes de eventos do Google Cloud para Cloud Run, Cloud Functions e GKE via Pub/Sub formatado como CloudEvents ou gatilhos de log de auditoria.
Por que está no exame: O Domínio 4 nomeia o Eventarc sempre que um evento precisa fluir de um serviço do Google Cloud (por exemplo, Cloud Storage, Audit Logs) para um destino serverless com formatação padrão CloudEvents.
Identidade com escopo de projeto e organização com papéis predefinidos e personalizados, contas de serviço, Federação de Workload Identity e políticas baseadas em recursos.
Por que está no exame: O Domínio 5 (Managing Application Performance / Security) testa o design de papéis de menor privilégio, a personificação de contas de serviço e o Workload Identity para autenticação de pod-para-API do Google sem chaves estáticas.
O Cloud KMS gerencia chaves de criptografia gerenciadas pelo cliente (CMEK / HSM externo); o Secret Manager armazena chaves de API, credenciais de DB e tokens com versionamento e rotação.
Por que está no exame: O Domínio 1 + Domínio 3 esperam o Secret Manager para injeção de credenciais em tempo de execução e o Cloud KMS como o armazenamento de chaves de suporte — distingui-los das variáveis de ambiente é uma pergunta recorrente.
Cloud Trace para análise de latência distribuída, Cloud Profiler para perfil de CPU/memória em produção e Cloud Debugger (obsoleto; substituição por Snapshot Debugger) para inspeção de estado ao vivo.
Por que está no exame: O Domínio 5 (Managing Application Performance) é amplamente coberto pelo Cloud Operations Suite — espere perguntas sobre cadeias de rastreamento em Cloud Run/Functions e diagnóstico de hotspots baseado em perfil.
O Cloud Logging agrega logs estruturados de todos os serviços do Google Cloud com sinks, métricas baseadas em log e o Logs Explorer; o Error Reporting agrupa e alerta sobre exceções de aplicativos.
Por que está no exame: O Domínio 5 testa o registro estruturado do Cloud Run/Functions, alertas baseados em log via Cloud Monitoring e agrupamentos do Error Reporting — a superfície canônica de "onde está o bug".
$130k–$180k–$270k USD anual
O intervalo reflete engenheiros backend sêniores / cloud-native baseados nos EUA, onde o GCP é a plataforma principal. O TC de um engenheiro de software FAANG L5 ultrapassa $300k. A certificação é um forte indicativo, mas não por si só garante esses salários — ela complementa 5 a 10+ anos de experiência comprovada em engenharia de software.
Fonte: levels.fyi 2025–2026 (engenheiros de software Google L4–L5, backends sêniores em FAANG e unicórnios com GCP), U.S. BLS OEWS May 2024 (15-1252 desenvolvedores de software). Os valores são aproximados; a compensação real depende da função, região e experiência.
O PCD é solicitado com menos frequência do que as certificações de trilha de arquiteto, mas é um forte diferencial em anúncios de emprego para engenheiros de backend sêniores e de plataforma em empresas com forte uso de GCP. A demanda se concentra em Spotify, Snap, PayPal, Wayfair, vários grandes varejistas, estúdios de jogos e parceiros do Google Cloud. A certificação também é valorizada no próprio Google — as carreiras de engenharia de clientes e de defensores de desenvolvedores frequentemente a listam como preferencial. O PCD combina naturalmente com a certificação Kubernetes CKAD e com Terraform Associate para formar um perfil forte de desenvolvedor cloud-native. É menos utilizado como filtro de contratação do que o ACE ou PCA, mas os detentores relatam consistentemente melhor resposta de recrutadores para vagas de engenheiro sênior.
Não há pré-requisitos formais. O Google recomenda três ou mais anos de experiência na indústria, incluindo um ou mais anos projetando e desenvolvendo aplicações no Google Cloud. Na prática, o PCD não é uma primeira certificação GCP sensata para não-desenvolvedores — candidatos bem-sucedidos conseguem ler e escrever Go, Java, Python ou Node.js confortavelmente e já entregaram aplicações não-triviais.
O Associate Cloud Engineer (ACE) é o trampolim mais comum, mas não é estritamente exigido se você já escreve código de produção no AWS ou Azure. Conforto com contêineres, Kubernetes básico (Deployments, Services, ConfigMaps), conceitos de CI/CD e pelo menos um dos principais bancos de dados SQL ou de documentos é efetivamente exigido. O Caminho de Aprendizagem Oficial de Desenvolvedor Cloud no Google Cloud Skills Boost (cerca de 50 a 70 horas de laboratórios e leitura) é uma boa base, mas a maioria dos candidatos bem-sucedidos complementa com projetos pessoais secundários no Cloud Run / GKE.
O PCD é classificado como profissional e é genuinamente focado em cenários. Planeje de 80 a 130 horas de estudo ao longo de 8 a 12 semanas se o PCD for sua primeira certificação profissional GCP, ou de 40 a 70 horas ao longo de 4 a 6 semanas se você já possui o ACE mais experiência sólida em engenharia de backend. O exame tem de 50 a 60 questões de múltipla escolha / múltipla seleção em 120 minutos, entregues através da Pearson VUE (o Google migrou do Kryterion / Webassessor no início de 2026).
O obstáculo mais comum é escolher entre Cloud Run, GKE, App Engine e Cloud Functions para um determinado cenário — a resposta "preferida" do Google frequentemente depende de critérios sutis de escalonamento, latência ou sobrecarga operacional que não são óbvios apenas pela documentação. O segundo obstáculo é a semântica de entrega do Pub/Sub (pelo menos uma vez vs. exatamente uma vez, push vs. pull, tópicos de dead-letter). O Google não publica pontuações numéricas — apenas aprovação/reprovação. A credencial é válida por dois anos e a recertificação exige passar novamente no exame atual.
Guia de exame atualizado no final de 2023 para adicionar jobs do Cloud Run, cobertura expandida do Eventarc e cenários atualizados de GKE Workload Identity. Removeu o foco no ambiente flexível legado do App Engine.
Grande atualização que introduziu o Cloud Run como uma opção de computação de primeira classe e expandiu o domínio de observabilidade.
PCD (Google Cloud Professional Cloud Developer) é um exame de nível Professional um exame desafiador, com muitos cenários, que exige profunda experiência prática e a capacidade de tomar decisões de trade-off arquitetônicas. A maioria dos candidatos precisa de 150 a 300 horas de estudo distribuídas em 3 a 6 meses para exames de nível profissional e especialista. Esses exames geralmente esperam proficiência anterior em nível associado. A maioria dos candidatos que pontuam consistentemente acima do limite de aprovação em exames práticos é aprovada na primeira tentativa.
A maioria dos candidatos precisa de 150 a 300 horas de estudo distribuídas em 3 a 6 meses para exames de nível profissional e especialista. Esses exames geralmente esperam proficiência anterior em nível associado. O tempo para aprovação varia amplamente de acordo com a experiência prévia. Engenheiros com experiência prática de produção na tecnologia subjacente geralmente precisam de menos tempo; candidatos novos na plataforma devem planejar-se para o limite superior dessa faixa.
PCD é uma credencial reconhecida no ecossistema GCP e sinaliza conhecimento validado para empregadores, recrutadores e clientes. Se vale a pena o tempo e a taxa para você, depende do seu papel e objetivos — geralmente compensa mais para engenheiros de nuvem, arquitetos e consultores que trabalham com GCP diariamente ou desejam mudar para funções que o fazem.
A pontuação de aprovação para PCD é Não publicado. O exame contém 50 questões e dura 2 h.
A taxa do exame PCD é $200 USD. As taxas são definidas por GCP e podem variar por região; sempre confirme o preço atual na página oficial de certificação GCP antes de agendar.
As certificações Google Cloud Professional são válidas por 2 anos. Recertifique-se passando novamente na versão atual do exame.
Sim. Você pode fazer o exame online (supervisionado através do navegador seguro do provedor, disponível 24 horas por dia, 7 dias por semana na maioria das regiões) ou em um centro de testes Pearson VUE presencial durante o horário comercial. Ambos os formatos usam as mesmas perguntas, limite de tempo e pontuação de aprovação.
A CertLabPro oferece 15 modos de estudo no banco de questões práticas para PCD. O modo de simulação de exame espelha o exame real: 50 questões em 2 h, com o mesmo limite de aprovação de Não publicado. O modo de navegação permite que você leia todas as perguntas e respostas estaticamente.