Google Cloud Professional Cloud Database Engineer
Última revisão: maio de 2026
Uma referência rápida dos padrões arquiteturais que o exame PCDE avalia. Leia de cima a baixo ou pule para uma seção.
Plataforma global de e-commerce que requer transações ACID, forte consistência e 99.999% de disponibilidade em múltiplos continentes.
Cloud Spanner com uma configuração multirregional (por exemplo, nam-eur-asia).
Por quê: Spanner é o único serviço gerenciado do GCP que oferece transações ACID distribuídas globalmente, fortemente consistentes em escala, com um SLA de 99.999%.
Migrando um grande banco de dados Oracle OLTP de alto desempenho com procedimentos armazenados complexos e necessidades de consulta analítica.
AlloyDB for PostgreSQL.
Por quê: AlloyDB oferece desempenho superior de PostgreSQL, recursos de compatibilidade com Oracle e um motor colunar para acelerar consultas analíticas (HTAP) sem impactar as cargas de trabalho transacionais.
Ingestão de dados de séries temporais de alto throughput (milhões de OPS) (por exemplo, IoT, logs) que requer leituras de baixa latência e expiração automática de dados.
Cloud Bigtable com um design de chave de linha `(entity_id)#(reverse_timestamp)` e uma política de coleta de lixo.
Por quê: Bigtable é projetado para cargas de trabalho de chave/valor de baixa latência e escala massiva. Um timestamp reverso na chave de linha co-localiza dados recentes para varreduras eficientes. A coleta de lixo gerencia o TTL.
Aplicativo móvel ou web que requer um esquema flexível, sincronização de dados em tempo real com clientes e suporte offline.
Firestore em Modo Nativo.
Por quê: Firestore é construído especificamente para este padrão de backend de aplicativo serverless, fornecendo listeners em tempo real e persistência offline através de seus SDKs de cliente prontos para uso.
Pesquisa de similaridade em grande escala (mais de 10 milhões de vetores) para aplicações de IA/ML (por exemplo, RAG, recomendações) que necessitam de latência inferior a 100ms.
AlloyDB for PostgreSQL com extensão pgvector e um índice ScaNN.
Por quê: AlloyDB integra o algoritmo ScaNN de alto desempenho do Google para pesquisa de vizinhos mais próximos aproximada (ANN), superando implementações padrão de pesquisa de vetores em escala.
Projetando um esquema do Cloud Spanner para uma carga de trabalho com muitas escritas para evitar hotspots em um único servidor.
Projetar chaves primárias que não utilizem valores monotonicamente crescentes (por exemplo, IDs sequenciais, timestamps) como a primeira parte da chave. Use UUIDs, valores hashed ou sequências bit-reversed em vez disso.
Por quê: Spanner distribui dados lexicograficamente pela chave primária. Chaves sequenciais direcionam todas as escritas para um único split, criando um hotspot. Chaves distribuídas aleatoriamente espalham as escritas por todos os splits.
Um esquema do Spanner possui uma forte relação pai-filho (por exemplo, Clientes e Pedidos) e as consultas frequentemente buscam um pai com todos os seus filhos.
Use tabelas intercaladas, definindo a tabela filha com `INTERLEAVE IN PARENT`.
Por quê: A intercalação co-localiza fisicamente as linhas filhas com suas linhas pai no armazenamento. Isso torna as junções pai-filho extremamente eficientes, pois se torna uma varredura de intervalo altamente otimizada em um único split.
Monitoramento de localizações em tempo real para uma frota massiva de veículos (50k+ escritas/seg) com consultas para encontrar veículos dentro de uma área geográfica.
Cloud Bigtable com uma chave de linha prefixada por um GeoHash da localização do veículo.
Por quê: Bigtable lida com o throughput de escrita extremo. A codificação GeoHash converte coordenadas 2D em uma string 1D onde os prefixos representam proximidade geográfica, permitindo varreduras de intervalo geoespaciais eficientes.
Armazenar e analisar dados em escala de petabytes (por exemplo, dados genômicos, logs) com consultas SQL analíticas complexas.
Armazene dados brutos no Cloud Storage e consulte-os diretamente do BigQuery usando tabelas externas, ou carregue para o armazenamento nativo do BigQuery.
Por quê: BigQuery é um data warehouse serverless construído para análises em escala de petabytes. Sua separação de armazenamento e computação oferece desempenho de consulta incomparável e custo-benefício para cargas de trabalho OLAP.
Um cache em memória de alta disponibilidade para estruturas de dados complexas (hashes, sets) com capacidades pub/sub para invalidação de cache.
Memorystore for Redis Standard Tier com réplicas de leitura.
Por quê: O Standard Tier oferece um SLA de 99.9% com failover automático. Redis suporta tipos de dados complexos e pub/sub, diferentemente do Memcached. As réplicas de leitura podem escalar o throughput de leitura.
Projetando uma aplicação SaaS multi-tenant no Spanner que requer forte isolamento de dados e garantias de desempenho por tenant.
Use tenant_id como o primeiro componente da chave primária para todas as tabelas. Para um isolamento mais forte, use um modelo de banco de dados por tenant dentro de uma única instância do Spanner.
Por quê: Um prefixo tenant_id co-localiza naturalmente todos os dados de um único tenant, otimizando consultas e permitindo que o Spanner divida os dados por tenant. O banco de dados por tenant oferece o isolamento lógico mais forte.
Um banco de dados Cloud SQL está enfrentando desempenho de consulta lento e alto uso de CPU.
Use Query Insights para identificar as consultas mais intensivas em recursos, analisar seus planos de execução e identificar índices ausentes ou padrões ineficientes.
Por quê: Query Insights é a ferramenta principal e integrada para diagnosticar o desempenho de consultas no Cloud SQL. Ele visualiza a carga de consulta, identifica eventos de espera e ajuda a identificar a causa raiz sem ferramentas de terceiros.
Uma organização precisa de um único painel e conjunto de políticas de alerta para dezenas de instâncias de banco de dados espalhadas por múltiplos projetos GCP.
Crie um workspace do Cloud Monitoring em um projeto central e configure seu "escopo de métricas" para incluir todos os projetos contendo instâncias de banco de dados.
Por quê: Os escopos de métricas permitem que um único workspace de Monitoramento agregue e exiba métricas de múltiplos projetos, fornecendo uma visão unificada sem duplicação de dados ou configuração complexa.
Necessidade de provisionar e gerenciar instâncias do Cloud SQL em ambientes de desenvolvimento, staging e produção de forma consistente e com controle de versão.
Use Terraform com o provedor Google Cloud. Defina um módulo Cloud SQL e use arquivos `.tfvars` separados para cada ambiente.
Por quê: Terraform fornece Infraestrutura como Código (IaC), permitindo implantações repetíveis, auditáveis e com controle de versão. Isso evita erros de configuração manual e garante consistência entre os ambientes.
Um contratado precisa de acesso temporário elevado ao banco de dados que deve ser revogado automaticamente após 4 horas.
Conceda o papel IAM necessário com uma Condição IAM que usa uma expressão baseada em tempo (`request.time < timestamp(...)`).
Por quê: As Condições IAM fornecem uma maneira nativa e segura de conceder acesso com tempo limitado sem limpeza manual, que é propensa a erros. O acesso é negado automaticamente após a expiração do timestamp.
Uma política de segurança exige que toda a criptografia de disco de banco de dados utilize chaves gerenciadas pelo cliente (CMEK) com rotação controlada.
Configure a instância do Cloud SQL ou AlloyDB para usar uma chave do Cloud KMS. Configure a rotação automática na chave KMS.
Por quê: CMEK oferece controle e auditabilidade sobre as chaves usadas para criptografia em repouso. O Cloud KMS gerencia o ciclo de vida das chaves, incluindo rotação automatizada, de forma integrada.
A conformidade exige a captura de todas as consultas SQL executadas em uma instância do Cloud SQL para PostgreSQL, com logs retidos por 7 anos.
Habilite a extensão `pgaudit` na instância. Configure os Cloud Audit Logs para Acesso a Dados. Crie um coletor de logs do Cloud Logging para o BigQuery para retenção e análise de longo prazo.
Por quê: pgaudit fornece auditoria detalhada em nível SQL. O envio de logs para o BigQuery é o padrão, um modelo custo-efetivo para retenção de logs de longo prazo e pesquisáveis além do padrão do Cloud Logging.
Analistas de dados precisam executar consultas analíticas pesadas em dados de produção do Cloud SQL sem impactar a carga de trabalho transacional.
Crie uma réplica de leitura e direcione todas as consultas analíticas para ela. Para análises mais complexas, use consultas federadas do BigQuery contra a réplica de leitura.
Por quê: Uma réplica de leitura isola completamente o tráfego de leitura analítica da instância primária, protegendo o desempenho do OLTP. A federação permite usar o poderoso motor do BigQuery sem um pipeline ETL separado.
Um cluster Bigtable apresenta carga de CPU irregular, com alguns nós muito utilizados enquanto outros estão ociosos, indicando um gargalo de desempenho.
Use a ferramenta Key Visualizer no Cloud Console para analisar os padrões de acesso e identificar os intervalos de chaves de linha específicos que estão sendo acessados com muita frequência (hotspotting).
Por quê: Key Visualizer é a ferramenta de diagnóstico desenvolvida especificamente para problemas de desempenho do Bigtable. Ela fornece um mapa de calor do acesso às chaves, facilitando a identificação de hotspots que precisam ser resolvidos por meio de um redesenho de esquema.
É preciso replicar mudanças de um banco de dados OLTP do Cloud SQL para um data warehouse BigQuery em tempo quase real.
Use o Datastream para configurar um fluxo de Change Data Capture (CDC) da instância de origem do Cloud SQL diretamente para o BigQuery.
Por quê: Datastream é um serviço CDC gerenciado e de baixa latência que lê logs de banco de dados, minimizando o impacto na origem. Ele lida com a deriva do esquema e entrega as alterações de forma confiável ao BigQuery.
Uma aplicação Cloud Run está esgotando as conexões do banco de dados devido à escalabilidade rápida durante picos de tráfego.
Implante o Cloud SQL Auth Proxy como um container sidecar e configure-o para pooling de conexões (ou use-o com um pooler dedicado como PgBouncer).
Por quê: Plataformas serverless podem escalar para milhares de instâncias, sobrecarregando os limites de conexão do banco de dados. Um pooler de conexões multiplexa essas numerosas e efêmeras conexões de aplicação em um conjunto pequeno e estável de conexões de banco de dados.
Migrando um grande banco de dados MySQL on-premises (5TB) para o Cloud SQL for MySQL com um tempo máximo de inatividade de 30 minutos.
Use o Database Migration Service (DMS) para configurar um trabalho de replicação contínua. O DMS realiza uma carga inicial e, em seguida, transmite as alterações até a transição.
Por quê: DMS é a solução gerenciada para migrações com tempo de inatividade mínimo. A replicação contínua significa que o único tempo de inatividade é o tempo necessário para parar as escritas, esperar pela sincronização final e apontar a aplicação para o novo banco de dados.
Migrando um banco de dados Oracle para o AlloyDB for PostgreSQL, incluindo procedimentos armazenados PL/SQL complexos.
Use o DMS para migração de dados. Use ferramentas de conversão de esquema (como Ora2Pg ou DMS Schema Conversion) para converter esquemas e PL/SQL para PL/pgSQL, seguido por revisão e testes manuais.
Por quê: Migrações heterogêneas exigem tanto a migração de dados (tratada pelo DMS) quanto a conversão de esquema/código. Ferramentas automatizadas lidam com ~80% da conversão, mas o esforço manual é sempre necessário para recursos específicos do Oracle.
É necessário verificar a integridade e a completude dos dados após migrar um banco de dados de um datacenter on-premises para o Google Cloud.
Use a ferramenta de validação de dados de código aberto (DVT). Configure-a para comparar contagens de linhas, agregações em nível de coluna (min, max, sum) e hashes em nível de linha entre a origem e o destino.
Por quê: DVT fornece uma estrutura abrangente, escalável e personalizável para validação de dados que vai além de simples contagens de linhas, detectando corrupção sutil de dados ou problemas de transformação.
Migrando uma aplicação MySQL sharded para um único banco de dados globalmente consistente.
Use múltiplos trabalhos Dataflow paralelos para migrar cada shard concorrentemente para um único banco de dados Cloud Spanner. Redesenhe o esquema para eliminar a necessidade de sharding em nível de aplicação.
Por quê: Spanner é projetado para substituir arquiteturas sharded complexas. Uma abordagem de migração paralela com Dataflow é a maneira mais eficiente em termos de tempo para consolidar grandes conjuntos de dados sharded no Spanner.
Migrando um banco de dados SQL Server que usa Autenticação Windows (Active Directory) para o Cloud SQL for PostgreSQL.
Integre o Cloud SQL com o Cloud Identity usando a autenticação de banco de dados IAM. Sincronize grupos do AD para Grupos Google via GCDS e mapeie papéis de banco de dados para esses grupos.
Por quê: Esta abordagem replica o modelo de controle de acesso centralizado e baseado em grupos do AD de forma nativa na nuvem, evitando o gerenciamento manual de usuários/senhas e aproveitando estruturas de identidade existentes.
Migrando uma aplicação do Amazon DynamoDB para o Cloud Bigtable.
Mapeie a chave primária composta do DynamoDB (partition key + sort key) para uma chave de linha concatenada do Bigtable, separada por um delimitador (por exemplo, `partitionKey#sortKey`).
Por quê: Este design de chave de linha preserva as capacidades de consulta da chave composta do DynamoDB, permitindo buscas eficientes por prefixo da chave de partição e varreduras de intervalo na parte da chave de ordenação.
Uma aplicação que se conecta a uma instância do Cloud SQL de alta disponibilidade deve sobreviver a um failover zonal sem intervenção manual.
Conecte-se ao banco de dados usando o Cloud SQL Auth Proxy com o nome de conexão da instância (project:region:instance), não um endereço IP estático.
Por quê: O endereço IP da instância muda durante um failover. O Auth Proxy e o nome de conexão da instância fornecem um endpoint estável que se resolve automaticamente para o endereço IP da instância primária atual.
Uma aplicação Spanner global tem usuários na América do Norte e na Ásia. As escritas se originam principalmente na América do Norte, mas os usuários asiáticos precisam de leituras de baixa latência.
Use uma configuração multi-região com a região líder na América do Norte (`nam*`). As leituras na Ásia serão atendidas por réplicas locais somente leitura.
Por quê: As escritas no Spanner são roteadas através da região líder, então colocá-la perto da fonte de escrita minimiza a latência de escrita. Réplicas de leitura em outras regiões fornecem leituras de baixa latência para usuários distribuídos globalmente.
Uma aplicação baseada em AlloyDB tem uma proporção de leitura para escrita de 10:1 e precisa escalar para lidar com alto tráfego de leitura, mantendo 99.99% de disponibilidade.
Configure a instância primária com alta disponibilidade e adicione múltiplas instâncias de pool de leitura. Direcione o tráfego de leitura para o pool de leitura.
Por quê: A alta disponibilidade do AlloyDB oferece o SLA de 99.99%. As instâncias do pool de leitura são projetadas para escalabilidade de leitura horizontal, desviando o tráfego da instância primária para nós dedicados otimizados para leitura.
Uma instância do Cloud SQL sensível à latência com armazenamento SSD tem desempenho de I/O insuficiente.
Aumente o tamanho do armazenamento provisionado da instância.
Por quê: No Cloud SQL, tanto os IOPS de leitura quanto os de escrita escalam linearmente com a quantidade de armazenamento em disco persistente provisionado. Aumentar o tamanho do disco é a maneira direta de aumentar os IOPS disponíveis.
É necessário implantar uma alteração de esquema arriscada em um banco de dados Cloud SQL crítico com capacidade de reversão rápida.
Crie uma réplica de leitura da instância de produção (azul). Promova a réplica para uma instância autônoma (verde), aplique e valide as alterações de esquema. Em seguida, redirecione o tráfego da aplicação para a instância verde. Mantenha a azul em execução para reversão.
Por quê: Este padrão permite o teste completo de alterações em uma cópia dos dados em escala de produção sem impactar o sistema em produção. O tráfego pode ser alternado instantaneamente, e a reversão é tão simples quanto apontar o tráfego de volta para a instância azul.
É preciso testar um plano de recuperação de desastres de banco de dados trimestralmente sem afetar o ambiente de produção.
Crie uma instância de teste temporária restaurando a partir de um backup de produção recente. Execute os procedimentos de DR documentados contra esta instância de teste, incluindo failover simulado e testes de reconexão de aplicação.
Por quê: Testar em um backup restaurado fornece um ambiente realista para validar RTO/RPO e procedimentos de recuperação sem o risco de causar uma interrupção na produção.
Um serviço Cloud Run precisa se conectar a uma instância do Cloud SQL de forma segura, sem que o tráfego atravesse a internet pública.
Configure o Cloud SQL com um IP privado. Crie um conector Serverless VPC Access na mesma VPC e configure o serviço Cloud Run para rotear o tráfego através dele.
Por quê: Este é o padrão seguro e comum para conectar computação serverless a recursos nativos da VPC. O conector faz a ponte entre o ambiente serverless e sua VPC, mantendo todo o tráfego na rede privada do Google.
Adicionando uma nova coluna não-nula a uma tabela massiva do Cloud Spanner com escrita ativa, sem tempo de inatividade.
1. Adicione a coluna como anulável. 2. Atualize o código da aplicação para escrever na nova coluna. 3. Preencha as linhas existentes em lotes usando o Dataflow. 4. Após o preenchimento, altere a coluna para ser NOT NULL.
Por quê: Este processo de várias etapas é o padrão de alteração de esquema online para grandes tabelas. Ele evita bloquear a tabela por uma longa duração ou causar uma operação massiva de preenchimento (backfill) que impacta o desempenho em uma única transação.
