Google ACE: Compute Engine e Operações de Máquinas Virtuais — 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 Compute Engine oferece máquinas virtuais flexíveis e de alto desempenho e primitivos de orquestração para executar cargas de trabalho de uso geral e especializadas. A excelência operacional no Compute Engine significa selecionar a família de máquinas e o disco corretos, moldar o ciclo de vida da instância com templates e grupos de instâncias, estabelecer autohealing e autoscaling robustos, fortalecer os caminhos de acesso e se preparar para modos de falha com procedimentos de recuperação repetíveis. Esta seção explica as escolhas de design, trade-offs e padrões operacionais que minimizam o trabalho manual e maximizam a confiabilidade e a eficiência de custos.

Tipos de Máquina, Dimensionamento e Ciclo de Vida da Instância

Famílias de máquinas

Uso geral: E2 (otimizada para custo), N2 (balanceada), N2D (baseada em AMD), Tau T2D/T2A (alta relação preço-desempenho para scale-out), adequadas para a maioria das cargas de trabalho.
Otimizada para computação: C3 para tarefas vinculadas à CPU (CPU-bound); escolha quando precisar de alto desempenho por núcleo.
Otimizada para memória: Série M para bancos de dados em memória e analytics.
GPUs e aceleradores: Anexe a famílias compatíveis quando precisar de aceleração CUDA ou ML; garanta que a inicialização do driver seja capturada nos processos de inicialização.

Tipos de máquina personalizados

Use vCPU e memória personalizadas para dimensionar corretamente (right-size) as cargas de trabalho e reduzir o desperdício, especialmente para necessidades assimétricas (ex: uso intensivo de memória, mas CPU moderado).
Para serviços vinculados à CPU (CPU-bound), prefira contagens de vCPU mais altas; para os vinculados à memória (memory-bound), aumente a RAM e garanta que os garbage collectors e caches estejam ajustados.
Fique atento aos modelos de licenciamento atrelados à contagem de núcleos; tipos personalizados ajudam a evitar núcleos licenciados desnecessários.

Dimensionamento da carga de trabalho

Comece a partir de perfis de recursos medidos em ambientes de desenvolvimento ou anteriores: utilização de CPU em P95, pico de uso de memória (high-water mark), throughput/IOPS de disco, largura de banda de rede.
Para tráfego com picos (bursty), planeje uma margem de segurança (headroom) ou use autoscaling; para estado estacionário (steady-state), mire em 60–70% de utilização no pico para equilibrar custo e resiliência.
Avalie as Spot VMs (preemptivas) para trabalhos em lote (batch) e tolerantes a falhas; elas podem ser encerradas a qualquer momento, então projete com checkpointing e novas tentativas (retry).

Recursos do ciclo de vida da instância

Instâncias de VM: O recurso de computação atômico. Use labels e uma nomenclatura consistente para impulsionar a automação.
Instance templates: Blueprints imutáveis que capturam o tipo de máquina, discos, contas de serviço, metadados e scripts de inicialização; eles são a base para grupos de instâncias gerenciados e garantem implantações repetíveis.
Managed instance groups (MIGs): Fornecem tamanho declarativo, autoscaling, autohealing, atualizações contínuas (rolling updates), posicionamento regional (multizona) e configuração por instância. Prefira MIGs para padrões stateless e stateful (MIGs stateful preservam discos/IPs selecionados).
Unmanaged instance groups: Coleções simples para balanceamento de carga de conjuntos legados; não possuem autoscaling/autohealing. Use apenas quando precisar registrar VMs gerenciadas de forma independente.

Disponibilidade, Autoscaling e Manutenção

Autoscaling

Sinais: Utilização de CPU, solicitações por segundo por instância do balanceador de carga HTTP, métricas do Cloud Monitoring e profundidade da fila. Escolha um sinal fortemente correlacionado com a saturação; a CPU é uma boa linha de base para cargas de trabalho homogêneas e vinculadas à CPU.
Cooldowns e estabilização: Configure para evitar oscilação excessiva (thrashing). Se sua aplicação leva minutos para aquecer (warm up), aumente o atraso inicial (initial delay) do MIG e defina um cooldown de autoscaling apropriado.
Padrões de instância única (Exact-one): Para forçar exatamente uma VM, defina min=1 e max=1 no autoscaling de um MIG. Isso preserva a saúde da instância enquanto habilita o autohealing.

Autohealing e verificações de saúde (health checks)

