Google PCD: Custos, Governança e Operações de Aplicações Sustentáveis — 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

Custo, governança e operações sustentáveis são inseparáveis no desenvolvimento moderno de aplicações na Google Cloud. O objetivo é expor e controlar os gastos, projetar serviços que escalem economicamente e impor barreiras de proteção (guardrails) que mantenham os ambientes seguros, em conformidade (compliant) e organizados — enquanto se equilibra desempenho e confiabilidade. Esta seção detalha mecanismos práticos (faturamento e labels, controles de autoscaling, cotas e políticas), a economia específica de cada carga de trabalho (workload) (Cloud Run, GKE, plataformas de dados) e as escolhas conscientes de sustentabilidade que reduzem o desperdício ocioso e o impacto de carbono sem prejudicar a experiência do usuário.

Controles de Custo e Visibilidade

• Contas de faturamento, labels, alocação de custos, orçamentos, alertas e visibilidade
  • Use uma conta de faturamento dedicada por unidade de negócio ou fonte de financiamento para isolar a propriedade e permitir permissões granulares. Exporte os dados de faturamento para o BigQuery para análise detalhada, previsão e chargeback.
  • Labels são pares chave-valor em recursos para atribuição de custos. Padronize as chaves dos labels (equipe, app, env, centro-de-custo) e imponha-as por meio de políticas da organização e verificações de CI. Observação: os labels não são retroativos; recursos sem labels distorcem os relatórios.
  • Use orçamentos e alertas nos níveis de conta de faturamento e de projeto. Combine limites (por exemplo, 50, 90, 100 por cento) e gatilhos baseados em previsões. Encaminhe as notificações de orçamento para o Pub/Sub e repasse para ferramentas de Chat/Ops. Orçamentos alertam; eles não impõem limites.
  • Para plataformas compartilhadas (por exemplo, GKE, BigQuery), use labels por namespace ou por job e anexe-os aos logs e ao uso para permitir showback/chargeback.

Exemplo: adicionar labels gcloud compute instances update web-01 –labels=team=payments,app=checkout,env=prod

• Cotas, limites, previsão de consumo e governança de capacidade
  • As cotas protegem os serviços e limitam custos descontrolados. Revise as cotas de serviço regularmente, dimensione-as corretamente por projeto e solicite aumentos antes de lançamentos. Implemente verificações de pré-implantação (pre-deploy) que comparem o pico de uso esperado com as cotas.
  • Faça a previsão de gastos usando a exportação do Billing mais a telemetria de uso do produto (métricas do Cloud Monitoring, métricas baseadas em logs). Modele cenários (QPS esperado, dados escaneados) e valide em pré-produção.
  • Modos de falha: atingir a cota no meio de um incidente ou lançamento de produto leva a throttling (429/403), interrupções parciais ou degradação silenciosa. Cotas superprovisionadas aumentam o raio de impacto (blast radius) de jobs defeituosos.

Exemplo: listar cotas do Compute Engine gcloud services quota list
–service=compute.googleapis.com
–consumer=projects/$PROJECT_ID

Elasticidade e Economia da Computação

• Dimensionamento adequado, autoescalonamento, faturamento por requisição, uso comprometido e capacidade spot

  • Faça o dimensionamento adequado (right-sizing) de vCPU e memória usando os insights do Cloud Monitoring e do Recommender; valide com testes de carga. Alocações insuficientes causam picos de latência e limitação de CPU/OOM (Out of Memory); alocações excessivas desperdiçam gastos.
  • O autoescalonamento (autoscaling) converte o superprovisionamento semelhante a capex em opex elástico. Use HPA/VPA para GKE e autoescalonamento por requisição para serverless (Cloud Run) para corresponder a capacidade à demanda.
  • O faturamento por requisição (Cloud Run, Cloud Functions, GKE Autopilot) alinha o custo ao uso e reduz a ociosidade. Tenha cuidado com as sobrecargas por requisição e as partidas a frio (cold starts); ajuste as instâncias mínimas quando apropriado.
  • O uso comprometido (committed use) é para a linha de base de estado estável (steady-state). Use CUDs baseados em recursos para o Compute Engine e CUDs flexíveis para produtos gerenciados/serverless elegíveis. Não se comprometa em excesso com cargas de trabalho voláteis.
  • A capacidade spot reduz o custo de computação para trabalhos interrompíveis e tolerantes a falhas. Sempre implemente handlers de término gracioso (graceful termination); mantenha a redundância e o checkpointing rápido. Espere o término a qualquer momento com um aviso prévio curto.

