Google ACE: Armazenamento, Bancos de Dados e Serviços de Dados — 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.

Bancos de dados e serviços de dados gerenciados

Cloud SQL (MySQL, PostgreSQL, SQL Server gerenciados):

• Configuração: Escolha o tipo de máquina, tipo de armazenamento, conexões (IP privado é o preferencial), redes autorizadas se usar IP público, janelas de manutenção e insights para diagnóstico de desempenho. Use o pool de conexões (ex: Cloud SQL Auth Proxy, PGbouncer) para se manter dentro dos limites de conexão e CPU.
• Alta disponibilidade: Instâncias de HA regional implantam uma instância de standby em outra zona com replicação de armazenamento síncrona; o failover é automático. Espere uma pequena janela de indisponibilidade de escrita durante o failover.
• Réplicas: Réplicas de leitura para escalar a leitura e desonerar o BI; replicação externa para migrações. Monitore o atraso da réplica (replica lag) e projete leitores idempotentes.
• Backups e PITR: Habilite backups automatizados e logs binários/WAL para recuperação point-in-time (PITR). Teste as restaurações regularmente.

undefined

• Modos de falha: Transações de longa duração bloqueiam o vacuum/checkpointing; picos de conexões causam thrashing; o crescimento automático do armazenamento (autogrow) pode parar se a cota for insuficiente. Configure alertas para CPU, memória, conexões, atraso da réplica (replica lag) e uso de disco.

Cloud Spanner:

• Escala e regionalidade: Instâncias regionais ou multirregionais com replicação síncrona e consistência forte global. Escale os nós para vazão (throughput) e armazenamento; o posicionamento da região líder influencia a latência de escrita.
• Esquema e chaves: Projete chaves primárias para evitar hotspots; use chaves compostas com um prefixo de hash ou aleatório para séries temporais para distribuir as escritas. Use índices secundários para padrões de consulta e considere armazenar colunas frequentemente filtradas juntas. Mantenha as transações pequenas e delimitadas para minimizar a contenção de bloqueio (lock contention).
• Transações: Transações distribuídas e fortemente consistentes com consistência externa via TrueTime. Latência de escrita limitada pelo quórum; conflitos resultam em transações abortadas—tente novamente com backoff exponencial.

Firestore e Bigtable:

• Firestore (modo nativo): Armazenamento de documentos com coleções, listeners em tempo real, transações abrangendo até 500 documentos por transação e consistência forte para leituras de documentos e a maioria das consultas. Ideal para dados de aplicativos móveis/web, JSON hierárquico e aplicativos orientados a eventos.
• Bigtable: Banco de dados de colunas largas (wide-column) para escala de petabytes e latência abaixo de 10ms. Apenas transações de linha única; projete as chaves de linha (row keys) para evitar hotspotting. Ideal para séries temporais, IoT, personalização e contadores em grande escala. Não é para joins ad-hoc ou agregações complexas.

Memorystore:

• Redis e Memcached: Caches em memória para latência de microssegundos a milissegundos. O nível Basic não tem HA; o nível Standard oferece HA regional com failover automático para o Redis. Trate como efêmero; não use como o sistema de registro (system of record).

BigQuery:

• Datasets e tabelas: Organize por dataset; controle o acesso nos níveis de projeto, dataset, tabela, coluna e linha. Use tabelas particionadas e clusterizadas para controlar os bytes lidos e o custo.
• Jobs de carregamento e consulta: Carregue a partir do Cloud Storage, de exportações do Cloud SQL ou de inserções via streaming. Use execuções de teste (dry runs) para estimar o custo:

undefined

• Controle de acesso: Conceda o papel BigQuery Data Viewer no escopo do dataset para consumidores somente leitura; use visualizações autorizadas ou segurança em nível de linha/coluna para o princípio do menor privilégio.

Trade-offs de movimentação, migração, validação e operações de dados

Migração e transferência:

• Database Migration Service (DMS): Para migrações homogêneas para o Cloud SQL com tempo de inatividade mínimo por meio de replicação. Valide o cutover com métricas de lag e comparações de checksum.
• Transferências do Cloud Storage: Storage Transfer Service para transferências repetitivas ou orientadas a eventos; gsutil -m rsync para cópias sincronizadas únicas com checksums; Transfer Appliance para grandes movimentações offline.
• Importação/exportação: O Cloud SQL exporta para o Cloud Storage; a reimportação suporta o bootstrap de PITR e a verificação de dados. O BigQuery suporta cargas em lote do Cloud Storage e exportações para Avro/Parquet para uso downstream.
• Validação: Use checksums de objetos (CRC32C), contagens de linhas, consultas de amostragem e invariantes no nível da aplicação. Para o BigQuery, compare contagens ou hashes de GROUP BY entre a origem e o destino.

Trade-offs de desempenho, disponibilidade, capacidade e custo:

• Cloud Storage: Otimize o egresso colocalizando a computação; escolha as classes pela frequência de acesso; use dual/multi-region para resiliência entre zonas e maior disponibilidade a um custo de armazenamento mais alto.
• PD/Filestore: SSD para E/S de baixa latência; HDD para throughput; replicação regional para HA; dimensione corretamente os IOPS para evitar throttling.
• Cloud SQL: O escalonamento vertical é simples, mas limitado; réplicas de leitura aliviam o tráfego de leitura; HA adiciona disponibilidade, mas não capacidade de leitura; a classe de armazenamento afeta a latência e o custo.
• Spanner: Escala horizontalmente com consistência forte; o custo premium é compensado pelo RPO/RTO global e pelo sharding simplificado. As escritas são sensíveis ao design da chave e à latência da região líder.
• Firestore/Bigtable/Memorystore: Escolha com base na latência, modelo de dados e consistência. Caches em memória reduzem a carga do banco de dados, mas adicionam complexidade de invalidação de cache.
• BigQuery: O custo sob demanda é proporcional aos bytes escaneados; particionamento/clusterização e predicate pushdown reduzem os gastos. Reservas de taxa fixa (flat-rate) trocam previsibilidade por comprometimento.

Solução de problemas e recuperação segura:

• Cloud Storage: Use o versionamento e a retenção de objetos para recuperar; examine os logs de acesso a dados do Cloud Logging para auditar eventos de leitura/escrita; garanta que as chaves CMEK estejam habilitadas durante a recuperação.
• PD/Filestore: Restaure a partir de snapshots ou backups; execute fsck e modos de recuperação de banco de dados; garanta a consistência com o quiesce no nível da aplicação antes de criar o snapshot.
• Cloud SQL: Restaure para uma nova instância para PITR para evitar a perda de dados na primária; verifique com testes somente de leitura; mantenha o firewall e o DNS privado para padrões de cutover seguros.
• Spanner/Bigtable: Investigue hotspotting por meio da assimetria de acesso a chaves (key access skew); use o Monitoring para rastrear latência e throttling; implemente backoff e novas tentativas para transações abortadas ou operações com limite de taxa.
• BigQuery: Diagnostique consultas lentas por meio dos detalhes de execução; adicione partições e clusterização; limite SELECT *; materialize resultados intermediários quando apropriado. Recupere tabelas excluídas dentro da janela de time travel restaurando um snapshot ou copiando de um tempo de snapshot.

Cenário de Problema Prático

A Contoso Retail está consolidando backups e dados de analytics, ao mesmo tempo em que reforça os controles de acesso e habilita a recuperação point-in-time (PITR) para seus sistemas transacionais. Eles precisam: armazenar backups de aplicações com tiering automatizado, fornecer compartilhamento de arquivos de curta duração para terceiros, habilitar PITR para uma pequena carga de trabalho relacional e estimar os custos de consulta de analytics antes da execução.

Abordagem:

1. Criar um bucket regional do Cloud Storage com UBLA, retenção e ciclo de vida.

   • Comando: gcloud storage buckets create gs://contoso-backups –location=us-central1 –uniform-bucket-level-access –default-storage-class=STANDARD gcloud storage buckets update gs://contoso-backups –retention-period=365d gsutil lifecycle set lifecycle.json gs://contoso-backups
   • Justificativa: O UBLA centraliza a autorização no IAM e melhora a auditabilidade. Uma retenção de um ano impede a exclusão acidental. O ciclo de vida transiciona os backups para Coldline após 90 dias e os exclui na expiração para controlar os custos.

2. Conceder acesso somente de escrita para jobs de backup por meio de uma conta de serviço dedicada.

   • Comando: gcloud storage buckets add-iam-policy-binding gs://contoso-backups –member=serviceAccount:backup-writer@contoso.iam.gserviceaccount.com –role=roles/storage.objectCreator
   • Justificativa: storage.objectCreator impede a adulteração de metadados e a leitura de backups sensíveis, aderindo ao princípio do menor privilégio.

3. Compartilhar um backup sensível com um fornecedor por quatro horas usando uma URL assinada sem distribuir chaves.

   • Comando: gcloud storage sign-url gs://contoso-backups/db-dump-2024-09-30.sql.gz –duration=4h –impersonate-service-account share-signer@contoso.iam.gserviceaccount.com
   • Justificativa: O acesso com limite de tempo e sem identidade evita a criação de identidades externas ou segredos de longa duração. A representação (impersonation) usa assinatura centralizada apoiada pelo KMS e elimina os riscos de vazamento de chaves.

4. Habilitar backups do Cloud SQL e PITR para o banco de dados de pedidos.

   • Comando: gcloud sql instances patch orders-sql –backup-start-time=02:00 –enable-bin-log
   • Justificativa: Backups automatizados mais o registro de logs binários/WAL fornecem pontos de restauração para qualquer segundo dentro da janela de retenção, protegendo contra corrupção lógica e erro do operador.

5. Testar a recuperação restaurando para uma nova instância e validando os dados antes do cutover.

   • Comando: gcloud sql backups list –instance=orders-sql gcloud sql instances restore-backup orders-restore –backup-id=LATEST –destination-instance=orders-restore
   • Justificativa: Restaurar para uma instância separada evita impactar a produção e permite a validação por meio de checksums e consultas de amostra antes de qualquer troca de DNS ou no nível da aplicação.

6. Estimar o custo da consulta do BigQuery com um dry run e otimizar com particionamento.

   • Comando: bq query –use_legacy_sql=false –dry_run=true ‘SELECT COUNT(*) FROM contoso.analytics.sales WHERE sale_date >= “2026-01-01”’
   • Justificativa: Dry runs revelam os bytes a serem escaneados; garantir que sale_date seja uma coluna de partição com um predicado limitado reduz os bytes escaneados e controla os custos sob demanda.

7. Monitorar e auditar o acesso.

   • Passos:
     • Habilitar logs de Acesso a Dados para o Cloud Storage e o BigQuery.
     • Configurar alertas do Cloud Monitoring para conexões do Cloud SQL, uso de disco e falhas de backup.
   • Justificativa: Os logs de Acesso a Dados fornecem visibilidade de leitura/escrita no nível do objeto para conformidade. Alertas proativos encurtam o MTTR e garantem que os backups e o PITR permaneçam eficazes.

8. Documentar modos de falha e runbooks.

   • Passos:
     • Registrar procedimentos para restaurações de versão de objeto, revogação de URL assinada, PITR do Cloud SQL e recuperação de tabela do BigQuery usando time travel.
   • Justificativa: Runbooks claros e testados reduzem o risco operacional durante incidentes e padronizam práticas de recuperação seguras entre as equipes.

← Redes VPC · Todos os domínios · Implantação →

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

Navegar Google →