Google PCD: Entrega Contínua, Configuração e Automação de Infraestrutura — Guia de estudos

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

Faz parte do Google Professional Cloud Developer — Guia de estudos. Pratique com respostas verificadas no centro de exames da Google, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

A entrega contínua no Google Cloud integra automação de build, gerenciamento de artefatos, orquestração de implantação, infraestrutura como código e governança robusta para entregar alterações de forma repetida e segura. Pipelines robustos combinam artefatos imutáveis e configuração declarativa com políticas e auditabilidade. Esta seção explica decisões de design, práticas operacionais e modos de falha comuns ao implementar o Cloud Build, Cloud Deploy, Artifact Registry, Terraform, Kubernetes, feature flags e controles de governança de ponta a ponta.

Orquestração de Build e Implantação

Cloud Build

• Gatilhos (Triggers): Conecte builds a eventos de origem (pushes em branches, tags, PRs) ou agendamentos. Prefira regex de branch ou tag para garantir que apenas as refs desejadas sejam acionadas. Os gatilhos podem ser executados com uma conta de serviço específica para aplicar o princípio do menor privilégio; não dependa da padrão se os builds precisarem de acesso amplo a APIs.
• Etapas de build (Build steps): Cada etapa é executada em um contêiner. Use builders específicos (purpose-built builders) (docker, gcloud) ou builders personalizados quando o conjunto de ferramentas padrão for insuficiente. Separe as etapas para compilação, testes unitários, testes de integração, lint, varreduras de segurança e empacotamento de artefatos para que as falhas sejam atribuíveis e o cache seja usado de forma eficaz.
• Substituições (Substitutions): Use variáveis integradas (PROJECT_ID, SHORT_SHA) e substituições personalizadas (com prefixo $_) para builds parametrizados. Mantenha valores específicos do ambiente fora da lógica de build; passe-os como substituições ou resolva-os posteriormente durante a implantação.
• Contas de serviço (Service accounts): A conta de serviço do Cloud Build (PROJECT_NUMBER@cloudbuild.gserviceaccount.com) requer papéis (roles) explícitos (por exemplo, gravador do Artifact Registry, administrador de release do Cloud Deploy). Atribua os papéis mínimos e escopo por projeto. Para recursos privados, use Pools Privados (Private Pools) com conectividade VPC.
• Artefatos (Artifacts): Publique imagens imutáveis no Artifact Registry e, opcionalmente, faça upload de artefatos que não são contêineres para o Cloud Storage através da seção artifacts. Tagueie as imagens com uma versão semântica e com o digest do commit; use os digests das imagens nas implantações para evitar o desvio de tags (tag drift).

Exemplo de configuração do Cloud Build:

• cloudbuild.yaml: steps:

  • name: gcr.io/cloud-builders/docker args: [“build”,"-t","$REGION-docker.pkg.dev/$PROJECT_ID/app/app:${SHORT_SHA}","."]
  • name: gcr.io/cloud-builders/docker args: [“push”,"$REGION-docker.pkg.dev/$PROJECT_ID/app/app:${SHORT_SHA}"]
  • name: gcr.io/cloud-builders/gcloud args: [“deploy”,“releases”,“create”,“app-${SHORT_SHA}”,"–delivery-pipeline=app-pipeline","–images=app=$REGION-docker.pkg.dev/$PROJECT_ID/app/app@sha256:${COMMIT_SHA}"] substitutions: _REGION: us-central1 serviceAccount: projects/$PROJECT_ID/serviceAccounts/cb-deployer@$PROJECT_ID.iam.gserviceaccount.com

• Exemplo de gatilho (trigger): gcloud builds triggers create cloud-source-repositories –repo=my-repo –branch-pattern=^main$ –build-config=cloudbuild.yaml –service-account=cb-deployer@$PROJECT_ID.iam.gserviceaccount.com

Cloud Deploy

• Pipelines de entrega (Delivery pipelines) definem estágios (stages) e alvos (targets) ordenados. Os alvos referenciam clusters GKE, serviços do Cloud Run ou outros runtimes suportados. Marque os estágios de produção com requireApproval para controlar a promoção.
• Rollouts mapeiam uma release para um alvo; a promoção (promotion) avança uma release através dos alvos. Use entrega progressiva (canary, blue/green) e hooks para verificações pré e pós-implantação (predeploy/postdeploy).
• Modos de falha: Usar tags mutáveis causa atualizações não intencionais; sempre fixe os digests. A falta de permissões IAM para a conta do implantador (deployer) bloqueia os rollouts. Manifestos não renderizáveis ou desvio de configuração (config drift) específico do ambiente levam a falhas na promoção; valide os manifestos durante o build.

Exemplos de definições do Cloud Deploy:

