Google PCA: DevOps, Engenharia de Entrega e Infraestrutura como Código — 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

DevOps, Engenharia de Entrega (Delivery Engineering) e Infraestrutura como Código (IaC) no Google Cloud focam em entregar continuamente alterações confiáveis com forte rastreabilidade, automação e segurança. As arquiteturas devem ser otimizadas para ciclos de feedback curtos, implantações repetíveis, infraestrutura imutável e barreiras de proteção (guardrails) que escalam com a organização. No Google Cloud, isso normalmente combina as melhores práticas de controle de versão; CI com o Cloud Build; gerenciamento de artefatos com o Artifact Registry; CD com o Cloud Deploy; Kubernetes com o GKE usando manifestos, Helm ou Kustomize; GitOps para controle de desvio de configuração; e IaC com Terraform ou modelos de implantação do Google Cloud. A excelência operacional requer entrega progressiva (blue-green, canary, divisão de tráfego e feature flags), controles da cadeia de suprimentos de software (escaneamento, proveniência, assinatura), portões (gates) de teste e implantação, e governança que equilibra velocidade, segurança, auditabilidade e propriedade.

CI/CD, controle de versão e orquestração de lançamentos

Princípios de CI/CD
- Manter a branch master/main pronta para lançamento; praticar o desenvolvimento baseado em tronco (trunk-based) com feature branches de curta duração.
- Automatizar build, teste, escaneamento e empacotamento a cada alteração; exigir revisão de código com aprovações obrigatórias e verificações de status.
- Manter a rastreabilidade completa desde o commit → build → digest do artefato → lançamento no ambiente; incorporar SHAs de commit e metadados de build nas imagens e anotações de implantação.
- Modos de falha: branches de longa duração, transferências manuais, testes instáveis (flaky), builds não reproduzíveis e falta de imutabilidade dos artefatos levam a surpresas tardias e rollbacks.
Controle de versão, ramificações (branching), pull requests, revisão de código e rastreabilidade
- Usar branches protegidas, revisões obrigatórias e assinatura de commits. Marcar (tag) os lançamentos e manter um changelog gerado a partir dos commits de merge.
- Aplicar CODEOWNERS e metadados de propriedade de serviço para reforçar a responsabilidade de domínio.
- Conectar commits a issues e implantações; exportar logs e metadados de CI/CD para o Cloud Logging e o BigQuery para auditoria e métricas DORA.
Cloud Build
- Gatilhos (Triggers): disparam em eventos do Git (branch, tag, PR), invocações manuais ou via Pub/Sub. Parametrizar com substituições para versão, ambiente e feature flags para manter os pipelines DRY (Don’t Repeat Yourself).
- Passos de build (Build steps): executam builders oficiais ou contêineres que você define; usar passos paralelos quando independentes para reduzir a latência; usar caches para dependências de linguagem para acelerar os builds.
- Artefatos (Artifacts): enviar imagens para o Artifact Registry com tags e digests imutáveis; armazenar SBOMs e logs de build; publicar relatórios de teste como artefatos de build.
- Identidades de build seguras: executar o Cloud Build com uma conta de serviço dedicada com o mínimo de privilégios e Workload Identity Federation por repositório, sempre que possível. Para redes privadas ou para evitar egresso, use Private Pools. Limitar as chaves de conta de serviço; preferir tokens de curta duração.
- Exemplo (resumido):
  - cloudbuild.yaml:
    - steps:
      - name: gcr.io/cloud-builders/docker args: [build, -t, $REGION-docker.pkg.dev/$PROJECT/app/web:$COMMIT_SHA, .]
      - name: gcr.io/cloud-builders/docker args: [push, $REGION-docker.pkg.dev/$PROJECT/app/web:$COMMIT_SHA]
    - substitutions:
      - _ENV=staging
Cloud Deploy
- Lançamentos (Releases) e alvos (targets): modelar um pipeline de entrega com promoção entre alvos (ex: dev → staging → prod). Um lançamento (release) captura uma referência de artefato imutável e a configuração de implantação.
- Aprovações e promoção: exigir aprovações manuais ou automatizadas com controle baseado em papéis (role-based). A promoção deve ser uma ação rápida e de baixo risco, pois o artefato e os manifestos não são alterados.
- Rollout e rollback Canary: definir estratégias para exposição progressiva, verificações de saúde (health checks) e rollback automático em caso de erros de SLO. Registrar cada promoção, aprovador e resultado de verificação para fins de auditoria.
- Modos de falha: artefatos mutáveis entre ambientes, kubectl manual em produção ou pular a verificação pré-implantação causam desvios (drift) e interrupções não rastreáveis.

