Google ACE: Implantação, Configuração e Automação — Guia de estudos

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Faz parte do Google Associate Cloud Engineer — 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 implantação, configuração e automação no Google Cloud focam na entrega de mudanças repetíveis, auditáveis e seguras. Boas práticas se baseiam em infraestrutura como código (IaC), templates declarativos, artefatos imutáveis e pipelines padronizados. A excelência operacional vem do design para idempotência, pré-visualização de alterações, imposição de políticas e planejamento de rollouts controlados com caminhos de rollback claros. As seções a seguir fornecem padrões práticos, exemplos de comandos e o raciocínio por trás das escolhas de design, incluindo armadilhas e trade-offs comuns.

Fundamentos de Infraestrutura como Código e Configuração

Princípios:

Templates declarativos descrevem o estado final desejado; as ferramentas reconciliam o estado real para corresponder. Isso melhora a idempotência, a repetibilidade e a auditabilidade.
Infraestrutura imutável implanta novas instâncias ou revisões em vez de modificar as existentes, simplificando o rollback e reduzindo o desvio (drift).
Separação de responsabilidades: parametrize valores específicos do ambiente enquanto reutiliza módulos ou templates compartilhados.

Terraform no Google Cloud:

Configuração: arquivos HCL definem recursos, variáveis e saídas. Use módulos para encapsular VPCs, contas de serviço ou clusters GKE; publique módulos compartilhados internamente para padronizar padrões.
Estado (State): Mantenha o estado remoto e versionado. Use um backend do Cloud Storage com versionamento de objetos e retenção de bucket, conforme apropriado.
- Exemplo de bloco de backend:

undefined

Modos de falha: estado local ou buckets não versionados arriscam perda de dados e escritas concorrentes. Imponha acesso de menor privilégio ao bucket de estado; prefira credenciais de curta duração e personificação de conta de serviço (service account impersonation) em vez de chaves.
Planos e Aplicações: terraform plan fornece uma pré-visualização; restrinja os applies em CI/CD com aprovação humana para produção. Use -target com moderação; o uso frequente de targeting aumenta o risco de desvio (drift).
Módulos: versione os módulos semanticamente; fixe as versões para evitar alterações não planejadas. Valide com terraform validate e verificações de política antes de aplicar.
Importações e Desvio (Drift): terraform import traz recursos existentes para o gerenciamento; siga com uma revisão cuidadosa do estado. Detecte o desvio executando terraform plan regularmente.
Execução remota: execute o Terraform em jobs do Cloud Build ou Cloud Run com Workload Identity Federation para evitar chaves de conta de serviço. Faça cache dos providers para reduzir o tempo de build.

Deployment Manager:

Embora muitas equipes padronizem o uso do Terraform, você pode encontrar o Deployment Manager. Atualize uma implantação sem tempo de inatividade (downtime) atualizando a configuração:

undefined

Padrões de configuração:

Nomenclatura: aplique nomes consistentes e analisáveis (parseable) com ambiente, região, propósito e sequência, ex: vpc-prod-usw1-core.
Labels: anexe labels como env, cost_center, owner e app a todos os recursos; imponha via política ou validação.
Tags: use tags de rede para definir o escopo das regras de firewall; evite sobrecarregar tags para identidade ou propriedade (labels são melhores).
Metadados: aproveite os metadados da instância para scripts de inicialização e configuração; prefira metadados com checksum ou flags de versão para controlar reexecuções. Evite colocar segredos (secrets) nos metadados; use o Secret Manager.

APIs, habilitação de serviços, cotas e contas de serviço:

Habilite os serviços necessários no início da automação:

undefined

Valide a margem de cota (quota) durante o planejamento; testes de escala devem incluir verificações de cota para evitar throttling.
Use contas de serviço dedicadas por carga de trabalho (workload) e ambiente; conceda papéis IAM de menor privilégio no escopo mais restrito. Prefira associação a grupos para acesso humano e personificação de conta de serviço para automação.

Pipelines de Entrega e Promoção de Artefatos

Cloud Build:

Defina etapas do Cloud Build para construir, testar e empacotar artefatos. Use substituições para valores dinâmicos e use o Secret Manager para credenciais.
Acione builds a partir de alterações no código-fonte; isole as contas de serviço de build por repositório ou ambiente e conceda apenas as permissões necessárias.
Faça cache das camadas (layers) do Docker e das dependências de linguagem para reduzir os tempos de build. Fique atento aos limites de builds concorrentes e às cotas de workers efêmeros.

Promoção de artefatos:

Armazene imagens de contêiner ou pacotes de linguagem no Artifact Registry. Promova:
- Reatribuindo tags a digests imutáveis para o ambiente (ex: :qa, :prod) ou
- Copiando artefatos para um repositório específico do ambiente.
Trade-offs: um único repositório com tags simplifica a descoberta, mas exige governança rígida; repositórios por ambiente fortalecem o isolamento e a imposição de políticas.

