Google Cloud Professional Cloud DevOps Engineer
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 DevOps Engineer (PCDOE) valida a capacidade de aplicar os princípios de engenharia de confiabilidade de site (SRE) do Google a serviços de produção no Google Cloud. O exame mistura conteúdo clássico de DevOps (CI/CD com Cloud Build e Cloud Deploy, GitOps, Artifact Registry, IaC com Terraform) com a estrutura SRE distinta do Google — SLOs, SLIs, orçamentos de erro, redução de esforço repetitivo, cultura post-mortem. Ele também abrange todo o conjunto do Cloud Operations (Logging, Monitoring, Trace, Profiler, Error Reporting), operações de segundo dia do GKE e FinOps. O PCDOE é o análogo do GCP ao AWS DevOps Engineer Professional e ao Azure AZ-400 — mais próximo em espírito do livro Google SRE do que de uma certificação DevOps focada em ferramentas.
Hierarquia de recursos, políticas organizacionais, IAM de linha de base, barreiras de rede e segurança, IaC com Terraform e Cloud Foundation Toolkit. 20%.
Maior domínio, com 23%. Cloud Build, Cloud Deploy, Skaffold, Artifact Registry, estratégias de implantação (blue-green, canary, rolling), GitOps com Config Sync. Grande foco em cenários de design de pipeline.
Empatado como maior domínio, com 23%. Design de SLI / SLO / orçamento de erro, identificação e redução de esforço repetitivo, planejamento de capacidade, práticas de plantão, post-mortems. Extraído diretamente do livro Google SRE.
Roteamento e sinks do Cloud Logging, métricas baseadas em logs, painéis e alertas do Cloud Monitoring, Cloud Trace, Cloud Profiler, Error Reporting. 22%.
Menor domínio, com 12%, mas de alta densidade. Dimensionamento do GKE, famílias de máquinas do Compute Engine, FinOps com Active Assist e Recommender, ajuste de autoscaling.
Serviços que você encontrará no exame e por que cada um importa.
Serviço CI gerenciado que executa builds, testes e imagens de contêiner em workers hospedados pelo Google, impulsionado por um cloudbuild.yaml declarativo.
Por que está no exame: O Dominio 2 (CI/CD Pipelines) nomeia o Cloud Build como o executor de build canônico nativo do PCDOE — substrato para a criação de imagens, atestado e gatilhos de pipeline.
Serviço gerenciado de entrega contínua que promove imagens de contêiner através de alvos GKE / Cloud Run ordenados com aprovações e rollback.
Por que está no exame: O Dominio 2 testa padrões de entrega progressiva (canary, blue/green) — o Cloud Deploy é a resposta equivalente ao AWS-CodeDeploy no GCP.
Registro unificado para pacotes Docker, Helm, Maven, npm, Python, Go e OS, com isolamento VPC-SC e varredura de vulnerabilidades.
Por que está no exame: O Dominio 2 + Dominio 5 enfatizam a proveniência de artefatos e a varredura de vulnerabilidades — o Artifact Registry é o endpoint da cadeia de suprimentos e a fonte de imagens para o Cloud Deploy.
Hospedagem Git gerenciada, integrada a gatilhos do Cloud Build, Cloud Logging e Cloud Identity IAM para fluxos de trabalho de controle de código-fonte.
Por que está no exame: O Dominio 2 espera uma fonte da verdade integrada para gatilhos do Cloud Build e releases do Cloud Deploy — o CSR é o equivalente ao AWS-CodeCommit.
Kubernetes gerenciado com modos Standard e Autopilot, planos de controle regionais, ingress multi-cluster e upgrades gerenciados de pools de nós.
Por que está no exame: O Dominio 3 (SRE Practices) e o Dominio 4 (Observabilidade) dependem do GKE — a implantação de workloads, o autoscaling com reconhecimento de SLO e os rolling upgrades são todos centrados no GKE.
Controlador de configuração GitOps que sincroniza o estado declarativo do cluster (Kustomize, Helm, Config Sync) e aplica restrições do Policy Controller (OPA Gatekeeper) em frotas.
Por que está no exame: O Dominio 1 (Inicialização de uma organização Google Cloud) e o Dominio 3 (SRE Practices) testam GitOps e política como código — o ACM é a resposta nomeada do GCP.
Add-on do Kubernetes que gerencia recursos GCP (datasets BigQuery, tópicos Pub/Sub, vinculações IAM) como CRDs reconciliados de manifestos de cluster.
Por que está no exame: O Dominio 1 testa infraestrutura declarativa em formato GitOps — o Config Connector permite que as equipes de plataforma enviem provisionamento GCP junto com workloads sob o mesmo kubectl apply.
HashiCorp Terraform com os provedores oficiais google + google-beta, além de módulos do Cloud Foundation Toolkit e a biblioteca de políticas Terraform-validator.
Por que está no exame: O Dominio 1 nomeia o Terraform como a ferramenta IaC de fato para landing zones, projetos, redes e IAM — o PCDOE espera fluência com a estrutura de módulos e a estratégia de estado.
Runtime de contêiner serverless (orientado a requisições ou eventos) com divisão de tráfego revisionada, sidecars e mTLS gerenciado via Cloud Service Mesh.
Por que está no exame: O Dominio 2 testa a entrega progressiva para serviços stateless — as revisões do Cloud Run + divisão de tráfego são a primitiva canary canônica.
Computação serverless orientada a eventos (gatilhos HTTP e Eventarc) para integração leve entre Pub/Sub, Cloud Storage e Firestore.
Por que está no exame: O Dominio 4 (Observabilidade) cita Functions como o substrato para automação de resposta a incidentes e runbooks orientados a eventos.
Orquestração serverless que encadeia APIs do Google Cloud e endpoints HTTP com retentativas, etapas paralelas e tratamento de erros estruturado.
Por que está no exame: O Dominio 4 espera remediação automatizada — o Workflows é o equivalente ao AWS-Step-Functions para playbooks de resposta a incidentes e rollback multi-serviço.
Serviço de fila de tarefas totalmente gerenciado com limitação de taxa, deduplicação e alvos HTTP / App Engine para trabalho assíncrono e exatamente uma vez.
Por que está no exame: O Dominio 5 (Desempenho e Custo) testa padrões de descarregamento de carga — o Cloud Tasks desacopla produtores intermitentes de consumidores com limitação de taxa e atenua picos de custo.
Modo de operação do GKE onde o Google gerencia nós, autoscaling e dimensionamento de pools de nós — faturado por pod com disponibilidade garantida por SLA.
Por que está no exame: O Dominio 5 nomeia o Autopilot como o trade-off de custo/esforço operacional para equipes que desejam confiabilidade de nível SRE sem gerenciar pools de nós.
Agrupamento lógico de múltiplos clusters GKE em projetos, regiões e on-prem, com ativação de recursos em toda a frota (Config Sync, Policy Controller, Identity).
Por que está no exame: O Dominio 1 + Dominio 3 testam operações multi-cluster — as Frotas são a unidade de propagação de política e identidade para equipes de plataforma que gerenciam muitos clusters.
Plataforma de entrega contínua multi-cloud de código aberto com suporte nativo a GKE / Cloud Run, estágios de julgamento manual e análise canary automatizada.
Por que está no exame: O Dominio 2 contrasta o Cloud Deploy (gerenciado, opinativo) com o Spinnaker (auto-hospedado, multi-cloud) — saber quando cada um se encaixa é uma distinção recorrente do PCDOE.
Google Cloud IAM com vinculações condicionais, além de Workload Identity que federa pods GKE / externos para contas de serviço Google sem chaves de longa duração.
Por que está no exame: O Dominio 1 + Dominio 3 dependem da autenticação sem chave — Workload Identity é a maneira canônica de pipelines e pods assumirem identidades GCP sob o princípio do menor privilégio.
Pilha de observabilidade integrada — Cloud Logging para agregação de logs, Cloud Monitoring para métricas e alertas, Cloud Trace para latência e Cloud Profiler para amostragem contínua de CPU/heap.
Por que está no exame: O Dominio 4 (Observabilidade e Resolução de Problemas) é a razão de ser desta suíte; o PCDOE espera o uso fluente de MQL, métricas baseadas em logs e verificações de tempo de atividade.
O Error Reporting agrega e agrupa stack traces do Cloud Logging em problemas acionáveis; o Cloud Debugger captura o estado da aplicação a partir de código de produção em execução sem redeploys.
Por que está no exame: O Dominio 4 testa a triagem de incidentes em tempo real — o Error Reporting captura regressões, o Debugger inspeciona o estado sem forçar um rollback.
Definições nativas de SLO no Service Monitoring com alertas de taxa de queima de orçamento de erro contínuos e políticas de velocidade de release orientadas por orçamento.
Por que está no exame: O Dominio 3 (SRE Practices) é construído em torno de SLIs/SLOs/orçamentos de erro — o PCDOE espera que os candidatos traduzam as expectativas do usuário em política de alerta de taxa de queima.
$135k–$185k–$280k USD anual
A faixa reflete engenheiros SRE e DevOps baseados nos EUA, onde o GCP é a plataforma principal. O TC de um SRE L5 da FAANG ultrapassa US$ 300 mil+. Funções puramente de operações tendem a ter salários mais baixos; cargos de SRE sênior / engenheiro de produção em empresas nativas digitais que usam GCP tendem a ser mais altos. A certificação é um sinal forte, mas combina melhor com experiência comprovada de plantão em produção.
Fonte: levels.fyi 2025–2026 (SRE L4–L5 do Google, engenheiros de plataforma sênior de unicórnios da FAANG e empresas GCP), U.S. BLS OEWS May 2024 (15-1244 administradores de redes e sistemas de computador, 15-1252 desenvolvedores de software). Os valores são aproximados; a compensação real depende da função, região e experiência.
A demanda pelo PCDOE tem crescido constantemente à medida que a cultura SRE-first do GCP se expandiu para seus clientes. Há uma forte demanda em empresas nativas digitais que usam GCP (Spotify, Snap, PayPal, vários grandes varejistas, estúdios de jogos) onde o modelo SRE já é adotado, e em parceiros do Google Cloud que estão construindo práticas de serviços gerenciados. A certificação combina naturalmente com Kubernetes CKA / CKAD e Terraform Associate para formar um forte perfil de SRE nativo da nuvem. Os titulares relatam consistentemente uma forte resposta de recrutadores para cargos de SRE e engenheiro de plataforma sênior. O PCDOE também sinaliza fluência no livro Google SRE, o que por si só é um sinal de contratação em empresas que adotaram o modelo SRE.
Não há pré-requisitos formais. O Google recomenda três ou mais anos de experiência na indústria e um ou mais anos projetando e gerenciando soluções no Google Cloud. Na prática, o PCDOE não é uma primeira certificação GCP credível — candidatos bem-sucedidos já implementaram sistemas em produção e realizaram plantões.
O Associate Cloud Engineer (ACE) é o degrau mais comum, mas não é estritamente necessário se você já gerencia ambientes de produção AWS ou Azure. Ler o livro Google SRE ("Site Reliability Engineering") e o SRE Workbook é efetivamente parte da preparação — muitas perguntas do exame parafraseiam passagens diretamente. É necessário ter familiaridade com Kubernetes (Deployments, Services, HPA, PodDisruptionBudgets), Terraform e pipelines do Cloud Build. O Caminho de Aprendizagem oficial do Engenheiro DevOps no Google Cloud Skills Boost (cerca de 40 a 60 horas) abrange o currículo.
O PCDOE é classificado como profissional e é moderadamente difícil — o conteúdo específico de SRE (SLOs, orçamentos de erro, esforço repetitivo) dificulta mais os candidatos tradicionalmente focados em operações do que os engenheiros de confiabilidade de site experientes. Planeje 80–130 horas de estudo ao longo de 8–12 semanas se o PCDOE for sua primeira certificação profissional GCP, ou 40–70 horas ao longo de 4–6 semanas se você já possui ACE mais experiência de SRE de plantão. O exame consiste em 50–60 questões de múltipla escolha / múltipla seleção em 120 minutos, entregues através da Pearson VUE (o Google migrou de Kryterion / Webassessor no início de 2026).
O obstáculo mais comum são as questões de filosofia SRE — a resposta esperada do Google frequentemente depende de distinções sutis (quando gastar o orçamento de erro vs. quando congelar as implantações, quando a redução de esforço repetitivo vale a pena automatizar vs. aceitar). O segundo obstáculo são os padrões de produção do GKE, especialmente o design de pool de nós, PodDisruptionBudgets e Workload Identity. 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 cobertura de Cloud Deploy, Config Sync / GitOps e cenários GKE Autopilot atualizados. Peso do domínio de filosofia SRE expandido.
Atualização importante que introduziu o Cloud Build como a principal interface de CI e alinhou o conteúdo de SLO / orçamento de erro com o SRE Workbook.
PCDOE (Google Cloud Professional Cloud DevOps Engineer) é 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.
PCDOE é 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 PCDOE é Não publicado. O exame contém 50 questões e dura 2 h.
A taxa do exame PCDOE é $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 PCDOE. 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.