Verificações de saúde (Health checks): Use verificações HTTP(S) para a vivacidade (liveness) da aplicação; o TCP apenas valida a aceitação do soquete. Implemente um endpoint de saúde que exercite as dependências críticas.
Limiares e intervalos: Ajuste o intervalo de verificação (check-interval) e os limiares (thresholds) para detectar falhas rapidamente, sem falsos positivos.
Atraso inicial (Initial delay): Defina o atraso inicial do autohealing do MIG com tempo suficiente para a inicialização e aquecimento (warm-up) para evitar substituições prematuras de instâncias saudáveis que estão entrando em operação.
Modos de falha: Endpoints de saúde mal configurados e atrasos iniciais muito curtos causam instabilidade (flapping) e superprovisionamento.

MIGs Regionais e posicionamento (placement)

MIGs Regionais distribuem instâncias por várias zonas em uma região, fornecendo tolerância a falhas de zona. Escolha o número de réplicas de destino por zona com base no planejamento de capacidade.
Use configurações por instância (per-instance configs) e políticas stateful quando for necessário preservar discos ou IPs; entenda que a substituição de VMs pode ser mais lenta devido à reconciliação de estado.

Manutenção, migração em tempo real (live migration) e reservas

Migração em tempo real (Live migration): Padrão para a maioria das VMs; as instâncias são movidas durante a manutenção do host sem reinicialização. Para cargas de trabalho que não toleram a migração (ex: HFT sensível à latência), defina a política de manutenção para encerrar (terminate) e confie no autohealing.
As janelas de manutenção do host são transparentes com a migração em tempo real, mas ainda geram eventos; monitore e teste.
Reservas: Crie reservas zonais para garantir capacidade para lançamentos críticos ou SLOs rigorosos. Aplique o consumo de reserva “específica” (specific) ou “qualquer” (any) com base na sua governança. Reservas são garantias de capacidade; combine-as com descontos por uso contínuo (committed use discounts) para o planejamento de custos.

Armazenamento, Imagens e Desempenho

Discos persistentes

Tipos: Standard (HDD) para throughput sequencial a baixo custo; Balanceado (pd-balanced) para uso geral; SSD (pd-ssd) para IOPS alto/baixa latência; Extremo (pd-extreme) para IOPS e throughput provisionados em níveis de alto desempenho. PDs Regionais fornecem replicação síncrona entre zonas para maior disponibilidade.
O desempenho escala com o tamanho do disco para standard, balanced e SSD; pré-dimensione para atender ao pico de IOPS/throughput ou use o Extreme para provisionar explicitamente.
O modo somente leitura com anexação múltipla (multi-attach read-only) permite compartilhar datasets entre várias VMs; coordene o acesso e as camadas de cache adequadamente.

Local SSD

Efêmero, anexado diretamente ao host, IOPS muito alto/latência muito baixa. Os dados são perdidos ao parar/terminar/migrar a instância. Use para espaço temporário (scratch), caches e camadas de dados replicados. Garanta a replicação ou checkpoints no nível da aplicação.

Snapshots e imagens

Snapshots são backups incrementais e point-in-time de discos persistentes; agende com o Resource Manager ou gcloud para atender ao RPO. O armazenamento entre regiões (cross-region) suporta DR.
Imagens capturam discos de boot mais a configuração. Mantenha um pipeline de imagens fortalecidas (hardened) e com gerenciamento de patches. Valide os agentes do sistema operacional convidado (para logging/monitoramento) em suas imagens douradas (golden images).
Padrões de restauração: Para recuperação rápida, mantenha imagens base pequenas e configure o restante através de scripts de inicialização ou cloud-init; isso reduz o desvio (drift) e acelera as atualizações.

Escolhas de disco: trade-offs e modos de falha

Discos subprovisionados limitam o throughput da aplicação; o superprovisionamento desperdiça custos. Meça as características reais de I/O e escolha o menor disco que atenda às necessidades de pico com uma margem.
Para bancos de dados, considere PDs regionais e pd-ssd/pd-extreme; valide o comportamento do fsync e as profundidades de fila (queue depths). Evite Local SSD para estado durável, a menos que seja replicado.

Acesso, Segurança, Rede e Cargas de Trabalho Especializadas

Administração Linux e Windows

SSH no Linux: Prefira o OS Login para centralizar a autorização SSH e atribuir o acesso a identidades. Conceda compute.osLogin ou compute.osAdminLogin a grupos, não a indivíduos.
RDP no Windows: Defina as credenciais do Windows no console ou via gcloud; garanta que as regras de firewall permitam TCP 3389 apenas de IPs confiáveis. Use o encaminhamento TCP do IAP para evitar exposição pública.
Console serial: Habilite como um caminho de emergência (break-glass); use gcloud compute connect-to-serial-port para depuração de boot. Restrinja com o IAM e audite o acesso.