Cloud Deploy:

Modele um pipeline de entrega com alvos (targets) ordenados (ex: dev → qa → prod). As releases referenciam um digest de artefato e um manifesto de implantação específicos.
Para GKE e Cloud Run, o Cloud Deploy usa configurações do Skaffold para renderizar e aplicar manifestos. Configure aprovações, verificações e portões (gates).
Rollout e rollback:
- Canary com desvio de tráfego incremental reduz o raio de impacto (blast radius).
- Blue/green permite uma transição (cutover) e rollback rápidos ao custo de capacidade extra.
- Faça o rollback fixando a última release funcional; evite correções no local (in-place) que criam desvio (drift).
Modos de falha: permissões de cluster incompatíveis, APIs ausentes e erros de esquema de manifesto. Detecte antecipadamente renderizando os manifestos durante o build e validando contra as políticas do cluster.

Planejamento de alterações seguras:

Exija pré-visualização (plan ou render), testes automatizados, validação de políticas e aprovação humana para produção.
Para grupos de instâncias gerenciadas do Compute Engine, ajuste a política de atualização maxSurge/maxUnavailable e as configurações de verificação de saúde (health check) para evitar superprovisionamento quando a prontidão da aplicação é lenta.

Operações de Linha de Comando e Gerenciamento de Ambiente

Configurações do Cloud Shell e do gcloud:

O Cloud Shell fornece um ambiente de administração gerenciado com o gcloud pré-autenticado e um diretório home persistente.
Use configurações nomeadas para alternar rapidamente entre contas, projetos e regiões: gcloud config configurations create prod gcloud config set project my-prod gcloud config set compute/region us-central1 gcloud config set compute/zone us-central1-a gcloud config configurations activate prod
Inspecione a configuração ativa com gcloud config list. Para o GKE, obtenha as credenciais: gcloud container clusters get-credentials my-cluster –region us-central1

Padrões de comando do Compute:

Criar VM com um IP interno reservado: gcloud compute addresses create license-ip –region=us-central1 –subnet=default –addresses=10.0.3.21 gcloud compute instances create license-server –zone=us-central1-a –subnet=default –private-network-ip=10.0.3.21 –tags=license
Criar uma VPC personalizada, sub-rede e regra de firewall: gcloud compute networks create core –subnet-mode=custom gcloud compute networks subnets create core-us –network=core –range=10.0.0.0/20 –region=us-central1 gcloud compute firewall-rules create allow-https –network=core –allow=tcp:443 –target-tags=web

Padrões do IAM:

Conceder um papel no escopo do projeto: gcloud projects add-iam-policy-binding my-project –member=group:ops@example.com –role=roles/logging.viewer
Copiar papéis personalizados entre projetos: gcloud iam roles copy myCustomRole –source=my-dev –destination=my-prod

Padrões de Storage:

Criar um bucket e fazer upload de objetos: gcloud storage buckets create gs://backups-prod –location=us-central1 –class=coldline –uniform-bucket-level-access gcloud storage cp ./backup.tar.gz gs://backups-prod/
Configurar o ciclo de vida via arquivo e aplicar com gcloud storage buckets update --lifecycle-file=policy.json

Habilitação e verificação de API:

Habilitar o Pub/Sub para uma aplicação: gcloud services enable pubsub.googleapis.com
Listar serviços habilitados: gcloud services list –enabled

Governança, Desvio e Automação

Desvio de configuração e aplicação de políticas:

Detecte desvios executando terraform plan de forma agendada; falhe os builds em caso de alterações inesperadas.
Aplique restrições de políticas organizacionais (ex: restringir IPs externos) e valide as configurações de recursos com política como código (policy-as-code) antes do apply.
Para Kubernetes, use o Config Sync e o Policy Controller para reconciliar continuamente e barrar alterações não conformes.
Auditabilidade: utilize os logs de Admin Activity e Data Access; roteie para o BigQuery para análise. Use o Cloud Asset Inventory para consultas de estado em um ponto no tempo (point-in-time) e com viagem no tempo (time-travel).

Cotas e limites:

Inspecione as cotas por região e projeto; planeje uma margem (headroom) para autoscaling e rollouts: gcloud compute regions describe us-central1 –format=“yaml(quotas)”
Solicite aumentos antes de um crescimento planejado ou de grandes rollouts.

Tarefas operacionais automatizadas:

O Cloud Scheduler aciona endpoints HTTP, tópicos do Pub/Sub ou Workflows em uma programação cron. Garanta que os manipuladores (handlers) sejam idempotentes; configure tentativas (retries) e tópicos de mensagens mortas (dead-letter topics).
O Workflows orquestra automações de múltiplos passos entre APIs do Google com tentativas, passos paralelos e lógica de compensação.
Os jobs do Cloud Run executam tarefas em lote (batch) ou administrativas contêinerizadas sob demanda ou via Scheduler. Prefira jobs para cargas de trabalho únicas ou iterativas; use permissões mínimas na conta de serviço do job.

