Google ACE: Contêineres, Hospedagem de Aplicativos e Plataformas Serverless — 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

O Google Cloud oferece uma gama de plataformas para executar contêineres e aplicações, desde serverless totalmente gerenciado até clusters Kubernetes configuráveis. Selecionar e operar a plataforma correta exige a compreensão dos planos de controle, modelos de escalonamento, mecanismos de lançamento, redes e segurança. Esta seção consolida orientações operacionais para Google Kubernetes Engine (GKE), Artifact Registry, Cloud Run, App Engine e Cloud Functions, juntamente com padrões para segredos, rollouts seguros e diagnósticos.

Kubernetes Engine: Clusters, Workloads e Redes

Os clusters GKE fornecem um plano de controle do Kubernetes gerenciado com pools de nós que você dimensiona e protege. Escolha o Autopilot para sobrecarga operacional mínima e padrões opinativos, ou o Standard para controle granular de nós, redes e add-ons. Use canais de lançamento e auto-upgrade de nós para atualizações previsíveis e seguras; habilite o auto-reparo de nós. Prefira o Container-Optimized OS para nós com segurança reforçada, a menos que pacotes específicos exijam o Ubuntu.

Pools de nós e agendamento
- Separe os pools de nós por classe de workload (ex: geral, GPU, spot) e use taints/tolerations para direcionar os Pods.
- Habilite o cluster autoscaler e configure o min/max por pool. Esteja ciente de que PodDisruptionBudgets e solicitações de recursos podem bloquear o scale-in ou deixar Pods pendentes se as solicitações excederem os tipos de nós disponíveis.
- Nós spot/preemptivos reduzem o custo, mas introduzem o risco de evicção; combine com orçamentos de surge do Deployment e restrições de topologia de Pod para resiliência.
Namespaces e multilocação
- Use namespaces para particionar cotas, políticas e RBAC. Aplique NetworkPolicies para restringir o tráfego leste-oeste. Imponha os padrões de Pod Security no escopo do namespace para evitar workloads privilegiadas.
Workloads
- Deployments gerenciam Pods stateless com rolling updates, orçamentos de surge/unavailable e rollbacks rápidos. Use readiness probes para controlar o tráfego e liveness/startup probes para autorrecuperação. Readiness probes mal configuradas podem causar um “blackhole” no tráfego; teste antes da produção.
- StatefulSets fornecem identidades estáveis e escalonamento ordenado para bancos de dados e sistemas baseados em quórum. Use um headless Service e uma StorageClass que suporte provisionamento dinâmico; planeje a localidade zonal de PVs.
- DaemonSets agendam um Pod por nó (ex: agentes de logging/monitoramento). Eles respeitam o autoescalonamento e eventos de “drain” e são ideais para telemetria em todo o nó.
Services e Ingress
- ClusterIP expõe DNS e balanceamento de carga dentro do cluster. NodePort é usado principalmente para solução de problemas. LoadBalancer provisiona um balanceador de carga TCP/UDP externo ou interno do Google Cloud; use o interno para serviços privados.
- O GKE Ingress configura o balanceamento de carga HTTP(S) global com certificados gerenciados, mapas de URL e Cloud Armor. Para gerenciamento de tráfego moderno, prefira o balanceamento de carga nativo de contêiner (NEG) para verificações de saúde por Pod e convergência mais rápida. Garanta que os endpoints de readiness reflitam a saúde real da aplicação; caso contrário, o backend se torna insalubre, causando erros 502.
Autoescalonamento
- O Horizontal Pod Autoscaler (HPA) escala réplicas por métricas como CPU ou métricas personalizadas via Cloud Monitoring; garanta que o Metrics Server esteja saudável. O Vertical Pod Autoscaler (VPA) pode dimensionar corretamente as solicitações; evite conflitos com o HPA usando o VPA no modo “recommendation” para workloads gerenciadas pelo HPA ou use o modo compatível HPA+VPA com cuidado.
- O Cluster autoscaler adiciona/remove nós para acomodar os Pods. Se os Pods solicitarem mais recursos do que qualquer tipo de nó oferece, eles nunca serão agendados; alinhe as solicitações/limites com os tipos de pool de nós.