SSH, OS Login e gerenciamento de chaves

Habilite o OS Login no nível do projeto ou da instância com o metadado enable-oslogin=TRUE. Os usuários adicionam sua chave pública SSH à sua Conta Google; o IAM controla o acesso baseado em papéis.
Para sudo/root, use compute.osAdminLogin. Desabilite as chaves SSH em todo o projeto se estiver usando o OS Login para evitar desvios (drift).

Metadados, scripts de inicialização e cloud-init

O servidor de metadados fornece dados da instância/projeto e tokens de contas de serviço. Use apenas tokens com escopo bem definido; nunca codifique segredos (hardcode).
Scripts de inicialização e cloud-init: Inicialize agentes (bootstrap), busque configurações e registre serviços. Torne os scripts idempotentes e escreva logs no console serial para diagnóstico.
Metadados por instância podem sobrescrever as configurações do modelo; use com cuidado para evitar desalinhamento de configuração (configuration skew).

Contas de serviço e escopos

Atribua uma conta de serviço dedicada por carga de trabalho com papéis do IAM de privilégio mínimo nos recursos necessários (ex: storage.objectCreator em um bucket específico).
Prefira escopos de API da Cloud amplos apenas quando o IAM controlar rigidamente o acesso; caso contrário, restrinja os escopos ao mínimo de APIs necessárias.

Rede e endereços

As NICs (placas de rede) podem ter IPs apenas internos ou externos. Prefira VMs privadas com Cloud NAT ou IAP para acesso de saída e administrativo.
Reserve IPs internos estáticos para endpoints estáveis, como servidores de licença; evite depender de endereços efêmeros.
O External HTTP(S) Load Balancing termina o TLS na borda; use certificados gerenciados e verificações de saúde (health checks) para os MIGs de backend. Mantenha a prontidão do backend alinhada com a verificação de saúde e o atraso inicial do MIG.

Cargas de trabalho especializadas e isolamento

Shielded VMs: Secure boot, vTPM e monitoramento de integridade mitigam rootkits; habilite por padrão, a menos que drivers incompatíveis exijam o contrário.
Confidential VMs: A criptografia de memória com AMD SEV protege os dados em uso; geralmente o impacto no desempenho é mínimo, mas valide para aplicações sensíveis à latência.
Sole-tenant nodes: Hosts físicos dedicados para conformidade, isolamento do efeito “vizinho barulhento” (noisy-neighbor) e afinidade de licença. Planeje a fragmentação da capacidade e um custo mais alto.

Solução de Problemas e Operações de Recuperação

Diagnósticos comuns

Conectividade: Verifique as regras de firewall, as permissões da conta de serviço e as rotas. Use os testes de conectividade do Network Intelligence Center.
Problemas de inicialização: Inspecione os logs do console serial, tire uma captura de tela (screenshot) e verifique a saída do script de inicialização. Desative temporariamente a inicialização segura (secure boot) se drivers não assinados bloquearem a inicialização e, em seguida, corrija o problema.
Bloqueio de acesso: Para problemas de SSH com o OS Login, confirme os papéis do IAM e se as chaves existem nas contas de usuário; use o console serial para adicionar um usuário como acesso de emergência.
Corrupção de disco: Desanexe o disco de inicialização, anexe-o a uma VM de resgate, repare os sistemas de arquivos, rotacione as credenciais e capture uma imagem após a correção.

Comportamentos de MIGs e balanceadores de carga

Superprovisionamento: Se as instâncias precisarem de um longo tempo de aquecimento, aumente o atraso inicial do MIG e o período de resfriamento (cooldown) do autoescalador; caso contrário, você pode aumentar o número de instâncias devido a erros 4xx/5xx enquanto a aplicação ainda está inicializando.
Loops de autorrecuperação (autohealing): Confirme a semântica do endpoint de verificação de integridade e a prontidão das dependências; escalone a inicialização das dependências ou adicione novas tentativas (retries).

Padrões de recuperação

Recrie a instância a partir de um modelo ou imagem; padrões imutáveis reduzem o MTTR.
Restaure os dados a partir do snapshot bem-sucedido mais recente; valide o RPO/RTO em relação aos requisitos de negócio.
Para falhas regionais, faça o failover para uma zona ou região diferente usando MIGs regionais e replicação de snapshots entre regiões.

Salvaguardas operacionais

Reservas para capacidade crítica; use alertas baseados em monitoramento sobre o consumo de reservas e cotas.
Auditoria e logs: Habilite os logs de atividade do administrador e de acesso a dados para serviços críticos. Atribua o acesso por meio do OS Login e de contas de serviço.

Exemplos curtos

Reservar um IP interno estático:

undefined

Habilitar o OS Login no nível do projeto:

undefined

Criar uma verificação de integridade HTTP e anexá-la a um MIG com autorrecuperação (autohealing):

undefined

Cenário de Problema Prático

A Northwind Analytics executa uma API sensível à latência no Compute Engine. Os incidentes mostram superprovisionamento frequente durante as implantações, confusão ocasional no acesso SSH entre os administradores e um servidor de telemetria licenciado que deve permanecer acessível em 10.0.3.21. O objetivo é estabilizar o escalonamento, fortalecer o acesso e garantir que o endpoint da licença seja estável.

Abordagem

Criar um modelo de instância com um tipo de máquina personalizado e dimensionado corretamente e com bootstrapping de inicialização

Justificativa: O modelo impõe a imutabilidade. Uma forma personalizada de 6 vCPUs/20 GB de RAM corresponde à CPU e memória P95 medidas, evitando núcleos em excesso que aumentam os custos de licenciamento. Um script de inicialização registra a API no balanceador de carga somente após as verificações de integridade serem aprovadas, reduzindo o impacto do aquecimento.

Implantar um grupo de instâncias gerenciadas (MIG) regional atrás de um External HTTP(S) Load Balancer

Justificativa: Um MIG regional distribui as instâncias entre zonas para tolerância a falhas de zona. O balanceador de carga HTTP(S) termina o TLS na borda e realiza verificações de integridade por instância, mantendo o tráfego apenas em backends prontos.

Configurar o autoescalamento com base na CPU com um período de resfriamento (cooldown) e autorrecuperação (autohealing) com um atraso inicial realista

Justificativa: A CPU está fortemente correlacionada com a saturação desta API. Um período de resfriamento de 90 segundos evita oscilações bruscas (thrash) em picos transitórios. Um atraso inicial de 200 segundos se alinha com o aquecimento do contêiner e o JIT, impedindo que o autoescalador interprete inicializações a frio (cold starts) como falta de capacidade.

Ajustar a verificação de integridade e adicionar um endpoint /healthz no nível da aplicação

Justificativa: Uma verificação de integridade HTTP que valida as dependências (cache, conectividade com o BD) detecta falhas parciais (gray failures). Usar intervalos de 10 segundos e 3 limiares de falha (unhealthy thresholds) equilibra a velocidade de detecção e o risco de falsos positivos.

Habilitar o OS Login e conceder acesso de administrador a um grupo do IAM

Justificativa: O OS Login centraliza a autorização e a atribuição de SSH. Os administradores adicionam suas chaves públicas SSH às suas contas Google; conceder o papel compute.osAdminLogin ao grupo de plantão (on-call) fornece sudo enquanto preserva as trilhas de auditoria. Isso remove a divergência de chaves por VM.

Reservar o IP interno estático do servidor de licença e anexá-lo a uma VM pequena e dedicada

Justificativa: Reservar o endereço 10.0.3.21 garante que ele esteja disponível e evita sua reutilização acidental. Atribua-o à NIC da VM de licença para que os aplicativos dependentes não exijam alterações de configuração. Limite o escopo das regras de firewall apenas para as sub-redes de origem permitidas.

Atribuir uma conta de serviço dedicada ao modelo da API com o princípio do menor privilégio no IAM

Justificativa: O princípio do menor privilégio reduz o raio de impacto (blast radius). À conta de serviço são concedidos apenas os papéis necessários (por exemplo, acesso de leitura a segredos específicos e tópicos do Pub/Sub). Usar um modelo garante que todas as instâncias herdem a identidade correta.

Fortalecer (harden) as instâncias com Shielded VM e impor o acesso de emergência pelo console serial

Justificativa: A inicialização segura (Secure Boot) e o monitoramento de integridade mitigam a adulteração do kernel/bootloader. Restrinja o acesso ao console serial com o IAM e registre o acesso para auditorias; mantenha-o para recuperação caso o SSH falhe.

Implementar agendamentos de snapshots para discos com estado (stateful) e testar a restauração

Justificativa: Embora a API seja sem estado (stateless), crie um agendamento de snapshots para o servidor de licença e quaisquer discos de configuração para atender ao RPO. Testes periódicos de restauração validam as ferramentas e os runbooks.

Validar e implantar

Justificativa: Atualizações blue/green ou canário com as configurações de atualização contínua (rolling update) do MIG reduzem o risco. Painéis de monitoramento confirmam a estabilização da contagem de instâncias durante as implantações, a melhora na atribuição de acesso do administrador e a acessibilidade ininterrupta do endereço 10.0.3.21.

← Hierarquia de Recursos · Todos os domínios · Contêineres →

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