Segurança e observabilidade no rollout:

Incorpore verificações de saúde (health checks) e de prontidão (readiness probes) nos serviços. Para MIGs com inicialização lenta, aumente o atraso inicial (initial delay) para evitar ações de escalonamento prematuras.
Colete métricas de implantação e orçamentos de erro (error budgets); pause ou aborte automaticamente os rollouts quando os SLOs se degradarem.

Cenário de Problema Prático

A Altostrat Media precisa padronizar as implantações multi-ambiente para um serviço baseado em GKE, eliminando o desvio de configuração e garantindo um rollback rápido. Eles também precisam reservar um IP interno fixo para um servidor de licenças legado sem reconfigurar a aplicação.

Crie módulos de Terraform e estado remoto fundamentais

Implemente módulos para VPC, sub-redes, GKE, contas de serviço e regras de firewall. Configure um backend no Cloud Storage com versionamento e uma política de retenção para o bucket de estado.
Justificativa: A modularização promove o reuso e a consistência; o estado remoto e versionado permite colaboração, recuperabilidade e travamento (locking).

Habilite os serviços necessários e estabeleça identidades de automação com privilégio mínimo

Habilite compute.googleapis.com, container.googleapis.com, clouddeploy.googleapis.com, artifactregistry.googleapis.com.
Crie contas de serviço por ambiente para o Terraform, Cloud Build e Cloud Deploy; conceda papéis mínimos (ex: roles/container.admin para quem faz o deploy, não para quem faz o build).
Justificativa: A habilitação prévia e o escopo de papéis reduzem falhas de implantação e limitam o raio de impacto (blast radius).

Provisione a rede e reserve o IP legado

Com o Terraform, crie uma VPC customizada, sub-redes regionais e regras de firewall baseadas em tags de rede.
Reserve o IP interno: gcloud compute addresses create license-ip –region=us-central1 –subnet=core-us –addresses=10.0.3.21
Justificativa: A rede declarativa garante a repetibilidade; reservar o IP preserva as premissas da aplicação.

Construa os artefatos com o Cloud Build e publique no Artifact Registry

Defina o cloudbuild.yaml para executar testes, construir o contêiner, escanear e enviar um digest imutável para o Artifact Registry.
Justificativa: Artefatos imutáveis e escaneados são a base para promoções seguras e rastreabilidade (provenance).

Configure o pipeline do Cloud Deploy com alvos dev → qa → prod

Defina um pipeline de entrega e alvos (targets); referencie a configuração do Skaffold para renderizar os manifestos. Exija aprovação manual para produção e configure verificações.
Justificativa: A promoção estruturada impõe controles; políticas por alvo evitam implantações acidentais em produção.

Faça o rollout das atualizações do GKE com estratégia canary e portões de saúde

Use uma política de rollout canary para desviar 10%, depois 50% e então 100% do tráfego, dependendo das verificações de SLO e taxa de erro.
Justificativa: A entrega progressiva reduz o risco e fornece pontos de rollback naturais.

Elimine o desvio com planos agendados e verificações de política

Um job noturno executa terraform plan e um validador de política como código; alerta sobre diferenças (diffs) ou violações inesperadas.
Justificativa: A detecção precoce impede que o desvio se acumule e quebre futuros applys.

Operacionalize a VM do servidor de licenças com o IP reservado

Crie a VM vinculada ao endereço reservado e com as tags adequadas: gcloud compute instances create license-server –zone=us-central1-a –subnet=core-us –private-network-ip=10.0.3.21 –tags=license
Justificativa: Garante a alcançabilidade sem alterar a aplicação; as tags mantêm as regras de firewall com escopo restrito.

Automatize tarefas recorrentes com Scheduler, Workflows e jobs

O Cloud Scheduler aciona um Workflow para rotacionar chaves de contas de serviço onde for inevitável e para iniciar um job do Cloud Run para tarefas semanais de vacuum do banco de dados.
Justificativa: O agendamento centralizado mais a orquestração geram confiabilidade e observabilidade com tentativas e compensação.

Planeje rollbacks e valide os limiares de prontidão

Defina playbooks de rollback para promover novamente a última versão boa. Ajuste as readiness probes e, para quaisquer cargas de trabalho baseadas em MIG, aumente os atrasos iniciais da verificação de saúde para corresponder ao aquecimento (warm-up) da aplicação.
Justificativa: O rollback pré-planejado e as verificações de saúde ajustadas evitam falhas em cascata e superprovisionamento durante incidentes.

Essa abordagem alinha artefatos imutáveis, infraestrutura declarativa, promoções controladas (gated) e automação com privilégio mínimo para entregar operações seguras, auditáveis e repetíveis no Google Cloud.

← Armazenamento · Todos os domínios · Monitoramento →

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