Infraestrutura como Código e gerenciamento de configuração

Terraform
- Módulos: capture padrões reutilizáveis (ex: VPCs, clusters GKE, contas de serviço, bindings do IAM). Versione e fixe os releases dos módulos; publique registros de módulos internos.
- Estado remoto (remote state): armazene no Cloud Storage com versionamento, política de retenção e CMEK; habilite o travamento (locking); restrinja o acesso via IAM e acesso uniforme no nível do bucket; faça backup do estado.
- Planos e verificações de política: execute terraform fmt/validate/plan em CI; exija revisão humana do plano; aplique política como código (OPA/Conftest, Sentinel ou Policy Controller) para bloquear violações (ex: buckets públicos, bindings de IAM amplos).
- Promoção de ambientes: use workspaces separados ou estados/backends separados por ambiente; promova as alterações através das mesmas versões de módulos e variáveis; nunca edite recursos na nuvem manualmente. Entradas sensíveis (sensitive inputs) devem vir do Secret Manager ou de automação, nunca codificadas diretamente (hardcoded).
- Modos de falha: vazamento de segredos (secrets) para o estado, alterações concorrentes sem travamento (locking), desvio (drift) por edições fora de banda (out-of-band) e dependências implícitas que quebram a destruição/substituição (destroy/replace).
Modelos de implantação e configuração declarativa do Google Cloud
- Use ferramentas declarativas (Terraform, Google Cloud Deployment Manager ou Kubernetes Configuration as Code) para definir o estado desejado em vez de scripts com passos imperativos.
- Prefira infraestrutura imutável: substitua os modelos de instância e faça o roll out de MIGs; implemente novos Deployments do GKE em vez de aplicar patches nos pods existentes. Padrões imutáveis simplificam o rollback e a auditoria.
- O Deployment Manager suporta modelos Jinja/Python para recursos do Google Cloud, mas é limitado ao Google Cloud; o Terraform oferece um ecossistema mais amplo e ferramentas de política. A escolha deve ser baseada na padronização organizacional e nas habilidades da equipe.
Manifestos Kubernetes, Helm, Kustomize e GitOps
- Manifestos: mantenha modelos base com sobreposições (overlays) de ambiente; parametrize apenas o que deve variar por ambiente (ex: réplicas, limites, endpoints).
- Helm: empacote, modele e versione serviços com charts; trave as dependências; fixe os digests das imagens. Modo de falha: o excesso de modelagem (over-templating) obscurece a intenção e complica a revisão.
- Kustomize: gerencie sobreposições (overlays) (base + patches de ambiente); mais simples que o Helm quando o Kubernetes puro é suficiente.
- GitOps: um controlador (ex: Config Sync, Argo CD, Flux) reconcilia continuamente os clusters com o estado desejado no Git; cada alteração é um PR com revisão e uma trilha de auditoria. Detecte e corrija o desvio (drift) automaticamente.

Entrega progressiva, cadeia de suprimentos (supply chain), testes e verificação