• delivery-pipeline.yaml: apiVersion: deploy.cloud.google.com/v1 kind: DeliveryPipeline metadata: name: app-pipeline serialPipeline: stages:

  • targetId: dev
  • targetId: prod strategy: standard: verify: true requireApproval: true

• targets.yaml: apiVersion: deploy.cloud.google.com/v1 kind: Target metadata: name: dev gke: cluster: projects/PROJECT/locations/REGION/clusters/DEV_CLUSTER

  Definição do alvo de produção

  apiVersion: deploy.cloud.google.com/v1 kind: Target metadata: name: prod gke: cluster: projects/PROJECT/locations/REGION/clusters/PROD_CLUSTER

• Release e promoção: gcloud deploy releases create app-20260903-1 –delivery-pipeline=app-pipeline –region=us-central1 –images=app=us-central1-docker.pkg.dev/PROJECT/app/app@sha256:IMAGE_DIGEST gcloud deploy releases promote –delivery-pipeline=app-pipeline –release=app-20260903-1 –region=us-central1

Artefatos e Integridade da Cadeia de Suprimentos (Supply Chain)

Artifact Registry

• Repositórios: Crie repositórios separados por equipe ou ambiente para delimitar o escopo de IAM e limpeza. Use repositórios regionais próximos aos builders e runtimes para reduzir a saída de dados (egress) e a latência. Os formatos de pacote incluem imagens Docker e pacotes de linguagem (Maven, npm, PyPI).
• Retenção: Defina políticas de limpeza para remover tags antigas ou não referenciadas, mantendo uma janela de segurança para rollback. Evite uma retenção agressiva que remova a última versão sabidamente boa.
• Proveniência (Provenance) e SBOM: Habilite a proveniência de build para que as imagens carreguem atestados (attestations) compatíveis com SLSA. Gere SBOMs durante o build e armazene-os como atestados, melhorando a triagem de vulnerabilidades.
• Análise de vulnerabilidades (Vulnerability scanning): Habilite a análise de contêineres e interrompa o build ou bloqueie a promoção quando CVEs de alta severidade forem detectados sem correções disponíveis ou exceções de política.
• Trade-offs: Centralizar todos os artefatos em um único projeto simplifica a governança, mas pode criar um raio de impacto (blast radius); repositórios por ambiente ou por aplicação reduzem o risco, mas adicionam sobrecarga de gerenciamento.

Aplicação da cadeia de suprimentos (Supply chain enforcement)

• O Binary Authorization no GKE pode exigir atestados (por exemplo, “construído pelo Cloud Build no projeto X”, “sem CVEs críticos”). Integre com os portões (gates) do Cloud Deploy para impedir releases não conformes.
• Modos de falha: Depender de tags mutáveis, verificação desativada ou pulls não autenticados pode levar software não verificado a chegar em produção. Fixe os digests e exija atestados.

Infraestrutura como Código e GitOps

Terraform

• Configuração e módulos: Fatore módulos reutilizáveis com entradas/saídas (inputs/outputs) claras e versões semânticas. Publique os módulos em um repositório ou registro compartilhado; fixe as versões para evitar mudanças inesperadas.
• Estado (State): Use o backend do GCS para estado remoto com IAM no nível do bucket, versionamento de objetos e CMEK. Proteja o estado contra edições humanas e garanta a criptografia do estado. Evite segredos no estado lendo-os do Secret Manager no momento da aplicação (apply time) e usando fontes de dados (data sources) com moderação.

undefined

• Planos (Plans) e aplicações (applies): Execute terraform plan com -out e tenha uma revisão humana ou um portão automatizado para analisar a diferença (diff); aplique apenas o plano previamente aprovado. Use -refresh-only ou -detailed-exitcode em jobs de detecção de desvio (drift detection).
• Separação de ambientes: Use projetos, buckets de estado e contas de serviço (service accounts) separados por ambiente. Prefira um diretório por ambiente com arquivos de variáveis em vez de workspaces para organizações complexas. Nunca compartilhe o estado entre ambientes.
• Modos de falha: Aplicações concorrentes corrompem o estado; imponha a serialização com CI/CD e travamento (locking) (o GCS usa pré-condições de objeto). Alterações manuais no console causam desvio (drift); restrinja mutações diretas e execute jobs de plan periódicos.

Configuração declarativa do Kubernetes

• Manifestos: Mantenha os objetos do Kubernetes declarativos; evite imperativos do kubectl em fluxos de produção. Fixe os digests das imagens e as solicitações/limites de recursos (resource requests/limits).
• Kustomize: Use base + overlays para lidar com patches específicos de ambiente sem criar forks dos charts. kustomization.yaml (overlay):

undefined