Exemplos curtos:

Reverter um lançamento com falha:
- kubectl rollout undo deployment/web
Inspecionar outro contexto rapidamente:
- kubectl config use-context CONTEXT && kubectl config view

Gerenciamento de Artefatos, Segurança da Cadeia de Suprimentos e Lançamentos Seguros

O Artifact Registry hospeda imagens de contêiner por região com suporte a VPC Service Controls. Adote repositórios (ou prefixos) separados para ambientes e imponha tags imutáveis; faça o deploy pelo digest para remover ambiguidades. Integre o Cloud Build ou seu CI para construir e enviar com metadados de proveniência.

Gerenciamento de vulnerabilidades
- Habilite o Artifact Analysis para escanear imagens em busca de CVEs de SO e de linguagem. Interrompa builds ou bloqueie a promoção em caso de descobertas de alta severidade. Combine com o Binary Authorization para exigir assinaturas/atestados (ex: aprovação da política de vulnerabilidade, proveniência SLSA) antes da admissão no GKE.
Promoção de imagens
- Promova copiando um digest de imagem dos repositórios de dev para staging/prod ou retagueando em um repositório de promoção; evite a tag mutável “latest”. Automatize com gatilhos do Cloud Build condicionados a testes e resultados de varredura.
Segredos e configuração
- Prefira o Secret Manager com acesso de menor privilégio. No GKE, use o driver CSI do Secret Manager com Workload Identity para que os nós nunca vejam segredos de longa duração. Para configurações KRM, separe o ConfigMap (não secreto) do Secret (sensível) e monte como somente leitura.
- Para serverless, monte segredos através de bindings diretos do Secret Manager; evite embutir segredos em variáveis de ambiente, a menos que estritamente necessário.
Padrões de rollback e lançamento
- Kubernetes: use rolling updates com maxUnavailable=0 para não ter downtime e maxSurge ajustado à capacidade; faça canary com dois Deployments por trás de um único Service ou use uma Service mesh para porcentagens graduais. Proteja workloads críticas com PodDisruptionBudgets e minReadySeconds.
- Cloud Run e App Engine: use revisões/versões e divisão de tráfego para canaries e blue/green. Mantenha as revisões anteriores “aquecidas” para reduzir a latência de rollback.
- Modos de falha: desvio de tags mutáveis, lacunas no tempo de varredura e readiness probes mal especificadas são causas comuns de interrupções. Use digests de imagem, verificações pré-deploy e sondas de saúde sintéticas.

Plataformas de Aplicações Serverless

O Cloud Run fornece computação nativa de contêineres e orientada a requisições, com escalonamento automático para zero e imposição de identidade por requisição.

Serviços (services) e jobs do Cloud Run
- Serviços lidam com HTTP; a concorrência controla o número de requisições simultâneas por instância (ajuste para latência vs. eficiência). Jobs lidam com processamento em lote/cron que não seja HTTP e podem ser paralelizados.
- Revisões (revisions) são snapshots imutáveis. A divisão de tráfego (traffic splitting) permite implantações canary por porcentagem. Defina um número mínimo de instâncias (min instances) para reduzir cold starts; use a alocação de CPU durante a inatividade (idle) se trabalho em segundo plano for necessário.
- Identidade: atribua uma service account dedicada por serviço/revisão com o menor privilégio possível (least privilege). Restrinja a invocação via IAM (papel Cloud Run Invoker) ou torne-o público se necessário. Para autenticação de usuário final, use tokens assinados do IAP ou a autenticação integrada do Cloud Run com o Identity Platform.
Rede (Networking)
- Use conectores de VPC Serverless (Serverless VPC connectors) para acessar recursos em VPCs privadas. Escolha o egresso (egress): todo o tráfego pelo conector ou apenas os intervalos privados RFC1918. Esteja ciente das cotas de vazão (throughput) do conector; dimensione o tamanho do conector e alinhe-o regionalmente com o serviço. Para saída para a internet com recursos que possuem apenas IP privado, combine com o Cloud NAT.
- O Private Service Connect pode consumir serviços de produtores (producer services) de forma privada ou expor endpoints internos. Para ingestão via HTTP(S) externo, use o Cloud Load Balancing com NEGs serverless.