Feature flags e gerenciamento de tráfego
- Feature flags desacoplam a implantação (deploy) do lançamento (release); use para exposição gradual, testes A/B e chaves de desativação de emergência (kill switches). Garanta que os estados das flags sejam versionados e auditáveis; remova flags obsoletas.
- Divisão de tráfego (traffic splitting): no Cloud Run, use roteamento baseado em porcentagem entre as revisões; no GKE, use service mesh ou controladores de ingress que suportem roteamento ponderado. Para APIs sob um único hostname/TLS, mantenha serviços de backend separados por caminho (path) atrás do HTTP(S) Load Balancer; o roteamento por caminho isola de forma limpa as versões antiga e nova, preservando uma única URL e certificado.
- Blue-green: execute duas pilhas (stacks) prontas para produção; alterne o tráfego atomicamente via balanceador de carga, seletores de serviço ou tráfego de revisão do Cloud Run. Permite rollback instantâneo, mas dobra o custo em estado de repouso (steady-state).
- Canary e rollout progressivo: aumente gradualmente o tráfego a partir de uma pequena fatia enquanto mede os sinais de ouro (golden signals) e os KPIs de negócio; automatize o rollback em caso de regressão.
Controles da cadeia de suprimentos de software (software supply-chain)
- Análise de imagens (image scanning): habilite a análise de vulnerabilidades do Artifact Analysis; falhe os builds em caso de vulnerabilidades críticas ou imagens base sabidamente ruins; mantenha uma cadência de patches.
- Proveniência e assinatura: gere proveniência de build compatível com SLSA no Cloud Build; assine artefatos com o Cosign; aplique políticas do Binary Authorization que exijam atestados antes da implantação.
- Gerenciamento de dependências: fixe versões e digests, mantenha SBOMs, armazene localmente (vendor) dependências críticas e verifique checksums. Os modos de falha incluem desvio (drift) de dependências transitivas e registros (registries) comprometidos.
Pirâmide de testes, portões de implantação (deployment gates) e verificação pós-implantação
- Pirâmide: enfatize testes de unidade rápidos; adicione testes de integração e de contrato; execute testes de ponta a ponta (end-to-end) direcionados. Mantenha os dados de teste realistas e desidentificados (use o Cloud DLP para remover PII).
- Portões de implantação (deployment gates): aplique limites para taxa de aprovação de testes, status de vulnerabilidade, conformidade com políticas e revisão de código antes da promoção; exija aprovação manual para produção quando o risco for elevado.
- Verificação pós-implantação: execute smoke tests, verificações sintéticas e análise canary usando o Cloud Monitoring, Error Reporting e Trace. Se os KPIs se degradarem, acione um rollback automatizado e abra um incidente com o contexto capturado.
- Diagnósticos operacionais: implante o agente do Cloud Logging onde necessário e instrumente os serviços para o Trace e o Debugger. Mantenha runbooks para remediação segura (ex: redimensionar um disco persistente online e executar resize2fs com tempo de inatividade mínimo).

Governança, segurança, auditabilidade e propriedade

Velocidade com segurança
- O desenvolvimento baseado em tronco (trunk-based) com PRs de curta duração e revisão obrigatória mantém o fluxo sem sacrificar a qualidade.
- Pipelines de autoatendimento com templates para stacks comuns (GKE + Helm, Cloud Run, Dataflow) aceleram as equipes e reduzem o risco de soluções personalizadas.
Acesso, identidade e aprovações
- Use contas de serviço (service accounts) dedicadas por estágio do pipeline com o mínimo de privilégios e Workload Identity Federation; evite chaves estáticas.
- Separe as funções: desenvolvedores constroem; gerentes de release aprovam a promoção para produção; operadores de tempo de execução são donos da configuração de tempo de execução e dos orçamentos.
Auditabilidade e conformidade
- Exporte os logs do Cloud Build, Cloud Deploy e Cloud Audit Logs para o BigQuery. Use visualizações de dataset (views) e o IAM para compartilhar dados de auditoria com escopo definido com os auditores. Retenha métricas a longo prazo exportando-as para o Cloud Storage ou BigQuery de acordo com a política.
- Registre os digests dos artefatos nos metadados da implantação. Mantenha SBOM (Software Bill of Materials) e proveniência de ponta a ponta para cada release.
Propriedade e SLOs
- Cada serviço tem um proprietário, uma escala de plantão, SLOs e orçamentos de erro (error budgets) que controlam os releases. Vincule as políticas de implantação à conformidade com os SLOs para evitar o envio de alterações quando o orçamento de erro estiver esgotado.
Trade-offs e armadilhas comuns
- Custo do blue-green vs. velocidade de rollback; confiança do canary vs. tempo para o release completo.
- Consistência do GitOps vs. flexibilidade operacional; permita quebras de emergência (break-glass) controladas com logs e PRs de acompanhamento.
- Excesso de templates reduz a legibilidade; mantenha a configuração explícita e mínima.
- A política centralizada evita configurações incorretas, mas deve ser implementada iterativamente para não bloquear as equipes desnecessariamente.

Cenário de Problema Prático

Empresa: Borealis Fintech

Desafio: A Borealis está lançando uma nova API de pagamentos no GKE, mantendo as versões v1 e v2 sob o mesmo nome de host e TLS. Eles precisam de rastreabilidade de ponta a ponta, entrega progressiva com canary e feature flags, controles rigorosos da cadeia de suprimentos (supply-chain) e promoções auditadas entre os ambientes de dev, staging e prod. Eles também querem usar GitOps para a configuração do cluster e Terraform para os recursos da plataforma.

Abordagem:

Estabelecer controle de versão e estratégia de branches
- Criar um monorepo com diretórios de serviço e um repositório de infraestrutura separado. Impor a proteção do branch main, revisões de PR obrigatórias, CODEOWNERS e commits assinados. Justificativa: fluxo baseado em tronco (trunk-based) com propriedade clara e histórico pronto para auditoria.
Construir artefatos com o Cloud Build e o Artifact Registry
- Definir o cloudbuild.yaml para construir e enviar imagens com a tag $COMMIT_SHA e anotações de SBOM e proveniência. Usar uma conta de serviço (service account) dedicada do Cloud Build com privilégio mínimo e um Pool Privado (Private Pool). Justificativa: builds reproduzíveis e isolados com digests rastreáveis.
- Exemplo:
  - gcloud artifacts repositories create app –repository-format=docker –location=us
Implementar controles da cadeia de suprimentos de software (supply-chain)
- Habilitar a verificação de vulnerabilidades no Artifact Registry. Gerar proveniência e assinar imagens com o Cosign nas etapas de pós-build do Cloud Build. Configurar o Binary Authorization para exigir assinaturas e aprovação na verificação antes da implantação no GKE. Justificativa: bloquear artefatos não confiáveis ou vulneráveis no momento da aplicação da política.
Modelar a entrega com o Cloud Deploy
- Definir um pipeline de entrega com alvos (targets) dev, staging, prod e uma estratégia de canary para prod. Exigir aprovação manual para produção com aprovadores baseados em papéis (roles). Justificativa: promoção imutável e aprovações auditáveis.
- clouddeploy.yaml (trecho):
  - strategy:
    - canary:
      - canaryDeployment:
        percentages: [5, 25, 50, 100]
Rotear as APIs v1 e v2 sob o mesmo nome de host
- Configurar um Balanceador de Carga HTTP(S) externo com serviços de backend separados para os caminhos /v1 e /v2, cada um apontando para o NEG do GKE correspondente. Justificativa: isolamento limpo baseado em caminho, mesmo certificado e DNS, e capacidade de implantação independente.
- Exemplo (trecho):
  - gcloud compute url-maps add-path-matcher api-map –path-matcher-name api-pm –default-service v1-bes –path-rules="/v1/=v1-bes,/v2/=v2-bes"
Gerenciar a infraestrutura com o Terraform
- Criar módulos para VPC, GKE, Artifact Registry, contas de serviço e IAM. Armazenar o estado remoto em um bucket do Cloud Storage protegido por CMEK com versionamento e retenção. Aplicar políticas OPA no CI para prevenir alterações arriscadas. Justificativa: provisionamento de plataforma reutilizável, revisável e governado.
- backend “gcs” { bucket = “borealis-tf-state” prefix = “prod” }
Configurar o Kubernetes com Helm/Kustomize e GitOps
- Manter manifestos base para a API e sobreposições (overlays) por ambiente usando o Kustomize. Usar o Config Sync ou o Argo CD para reconciliar os clusters com o estado do Git. Justificativa: operações declarativas, auditáveis e resistentes a desvios (drift).
Entrega progressiva com canary e feature flags
- Usar o canary do Cloud Deploy para produção e um SDK de feature flags (OpenFeature) para controlar a nova lógica. Iniciar com 5% do tráfego, promover automaticamente com base em SLOs saudáveis; reverter automaticamente em caso de degradação e usar a flag como um interruptor de emergência (kill switch). Justificativa: reduzir o raio de impacto (blast radius) e desacoplar a implantação (deploy) do lançamento (release).
Portões de qualidade (Quality gates) e verificação
- Estágios do pipeline: testes unitários → testes de integração em ambiente efêmero → verificação de contêiner → checagem de políticas → testes de ponta a ponta em staging → canary em produção com verificação automatizada baseada em SLOs (Cloud Monitoring, Error Reporting, Trace). Justificativa: feedback rápido no início, segurança robusta antes da produção e verificações de saúde objetivas pós-implantação.
Operações, logs e auditoria
- Instalar agentes do Cloud Logging/Monitoring para VMs de suporte e habilitar logs/métricas de workloads do GKE. Exportar logs de CI/CD e de Auditoria para o BigQuery com visualizações de escopo definido para auditores. Manter runbooks (incluindo procedimentos seguros de rollback e de troca de emergência de DNS ou LB). Justificativa: observabilidade para remediação rápida e evidências prontas para conformidade.

Este design preserva a velocidade com um fluxo baseado em tronco (trunk-based) e pipelines automatizados; a segurança com canary, feature flags e Binary Authorization; a auditabilidade com artefatos imutáveis, aprovações e logs centralizados; e a propriedade clara por meio de CODEOWNERS e ambientes controlados por GitOps.

← Operações · Todos os domínios · Custo →

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