• Helm: Use arquivos de valores (values files) por ambiente; documente a precedência (valores da linha de comando sobrescrevem os arquivos de valores, que por sua vez sobrescrevem os padrões do chart). Faça o template e a renderização em CI (skaffold render ou helm template) para que as configurações no momento da implantação (deploy-time) sejam imutáveis.
• GitOps: Armazene o estado desejado no Git. Use o Cloud Deploy ou o Config Sync para reconciliar os clusters com o Git. Os PRs (Pull Requests) se tornam a superfície de controle de mudanças com trilhas de auditoria e verificações de políticas. Evite modificações com kubectl exec que não são capturadas no Git.

Segurança de Lançamento, Configuração e Governança

Feature flags e configuração em tempo de execução

• Feature flags dissociam a implantação do lançamento; envie código inativo e habilite por coorte, porcentagem ou região. Armazene as definições dos flags em um sistema de alta disponibilidade e baixa latência (Firestore, Memorystore) e faça cache com TTLs curtos. Registre as avaliações para rastreabilidade.
• Lançamento gradual (gradual rollout): Combine a divisão de tráfego (Cloud Run) ou subconjuntos canary (GKE) com flags para minimizar o raio de impacto. Use métricas de saúde e gatilhos de rollback automatizado baseados em SLOs.
• Rollback seguro: Prefira desativações rápidas via feature flags. Para um rollback de binário, promova a última versão estável conhecida ou reaplique o digest do manifesto anterior.

Variáveis de ambiente, precedência, segredos

• A precedência comumente segue: flags de tempo de execução > variáveis de ambiente > arquivos de configuração > padrões no código. Documente e padronize isso em todos os serviços.
• Injete a configuração com ConfigMaps e variáveis de ambiente; use o Secret Manager ou Kubernetes Secrets para valores sensíveis. Rotacione-os regularmente e evite embutir segredos nas imagens.
• Exemplos de injeção de segredos:
  • Variável de ambiente do Cloud Run:

undefined

• CSI do Secret Manager no GKE:

undefined

Portões de qualidade em CI/CD

• Testes unitários rodam a cada commit; feedback rápido é primordial.
• Testes de integração rodam em ambientes efêmeros ou sandboxes com dados pré-carregados.
• Verificações de segurança: SAST, varredura de dependências, varredura de vulnerabilidades de contêineres, verificações de política de IaC (Conftest, Policy Controller). Bloqueie merges ou promoções em caso de descobertas críticas.
• Verificações de implantação: Ações de pré-implantação e pós-implantação do Cloud Deploy validam a prontidão, a segurança das migrações de banco de dados e os smoke tests.

Ramificação, revisão de código, versionamento, rastreabilidade

• Prefira o desenvolvimento baseado em tronco (trunk-based development) com feature branches de curta duração e revisões de PR obrigatórias. Imponha verificações obrigatórias e um histórico linear para fins de auditabilidade.
• Versionamento: Tags de versão semântica para lançamentos; digests de imagem e SHAs de commit para imutabilidade. Evite tags móveis como latest em implantações de produção.
• Rastreabilidade: Anote builds e lançamentos com IDs de commit, PR e ticket. Emita eventos de implantação para o Logging; anexe labels aos recursos para custos e propriedade.

Desvio de infraestrutura, política, auditoria, controle de mudanças

• Detecção de desvio (drift): Agende terraform plan -detailed-exitcode; alerte sobre códigos de saída diferentes de zero. Para clusters, o Config Sync garante a convergência eventual com o Git.
• Aplicação de políticas: Use a Organization Policy para barreiras de proteção (por exemplo, restringir IPs externos), o Policy Controller para restrições de KRM e o Binary Authorization para políticas de imagem.
• Logs de auditoria: Habilite os logs de Atividade do Administrador e de Acesso a Dados; roteie para projetos centralizados com coletores (sinks) e retenção alinhados à conformidade. O Cloud Asset Inventory alimenta o histórico de mudanças e a análise de acesso.
• Controle de mudanças: Aprovações manuais em promoções para produção, com justificativas capturadas como anotações. Janelas de congelamento podem ser codificadas como verificações de política no CI/CD. Garanta que os caminhos de rollback de emergência estejam documentados e testados.

Cenário de Problema Prático

A Acme Retail precisa implantar um novo order-service no GKE nos ambientes de desenvolvimento e produção com lançamentos canary seguros, aplicação rigorosa de políticas e rastreabilidade completa do lançamento. A equipe deve padronizar a infraestrutura gerenciada pelo Terraform, a configuração declarativa do Kubernetes com Kustomize e um CI/CD auditável usando Cloud Build e Cloud Deploy.

Abordagem:

1. Estabelecer repositórios de artefatos e identidades

• Crie repositórios regionais no Artifact Registry: order-docker-dev e order-docker-prod. Conceda à conta de serviço do Cloud Build no projeto da aplicação os papéis roles/artifactregistry.writer e aos nós de tempo de execução do GKE o papel roles/artifactregistry.reader para o repositório apropriado.
• Justificativa: Repositórios segregados reduzem o raio de impacto e simplificam as políticas de ciclo de vida. O IAM explícito evita padrões com privilégios excessivos.