O App Engine oferece dois ambientes:

Standard
- Em sandbox, escala rapidamente e suporta escalonamento automático, básico ou manual. O escalonamento automático com min_idle_instances fornece capacidade pré-aquecida. Cold start rápido e modelo de implantação simples; personalizações limitadas no nível do SO e um conjunto fixo de runtimes.
Flexible
- Executa Docker em VMs do Compute Engine com mais controle sobre bibliotecas de sistema e rede. Ciclo de vida da instância mais lento e custo base mais alto; adequado quando runtimes personalizados ou bibliotecas nativas são necessários.
Serviços (services) e versões (versions)
- Divida o tráfego por versão (aleatório, por cookie ou por IP). Cada serviço pode escalar de forma independente. Use implantações graduais (gradual rollouts) e mantenha uma versão anterior para rollback instantâneo.

O Cloud Functions fornece funções de propósito único e orientadas a eventos.

Gatilhos (Triggers): Pub/Sub, Cloud Storage, HTTP, Eventarc para diversas fontes. Torne os handlers idempotentes; alguns gatilhos tentam novamente em caso de falha, levando ao processamento duplicado.
Configuração do runtime: variáveis de ambiente, integrações com o Secret Manager, número máximo de instâncias (max instances), memória/CPU. Controle a concorrência para funções HTTP para equilibrar latência e custo.
Armadilhas comuns: concorrência ilimitada ou efeitos colaterais não idempotentes causam duplicação de dados; garanta o uso de DLQs para o Pub/Sub; defina timeouts apropriados.

Seleção de Plataforma, Rede e Responsabilidade Operacional

Selecione uma plataforma com base no controle necessário, nas características de escalabilidade, nas necessidades de portabilidade e no orçamento de operações.

Controle vs. sobrecarga (overhead)
- Maior controle: GKE Standard (SO do nó, rede, add-ons de segurança) com a sobrecarga operacional correspondente.
- Equilibrado: GKE Autopilot (sem gerenciamento de nós, segurança opinativa).
- Menor sobrecarga: Cloud Run, App Engine, Cloud Functions (sem nós, escalabilidade gerenciada), mas limitados pelos modelos de tempo de execução (runtime) e de requisição.
Escalabilidade e adequação da carga de trabalho (workload)
- Cargas de trabalho com picos de requisições: Cloud Run/App Engine Standard se destacam; Functions para manipuladores orientados a eventos.
- Rede stateful ou personalizada: GKE com StatefulSets e recursos de CNI.
- Portabilidade: contêineres no GKE/Cloud Run; Functions são menos portáteis devido ao modelo FaaS.
Rede serverless, egresso e serviços privados
- Use conectores VPC para acesso privado; monitore a utilização do conector para evitar throttling. Defina o egresso como “all” (todos) apenas quando necessário; caso contrário, limite a faixas de IP privadas para reduzir custos e riscos.
- Para ingresso privado, considere o balanceamento de carga HTTP(S) interno com NEGs serverless ou o Private Service Connect.
- Para controle de exfiltração de dados, utilize em conjunto com o VPC Service Controls onde for compatível e restrinja as rotas de egresso por meio de firewall e do Cloud NAT.
Diagnóstico e responsabilidade operacional
- Padronize o uso do Cloud Logging com logs estruturados (JSON) e IDs de trace/span entre os serviços para correlação. Use painéis do Cloud Monitoring, verificações de tempo de atividade (uptime), SLOs e políticas de alerta.
- Para o GKE: habilite o Cloud Ops for GKE, colete métricas de aplicativos via Prometheus ou Cloud Monitoring e use DaemonSets para telemetria no nível do nó.
- Para serverless: aproveite os logs de requisição integrados, o Error Reporting, o Trace e o Profiler. Defina SLOs por serviço e alertas de latência, taxa de erros e saturação (concorrência, CPU da instância).
- Modelo de responsabilidade (ownership): defina quem é responsável pelos parâmetros de tempo de execução (runtime) (escalabilidade, concorrência), IAM e pipelines de lançamento (release). Teste regularmente rollbacks e cenários de desastre.