• Trade-offs de concorrência e instâncias mínimas no Cloud Run

  • A concorrência (concurrency) controla quantas requisições uma única instância pode atender simultaneamente.
    • Uma concorrência mais alta melhora a utilização e a eficiência de custos, mas pode aumentar a latência de cauda (tail latency) devido ao bloqueio “head-of-line” dentro do contêiner.
    • A concorrência de 1 isola as requisições (útil para código CPU-bound ou que não seja thread-safe), mas geralmente aumenta o número de instâncias e o custo.
  • As instâncias mínimas reduzem as partidas a frio (cold starts) e suavizam a latência ao custo de um gasto base. Use apenas onde os SLOs exigirem e valide o piso com os padrões de demanda.

Exemplo: Configuração do Cloud Run (service.yaml) apiVersion: serving.knative.dev/v1 kind: Service metadata: name: img-api annotations: autoscaling.knative.dev/minScale: “2” spec: template: spec: containerConcurrency: 40 containers: - image: gcr.io/PROJECT/img-api resources: limits: memory: “512Mi”

• Requests e limits de recursos no GKE, comportamento do Cluster Autoscaler e limpeza de recursos ociosos
  • As solicitações (requests) determinam o agendamento (scheduling); os limites (limits) restringem o uso de pico. Defina os requests próximos à necessidade observada em estado estável e os limits um pouco acima para permitir picos curtos. Limits muito baixos causam limitação de CPU (CPU throttling); limits de memória muito baixos causam OOMKilled. Requests muito acima da realidade isolam capacidade e bloqueiam o agendamento.
  • O Cluster Autoscaler escalona os pools de nós (node pools) com base em pods não agendáveis (unschedulable pods) (solicitações agregadas insuficientes). Ele respeita os PodDisruptionBudgets e não pode remover (evict) certos pods (por exemplo, com armazenamento local ou PDBs restritivos), o que pode impedir a redução de escala (scale-down). DaemonSets e taints/affinities de nós também podem bloquear a eficiência do escalonamento.
  • O Horizontal Pod Autoscaler (HPA) vincula o escalonamento a métricas de CPU/memória ou personalizadas; o Vertical Pod Autoscaler (VPA) dimensiona adequadamente os requests ao longo do tempo. Coordene o HPA e o VPA para evitar oscilações; use o VPA nos modos de recomendação ou automático, conforme apropriado.
  • Limpeza de recursos ociosos: exclua balanceadores de carga (load balancers), discos persistentes, snapshots e IPs estáticos não utilizados. Use as recomendações do Active Assist e “janitors” automatizados para detectar e remover ativos ociosos.

Exemplo: Deployment do GKE com requests/limits apiVersion: apps/v1 kind: Deployment metadata: name: api spec: replicas: 3 template: spec: containers: - name: api image: gcr.io/PROJECT/api:stable resources: requests: cpu: “500m” memory: “512Mi” limits: cpu: “1” memory: “768Mi”

Governança de Custos de Dados, Analytics e Rede

• Classes de armazenamento, controles de ciclo de vida, escalonamento de banco de dados e design de egresso de rede
  • Escolha as classes do Cloud Storage pelo padrão de acesso: Standard para dados quentes; Nearline, Coldline ou Archive para dados mais frios. Esteja ciente dos mínimos de recuperação e de exclusão antecipada para as camadas mais frias.
  • Regras de ciclo de vida automatizam transições e exclusões. Use dual-region para resiliência onde a latência multi-region é aceitável; co-localize a computação e os dados para reduzir o egresso e a latência.
  • Escalonamento de banco de dados:
    • Cloud SQL: escalone verticalmente com cautela; use réplicas de leitura para leituras; use autoescalonamento de armazenamento; use planos de consulta e pooling de conexões. Uma alta taxa de transferência de escrita pode exigir sharding ou a migração para o Spanner/Bigtable.
    • Spanner: escalonamento horizontal adicionando nós; configurações multi-region para disponibilidade e leituras globais; projete esquemas e chaves para uma carga balanceada.
    • Bigtable: projete chaves de linha para evitar hotspots; escalone os nós do cluster e o armazenamento separadamente.
  • Egresso de rede: evite tráfego entre regiões; coloque clientes e dados na mesma região sempre que possível. Use o Cloud CDN para conteúdo em escala de internet, Cloud Interconnect/Peering para ambientes híbridos e Private Google Access ou Private Service Connect para acessar as APIs do Google de forma privada. O tráfego desnecessário entre zonas/regiões aumenta o custo e a latência.

Exemplo: Ciclo de vida do Cloud Storage cat > policy.json « ‘EOF’ { “rule”: [ { “action”: {“type”: “SetStorageClass”, “storageClass”: “COLDLINE”}, “condition”: {“age”: 30} }, { “action”: {“type”: “Delete”}, “condition”: {“age”: 365} } ] } EOF gsutil lifecycle set policy.json gs://my-bucket