2. Definir o Terraform para a infraestrutura com separação de ambientes

• Crie os diretórios terraform/envs/dev e terraform/envs/prod. Cada configuração inclui um backend do GCS com buckets de estado separados, um módulo de cluster GKE e bindings de IAM para a conta de serviço do Cloud Deploy. Execute terraform init, plan -out=plan.bin e apply plan.bin em um job de CI com portões (gated) por ambiente.
• Justificativa: Estado e projetos por ambiente evitam impacto acidental entre ambientes; arquivos de plano (plan files) suportam revisão e controle de mudanças auditável.

3. Criar a base declarativa do Kubernetes e overlays do Kustomize

• Coloque os manifestos do Kubernetes em k8s/base para Deployment, Service e HPAs com imagens fixadas (pinned) por digest. Crie k8s/overlays/dev e k8s/overlays/prod com patches para réplicas, solicitações de recursos e configuração. Use uma classe CSI do Secret Manager para as credenciais do banco de dados.
• Justificativa: Uma fonte única de verdade com overlays elimina desvios (drift) e mantém as configurações DRY, ao mesmo tempo que permite diferenças seguras e específicas de cada ambiente.

4. Implementar o Cloud Build com etapas distintas de teste e empacotamento

• O arquivo cloudbuild.yaml inclui etapas: lint e testes unitários, testes de integração em um namespace de desenvolvimento descartável, build e push do contêiner para o repositório do ambiente, varredura de SBOM e vulnerabilidades, e geração de proveniência. O gatilho é executado em PRs para a main para testes e em merges para empacotamento. Os builds são executados com uma conta de serviço de menor privilégio, cb-deployer.
• Justificativa: Falhas precoces são baratas; separar as responsabilidades melhora a observabilidade e permite novas tentativas direcionadas. O princípio do menor privilégio reduz o risco da cadeia de suprimentos (supply chain).

5. Configurar o pipeline de entrega do Cloud Deploy com aprovação manual para produção e estratégia canary

• Defina um DeliveryPipeline com alvos de dev e prod. O estágio de prod requer aprovação e usa uma estratégia canary (por exemplo, 10% e depois 100%). Use hooks de pré-implantação para verificações de compatibilidade de esquema e smoke tests; a pós-implantação verifica os SLOs.
• Justificativa: A entrega progressiva limita o raio de impacto e introduz portões de qualidade automatizados, enquanto a aprovação manual impõe a intervenção humana para produção.

6. Conectar GitOps e aplicação de políticas

• Proteja a branch main com revisões obrigatórias e verificações aprovadas. Use restrições do Policy Controller para bloquear pods privilegiados и não permitir tags mutáveis. Habilite o Binary Authorization para exigir proveniência do Cloud Build e atestados de “sem CVEs altos” antes da admissão.
• Justificativa: A política como código (policy-as-code) impede que configurações arriscadas cheguem ao cluster e fornece uma aplicação consistente.

7. Gerenciar configuração e feature flags para um lançamento seguro

• Armazene a configuração de tempo de execução não secreta em ConfigMaps; os segredos são fornecidos via CSI do Secret Manager. Introduza uma feature flag order_new_flow lida do Firestore com um lançamento inicial de 1% em produção; os flags são armazenados em cache com TTLs curtos e registrados em log.
• Justificativa: Flags dissociam o lançamento da implantação, permitindo a desativação instantânea se surgirem problemas, sem a necessidade de fazer rollback do binário.

8. Garantir observabilidade, detecção de desvio e rastreabilidade

• Anote builds e lançamentos com o SHA do commit, número do PR e ticket de mudança. Roteie eventos do Cloud Deploy e logs de auditoria do GKE para um projeto de Logging centralizado. Jobs noturnos de terraform plan alertam sobre desvios (drift); o Config Sync monitora a divergência de KRM, reconciliando com o Git.
• Justificativa: Proveniência completa e trilhas de auditoria aceleram a resposta a incidentes; a detecção contínua de desvios mantém a integridade da infraestrutura.

9. Operar rollbacks e controle de mudanças

• Para incidentes, primeiro desabilite order_new_flow através do flag. Se necessário, promova o lançamento bem-sucedido anterior no Cloud Deploy para dev e prod. Todas as promoções para produção exigem uma referência de ticket nas anotações do lançamento e uma aprovação do SRE de plantão.
• Justificativa: Flags fornecem mitigação instantânea; lançamentos imutáveis permitem um rollback previsível. Aprovações e anotações satisfazem a governança operacional e a conformidade.

← Identidade · Todos os domínios · Observabilidade →

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

Navegar Google →