Cenário de Problema Prático

A Acme Retail planeja expor uma nova API de checkout enquanto moderniza seus serviços internos. Requisitos: API pública de baixa latência com lançamentos canário (canary rollouts), acesso privado a um banco de dados de inventário interno em uma VPC, imposição de segurança na cadeia de suprimentos (supply chain) e rollback claro com sobrecarga operacional mínima.

Escolha o Cloud Run para a API pública e o GKE Autopilot para o serviço de inventário interno.

Justificativa: O Cloud Run minimiza a sobrecarga operacional para HTTP stateless, suporta revisões e divisão de tráfego; o GKE Autopilot fornece recursos do Kubernetes para serviços stateful/internos sem gerenciamento de nós.

Compile, verifique e armazene imagens no Artifact Registry com proveniência.

Justificativa: O Cloud Build produz as imagens de contêiner; o Artifact Analysis as verifica em busca de CVEs. O armazenamento de digests e proveniência permite que o Binary Authorization imponha que apenas imagens verificadas e assinadas sejam executadas.

Imponha políticas de admissão.

Justificativa: Habilite o Binary Authorization no cluster GKE para exigir assinaturas e atestados de política. Para o Cloud Run, configure a automação de implantação para condicionar a promoção à aprovação na política de vulnerabilidades.

Configure a rede com um Serverless VPC connector e o Cloud NAT.

Justificativa: A API do Cloud Run precisa alcançar o serviço de inventário e o Cloud SQL de forma privada. Um conector VPC permite egresso privado RFC1918; o Cloud NAT fornece saída para a internet para download de dependências sem IPs externos em recursos privados. Mantenha o conector e os serviços na mesma região e dimensione corretamente sua taxa de transferência (throughput).

Proteja identidades e permissões.

Justificativa: Atribua uma conta de serviço (service account) dedicada ao serviço do Cloud Run com o menor privilégio (por exemplo, Cloud SQL Client, permissões de invocação para endpoints internos, se necessário). Para o GKE, use o Workload Identity para que os Pods assumam contas de serviço sem credenciais no nível do nó.

Implemente lançamentos (releases) e rollbacks seguros.

Justificativa: Implante a API em uma nova revisão do Cloud Run e divida 5% do tráfego para o canário (canary). Monitore a latência, a taxa de erros e a saturação; em seguida, aumente para 100% ou reverta instantaneamente (rollback) retornando o tráfego para a revisão anterior. No GKE, use atualizações contínuas (rolling updates) do Deployment com readiness probes e um pequeno Deployment canário por trás do mesmo Service para validar antes do lançamento completo.

Configure a observabilidade e os SLOs.

Justificativa: Emita logs JSON estruturados com IDs de trace de ambas as plataformas para o Cloud Logging. Crie SLOs de latência p95 e taxa de erros 5xx; anexe políticas de alerta. Use o Error Reporting e o Trace para análise de causa raiz. Para o GKE, implante um DaemonSet para métricas de nó e habilite o Cloud Ops for GKE.

Valide os modos de falha e a capacidade.

Justificativa: Faça testes de carga para verificar a taxa de transferência (throughput) do conector VPC, a concorrência do Cloud Run e o comportamento do HPA do GKE. Confirme a precisão das readiness probes para evitar blackholing. Teste os caminhos de negação do Binary Authorization e o rollback de imagem por digest para garantir a recuperabilidade sob a imposição de segurança na cadeia de suprimentos.

Essa abordagem entrega uma API pública segura e com baixa sobrecarga operacional, serviços internos controlados, rede privada, segurança de cadeia de suprimentos (supply chain) aplicável e rollback rápido, alinhada com as melhores práticas operacionais do Google Cloud.

← Compute Engine e Operações de Máquinas Virtuais · Todos os domínios · Redes VPC →

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