Última revisão: maio de 2026
Uma referência rápida dos padrões arquiteturais que o exame ACE avalia. Leia de cima a baixo ou pule para uma seção.
Centralize o faturamento e a aplicação de políticas, concedendo autonomia administrativa às unidades de negócios.
Use um nó de Organização com Pastas para cada unidade de negócios. Crie projetos dentro das pastas. Vincule todos os projetos a uma única Conta de Faturamento.
Por quê: Pastas fornecem limites administrativos e herança de políticas. Uma única conta de faturamento centraliza o gerenciamento de custos e permite descontos em toda a organização.
Notificar o setor financeiro quando os gastos do projeto atingirem certas porcentagens de um orçamento.
No Cloud Billing, crie um Orçamento para o projeto. Defina várias regras de limite de alerta (por exemplo, 50%, 90%, 100%) que enviem notificações para um tópico do Pub/Sub ou e-mail.
Por quê: Orçamentos são para alertar, não para interromper gastos. Para limitar automaticamente os gastos, uma notificação do Pub/Sub deve acionar uma Cloud Function para desabilitar o faturamento ou desligar recursos.
Analise custos de nuvem granulares, no nível do recurso, e rastreie os gastos por centro de custo.
Habilite a exportação detalhada de faturamento para um conjunto de dados do BigQuery. Aplique rótulos (por exemplo, `cost-center: "finance"`) aos recursos. Consulte a tabela do BigQuery e agrupe por rótulos para análise.
Por quê: A exportação de faturamento para o BigQuery fornece os dados de custo mais detalhados, incluindo rótulos, o que é essencial para modelos personalizados de chargeback e showback.
Aplique padrões de segurança e configuração em todos os projetos de uma organização (por exemplo, restringir locais de recursos, exigir acesso uniforme a buckets, desativar IPs públicos).
Aplique restrições de Política da Organização no nível da Organização ou Pasta. Exemplos: `gcp.resourceLocations` para residência de dados, `storage.uniformBucketLevelAccess` para segurança do GCS, `compute.vmExternalIpAccess` para evitar IPs públicos.
Por quê: As políticas da organização são herdadas e fornecem controle preventivo, bloqueando ações não conformes antes que ocorram. Isso é mais eficaz do que a auditoria reativa.
Evitar a exclusão acidental de um projeto de produção crítico.
Coloque um ônus no projeto usando `gcloud alpha resource-manager liens create`.
Por quê: Um ônus é uma propriedade que bloqueia a exclusão de um projeto. Ele deve ser explicitamente removido por um usuário com a função `resourcemanager.lienModifier` antes que o projeto possa ser excluído.
Alterne eficientemente entre diferentes projetos e contas de usuário ao usar a CLI gcloud.
Use `gcloud config configurations create` para criar configurações nomeadas para cada projeto/conta. Alterne entre elas usando `gcloud config configurations activate [CONFIG_NAME]`
Por quê: As configurações armazenam definições como projeto, conta, região e zona, evitando a necessidade de especificá-las a cada comando.
Execute um microsserviço HTTP sem estado, containerizado, com tráfego variável, minimizando a sobrecarga operacional e o custo.
Implante o contêiner no Cloud Run.
Por quê: O Cloud Run é totalmente gerenciado, escala para zero (eliminando custos em períodos de inatividade) e escala automaticamente com base nas requisições recebidas. É ideal para serviços web sem estado.
Execute um trabalho de processamento em lote tolerante a falhas e flexível no tempo com o menor custo possível.
Use VMs Spot (anteriormente VMs Preemptíveis) em um Grupo de Instâncias Gerenciado.
Por quê: As VMs Spot oferecem um desconto de até 91% em comparação com os preços sob demanda. Elas são adequadas para cargas de trabalho que podem ser interrompidas e reiniciadas, como muitos trabalhos de processamento em lote.
Implante uma aplicação web que requer alta disponibilidade (por exemplo, 99,9%) e autoscaling.
Use um Grupo de Instâncias Gerenciado (MIG) Regional com uma política de autoscaling, implantado atrás de um Balanceador de Carga HTTP(S) Externo Global.
Por quê: Um MIG regional distribui automaticamente instâncias em várias zonas para tolerância a falhas. O autoscaling ajusta a capacidade para atender à demanda, e o balanceador de carga fornece um único ponto de entrada.
Armazene dados que são acessados frequentemente por 30 dias, depois infrequente por um ano, e então arquivados.
Armazene em um bucket de classe Cloud Storage Standard. Crie uma regra de ciclo de vida para transicionar objetos para Nearline/Coldline após 30 dias e para Archive após 365 dias.
Por quê: As regras de ciclo de vida automatizam a otimização de custos, movendo dados para classes de armazenamento mais baratas com base na idade ou outras condições, sem intervenção manual.
Uma aplicação distribuída globalmente requer um banco de dados relacional com escalabilidade horizontal e forte consistência.
Use Cloud Spanner.
Por quê: Cloud Spanner é o único serviço que oferece um banco de dados relacional, distribuído globalmente, fortemente consistente e com suporte a SQL. O Cloud SQL é regional.
Uma aplicação requer um banco de dados PostgreSQL ou MySQL gerenciado com um SLA de disponibilidade de 99,95% e failover automático.
Use o Cloud SQL com a configuração de Alta Disponibilidade (HA) habilitada.
Por quê: A configuração de HA cria uma instância primária e uma instância standby em uma zona diferente. Os dados são replicados sincronicamente, e o failover é automático.
Projete uma VPC para uma aplicação de 3 camadas (web, app, db) onde a camada de banco de dados não deve ser acessível pela internet.
Crie uma VPC de modo personalizado com uma sub-rede separada para cada camada. Provisione as instâncias de banco de dados com apenas endereços IP privados em sua sub-rede dedicada.
Por quê: Isolar camadas em sub-redes separadas permite regras de firewall granulares. Omitir IPs externos em instâncias de banco de dados é a maneira mais direta de prevenir o acesso à internet.
Implante uma aplicação com estado (por exemplo, um banco de dados) no GKE que requer identificadores de rede estáveis e armazenamento persistente.
Use um StatefulSet com um modelo de PersistentVolumeClaim.
Por quê: StatefulSets são projetados para cargas de trabalho com estado, fornecendo nomes de host estáveis (por exemplo, `pod-0`, `pod-1`) e provisionando automaticamente um PersistentVolume exclusivo para cada réplica.
Um serviço Cloud Run sensível à latência deve evitar "cold starts" durante picos de tráfego.
Implante o serviço com a flag `--min-instances` definida para 1 ou superior.
Por quê: Definir instâncias mínimas mantém um número especificado de contêineres "aquecidos" e prontos para atender requisições, eliminando a latência associada ao início de um novo contêiner.
Execute uma função serverless automaticamente sempre que um novo arquivo for carregado para um bucket do Cloud Storage.
Implante uma Cloud Function (2ª Geração) com um trigger Eventarc para o evento `google.cloud.storage.object.v1.finalized` no bucket especificado.
Por quê: O Eventarc fornece uma arquitetura unificada e orientada a eventos. O trigger GCS é a maneira padrão e gerenciada de conectar eventos de armazenamento à computação serverless sem polling.
Implante uma nova versão de uma aplicação App Engine para teste sem enviar imediatamente tráfego de produção para ela.
Implante a nova versão usando `gcloud app deploy --no-promote`.
Por quê: A flag `--no-promote` cria a nova versão, mas não redireciona nenhum tráfego para ela. Você pode então testá-la usando sua URL específica da versão e migrar o tráfego manualmente quando estiver pronto.
Crie um balanceador de carga HTTP(S) global para uma aplicação web executando em instâncias do Compute Engine.
Crie esses componentes em ordem: Grupo de Instâncias (com VMs), Verificação de Integridade (Health Check), Serviço de Backend (apontando para IG e HC), Mapa de URL, Proxy HTTP(S) de Destino e uma Regra de Encaminhamento Global (com um IP público).
Por quê: Esta sequência constrói corretamente o balanceador de carga do backend (instâncias) para o frontend (regra de encaminhamento). Cada componente serve a um propósito específico no roteamento e na verificação de integridade.
Uma equipe precisa gerenciar o estado do Terraform de forma colaborativa, garantindo segurança e prevenindo modificações simultâneas.
Use um bucket do Cloud Storage como backend do Terraform. Habilite o versionamento de objetos para histórico e recuperação. O bloqueio de estado é tratado automaticamente pelo backend do GCS.
Por quê: Um backend GCS remoto é o padrão para colaboração em equipe no GCP. Ele fornece bloqueio para prevenir a corrupção de estado e versionamento para capacidades de rollback.
Receber uma notificação quando a utilização da CPU em qualquer VM de um grupo exceder 80% por um período sustentado (por exemplo, 5 minutos).
No Cloud Monitoring, crie uma Política de Alerta. Defina a condição para `Métrica: Utilização da CPU > 80%` para `Duração: 5 minutos`. Configure um canal de notificação (por exemplo, e-mail, PagerDuty).
Por quê: O Cloud Monitoring é o serviço nativo para criar alertas baseados em métricas. A condição de duração é crucial para evitar alertas "oscilantes" devido a picos breves e normais de utilização.
Reter logs de auditoria específicos por 7 anos para conformidade, enquanto mantém outros logs por 30 dias.
Crie um sink de log com um filtro para os logs de auditoria. Configure o sink para exportar para um bucket do Cloud Storage. Aplique uma política de retenção de 7 anos no bucket.
Por quê: O Cloud Logging tem um período de retenção limitado (máximo de 400 dias para Atividade de Administrador). Sinks são o mecanismo para rotear logs para armazenamento de longo prazo e mais barato, como GCS, ou para análise no BigQuery.
Um pod do GKE está no estado `CrashLoopBackOff`. Você precisa visualizar os logs do contêiner logo antes de ele falhar.
Use o comando `kubectl logs [POD_NAME] --previous`.
Por quê: Quando um contêiner falha e reinicia, `kubectl logs` mostra os logs do *novo* contêiner. A flag `--previous` é essencial para visualizar os logs da instância terminada para diagnosticar a falha.
Um grupo de instâncias gerenciado deve substituir automaticamente as instâncias que se tornam inoperantes.
Configure uma verificação de integridade (por exemplo, HTTP, TCP) e aplique-a à política de autocura do grupo de instâncias gerenciado.
Por quê: O MIG sonda periodicamente as instâncias com base na verificação de integridade. Se uma instância falhar em verificações consecutivas, o MIG a exclui e a recria automaticamente a partir do modelo, garantindo a disponibilidade da aplicação.
Um evento de corrupção de dados ocorreu em um banco de dados Cloud SQL. Você precisa restaurar o banco de dados para o estado em que estava 5 minutos antes do evento.
Certifique-se de que a Recuperação Pontual (PITR) esteja habilitada na instância antecipadamente. Realize uma operação de restauração, especificando o timestamp exato para o qual recuperar.
Por quê: O PITR depende da habilitação do log binário. Ele permite a recuperação granular para qualquer ponto no tempo dentro da janela de retenção, o que é crítico para minimizar a perda de dados (baixo RPO).
Automatize backups diários de um disco persistente do Compute Engine e retenha-os por 14 dias.
Crie uma Política de Recursos para snapshots de disco. Configure um agendamento diário e uma política de retenção de 14 dias. Anexe esta política ao disco persistente de destino.
Por quê: Agendamentos de snapshot são a maneira gerenciada e "fire-and-forget" de automatizar backups do GCE. Isso é mais confiável e mantenedor do que usar cron jobs ou scripts personalizados.
Uma instância do Compute Engine precisa ler de um bucket do Cloud Storage e gravar em uma tabela do BigQuery. Conceda as permissões mínimas necessárias.
Crie uma conta de serviço personalizada. Conceda a ela as funções `roles/storage.objectViewer` e `roles/bigquery.dataEditor`. Anexe esta conta de serviço à instância.
Por quê: Usar uma conta de serviço personalizada com funções específicas e predefinidas evita a natureza excessivamente permissiva da conta de serviço padrão do Compute Engine, aderindo ao princípio do menor privilégio.
Conceda a um usuário permissões para gerenciar instâncias do GCE, mas não para excluí-las.
Crie uma função IAM personalizada. Comece com as permissões da função `roles/compute.instanceAdmin.v1` e remova a permissão `compute.instances.delete`.
Por quê: Funções personalizadas oferecem a flexibilidade de conceder um conjunto preciso de permissões quando as funções predefinidas são muito amplas ou muito restritivas para uma função de trabalho específica.
Um desenvolvedor precisa acessar via SSH uma instância do Compute Engine que não possui endereço IP externo, conforme a política de segurança.
Conceda ao desenvolvedor a função `roles/iap.tunnelResourceAccessor`. Ele poderá então se conectar usando `gcloud compute ssh [INSTANCE_NAME] --tunnel-through-iap`.
Por quê: O encaminhamento TCP do Identity-Aware Proxy (IAP) fornece um método seguro, baseado em identidade, para acessar instâncias internas sem hosts bastion, VPNs ou IPs públicos.
Permitir tráfego SSH de entrada (porta 22) para VMs específicas apenas do intervalo de IP do escritório corporativo.
Crie uma regra de firewall da VPC com `direction: INGRESS`, `action: ALLOW`, `protocol/ports: tcp:22`, `source ranges: [CIDR_IP_CORPORATIVO]`, e `target tags: [por exemplo, "allow-ssh"]`. Aplique a tag às VMs pretendidas.
Por quê: Combinar intervalos de origem e tags de destino oferece uma maneira precisa e escalável de controlar o tráfego. Isso restringe tanto *quem* pode se conectar quanto *ao quê* eles podem se conectar.
Impeça que dados de um projeto BigQuery sensível sejam copiados ou acessados de fora de um limite de rede confiável, mesmo com credenciais válidas.
Configure os Controles de Serviço da VPC. Crie um perímetro de serviço que inclua o projeto sensível e restrinja a API do BigQuery.
Por quê: Os Controles de Serviço da VPC criam um "perímetro de dados" virtual que controla o acesso no nível da API, fornecendo uma forte defesa contra exfiltração de dados que as regras de firewall não conseguem.
Forneça a uma aplicação de terceiros acesso de leitura temporário e com limite de tempo a um objeto privado específico em um bucket do Cloud Storage.
Gere uma URL assinada para o objeto com um curto tempo de expiração (por exemplo, 15 minutos) usando uma conta de serviço com permissões de leitura.
Por quê: URLs assinadas concedem acesso temporário por objeto sem exigir que a terceira parte tenha uma conta Google ou permissões IAM. É o método mais seguro para este caso de uso.
Um pod do GKE precisa acessar APIs do Google Cloud (por exemplo, Pub/Sub) de forma segura, sem armazenar chaves de conta de serviço como segredos do Kubernetes.
Habilite a Workload Identity no cluster GKE. Crie uma Conta de Serviço Google (GSA) e uma Conta de Serviço Kubernetes (KSA). Vincule a KSA à GSA usando uma política IAM. Configure o pod para usar a KSA.
Por quê: Workload Identity é a maneira recomendada e sem chaves para aplicações GKE autenticarem-se aos serviços Google Cloud. Ela mapeia identidades KSA para identidades GSA, o que é mais seguro do que gerenciar e rotacionar arquivos de chave.
Uma política da organização exige que todos os dados em um bucket do Cloud Storage sejam criptografados usando uma chave de criptografia que a organização controla.
Crie uma chave criptográfica no Cloud KMS. Ao criar o bucket do Cloud Storage, especifique esta chave como a Chave de Criptografia Gerenciada pelo Cliente (CMEK).
Por quê: CMEK oferece controle sobre a chave usada para criptografia, incluindo rotação e revogação, enquanto ainda aproveita a infraestrutura de criptografia gerenciada pelo Google.
Permitir que os funcionários usem suas credenciais existentes do Active Directory local para acessar recursos do Google Cloud.
Configure o Cloud Identity para federar com o Active Directory usando SAML 2.0. Os usuários se autenticam com o AD, que então afirma sua identidade ao Google Cloud para acesso.
Por quê: A federação permite o Single Sign-On (SSO) e centraliza o gerenciamento de identidade no IdP existente (Active Directory), evitando a necessidade de gerenciar um conjunto separado de senhas no Google Cloud.
Conceda a um contratado externo acesso temporário a um projeto, que deve expirar automaticamente após 30 dias.
Adicione o contratado como membro IAM com a função necessária. Adicione uma condição à vinculação de função com um carimbo de data/hora de expiração (`request.time < timestamp("YYYY-MM-DDTHH:MM:SSZ")`).
Por quê: As Condições IAM fornecem controle de acesso baseado em atributos. Condições baseadas em tempo são perfeitas para acesso temporário, pois revogam automaticamente as permissões sem necessidade de limpeza manual.