• Controles de consulta do BigQuery, retenção de dados e custo de uso de analytics
  • Controle os bytes lidos: sempre filtre por chaves de partição/cluster; evite SELECT *; use visualizações materializadas e cache de resultados para consultas repetidas; use agregações aproximadas quando possível.
  • Limite o custo da leitura com o máximo de bytes cobrados e defina a prioridade do job como batch para trabalhos não urgentes para reduzir a interferência e o custo.
  • Escolha o modelo de preços: on-demand para cargas de trabalho esporádicas; reservas (slots) com compromissos para cargas de trabalho estáveis e de alto volume. Use reservas e atribuições separadas para isolar equipes.
  • Retenção de dados: defina a expiração de dataset/tabela e partição para governança; implemente armazenamento em camadas ou exportação para arquivamento.
  • Modos de falha: tabelas grandes não particionadas explodem os custos; consultas sem filtros de partição leem tabelas completas; expirações excessivamente agressivas excluem dados necessários; contenção excessiva de slots degrada o SLA.

Exemplo: limitar custo da consulta bq query –use_legacy_sql=false –maximum_bytes_billed=1000000000
‘SELECT user_id, COUNT(*) FROM proj.ds.events WHERE _PARTITIONDATE >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY) GROUP BY user_id’

Governança Organizacional e Higiene do Ambiente

• Políticas organizacionais, nomenclatura de recursos, uso de tags e separação de projetos

  • Use políticas organizacionais para impor barreiras de proteção (guardrails): restrinja as localizações de recursos, desabilite IPs externos, exija CMEK, restrinja os serviços permitidos, controle o peering de VPC e exija o OS Login quando necessário. Aplique no nível da organização ou da pasta, com exceções modeladas por meio da hierarquia.
  • Padronize a nomenclatura de recursos para codificar ambiente, projeto, aplicativo e região (ex: app-ambiente-regiao-sufixo). Imponha isso por meio de verificações de CI ou política como código (policy-as-code).
  • Diferencie:
    • Rótulos (Labels): atribuição para faturamento/operações.
    • Tags (de primeira classe): anexe a recursos e use em Condições do IAM e no direcionamento de políticas da organização.
    • Tags de rede: para regras de firewall no Compute Engine.
  • Separação de projetos: isole ambientes (produção, homologação, desenvolvimento) e cargas de trabalho sensíveis. Use uma Shared VPC para rede centralizada e projetos de serviço com privilégio mínimo. Isso reduz o raio de impacto e simplifica o IAM.

• Ciclo de vida do ambiente, ambientes de teste efêmeros e automação de limpeza

  • Provisione ambientes via IaC (Terraform) e habilite ambientes efêmeros por PR (Pull Request). Defina rótulos de TTL (Time-to-Live) e a remoção automática após o merge ou inatividade.
  • Use o Cloud Scheduler em conjunto com jobs do Cloud Run ou Functions para varrer em busca de recursos obsoletos por rótulo/idade e excluí-los. Exporte o inventário via Cloud Asset Inventory para conduzir auditorias.
  • Modos de falha: sandboxes abandonadas geram custos; a falta de TTL ou rótulos impede a limpeza; uma limpeza excessivamente agressiva pode excluir recursos ativos — adicione listas de permissão (allowlists) e períodos de carência.

• Arquitetura ciente da sustentabilidade e equilíbrio entre custo, desempenho e confiabilidade

  • Prefira serviços gerenciados e serverless para reduzir a ociosidade e melhorar a utilização de recursos.
  • Escolha regiões com menor intensidade de carbono, quando em conformidade; agende cargas de trabalho em lote para períodos de maior disponibilidade de energia livre de carbono, quando viável.
  • Otimize a gravidade dos dados (data gravity) e o cache para reduzir o consumo de energia da rede. Ajuste o autoscaling e a concorrência para diminuir a subutilização. Use profiling para remover caminhos de código que geram desperdício e acionam excesso de computação ou I/O.
  • Equilíbrio: adicione instâncias ou réplicas mínimas apenas onde os SLOs exigem; avalie a latência de cauda versus a concorrência e a redundância versus o uso de Spot. Valide com testes de carga baseados em SLO e modelagem de custo/desempenho.

Cenário de Problema Prático

A NimbusMarket, uma empresa de e-commerce, enfrenta picos de tráfego durante flash sales e um gasto crescente com analytics. Eles executam APIs para clientes no Cloud Run, workers de background no GKE e análises de produtos no BigQuery. A liderança solicita uma redução de custos de 25% sem comprometer o SLO de 99,9% da API.

Abordagem:

1. Estabelecer visibilidade de custos e barreiras de proteção

   • Crie orçamentos com alertas de previsão em 60%, 90% e 100% para a conta de faturamento, com notificações do Pub/Sub encaminhadas para a equipe de plantão.
   • Padronize os rótulos (equipe, app, ambiente, centro de custo) e imponha-os via CI nos planos do Terraform; adicione uma política organizacional que restrinja as localizações de recursos a regiões aprovadas. Justificativa: Orçamentos fornecem um aviso prévio; rótulos permitem relatórios por equipe; políticas evitam o uso acidental de regiões com alto custo de egress e melhoram a conformidade.

2. Ajustar o Cloud Run para escalonamento econômico

   • Defina containerConcurrency como 40 para a API stateless após o profiling confirmar um tempo médio de CPU de 30 ms e I/O não bloqueante. Configure minScale=2 para evitar cold starts durante o horário normal; defina uma política agendada para reduzir minScale para 0 durante a noite. Justificativa: Uma concorrência mais alta melhora a utilização e reduz o número de instâncias; um número mínimo de instâncias ativas preserva os SLOs com um custo base limitado que é removido fora do horário de pico.

3. Dimensionar corretamente as cargas de trabalho do GKE e habilitar o autoscaling eficiente

   • Aplique requests de 500m de CPU/512Mi e limits de 1 CPU/768Mi aos pods dos workers com base no profiling. Habilite o HPA com base na profundidade da fila e na latência de processamento, e o VPA no modo de recomendação para refinar iterativamente os requests. Verifique se os PodDisruptionBudgets permitem o scale-down. Habilite o Cluster Autoscaler no pool com vários nós menores. Justificativa: Requests precisos impulsionam um agendamento e autoscaling eficazes; o HPA alinha a capacidade ao backlog; o VPA evita desvios; múltiplos nós pequenos reduzem a capacidade ociosa e aceleram os eventos de escalonamento.

4. Adotar capacidade Spot para processamento em lote tolerante a falhas

   • Mova a geração de miniaturas de imagens para um pool de nós baseado em Spot com checkpointing. Implemente hooks preStop para finalizar o trabalho em andamento e um controller para reagendar tarefas interrompidas. Justificativa: A geração de miniaturas é idempotente e flexível em relação ao tempo, tornando-a ideal para economizar com Spot com impacto mínimo na experiência do usuário.

5. Reduzir custos de varredura em analytics e isolar cargas de trabalho

   • Particione e clusterize a tabela de eventos por event_date e customer_id. Adicione expiração de tabela para eventos brutos após 180 dias. Atribua os analistas de marketing a uma reserva separada do BigQuery com um limite de slots; imponha maximum_bytes_billed em suas consultas agendadas. Converta os relatórios noturnos para a prioridade de lote (batch). Justificativa: Particionamento e clusterização reduzem os bytes por consulta; a expiração impõe governança; as reservas isolam os “vizinhos barulhentos”; o processamento em lote reduz a contenção e o custo para tarefas não urgentes.

6. Otimizar o ciclo de vida do armazenamento e o egress

   • Armazene as imagens dos produtos em uma dual-region próxima aos clientes; mova as imagens não acessadas por 30 dias para o Coldline por meio de regras de ciclo de vida; sirva-as via Cloud CDN. Colocalize os serviços do Cloud Run com o Cloud SQL na mesma região e habilite o Private Service Connect para as APIs do Google. Justificativa: O CDN reduz o egress e a latência; o ciclo de vida move o conteúdo frio para um armazenamento mais barato; a colocalização minimiza o egress e melhora o desempenho.

7. Implementar automação de limpeza e verificações de sustentabilidade

   • Marque os ambientes efêmeros com a tag ttl-hours e execute um job noturno do Cloud Run que exclui os recursos expirados. Use os relatórios do Carbon Footprint para considerar mover os jobs em lote para uma região de menor emissão de carbono e agendá-los para horários de menor pico de emissão. Justificativa: A limpeza automatizada evita vazamentos de custo; o agendamento ciente das emissões de carbono reduz o impacto ambiental sem afetar os SLOs.

8. Validar com testes de carga cientes de SLO e modelos de custo

   • Execute testes de carga que simulam os padrões das flash sales; verifique a latência p95 e os orçamentos de erro. Compare o custo antes e depois usando os dashboards de exportação de faturamento. Justificativa: Confirma que os ajustes atendem às metas de confiabilidade, ao mesmo tempo que proporcionam economias mensuráveis e alinhadas aos objetivos.

Ao executar esses passos, a NimbusMarket alinha os gastos com a demanda, evita o desperdício por ociosidade e impõe governança, alcançando as economias desejadas enquanto mantém o SLO de 99,9% da API e melhora sua postura de sustentabilidade.

← Testes · Todos os domínios

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

Navegar Google →