Amazon SAP-C02: Bancos de Dados e Analytics — Guia de estudos

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

Faz parte do AWS Solutions Architect Professional SAP-C02 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Bancos de Dados Transacionais, Padrões de Escalabilidade e Caching

A escolha entre Amazon RDS (MySQL/PostgreSQL/Oracle/SQL Server), Amazon Aurora e Amazon DynamoDB começa com o perfil da carga de trabalho: um esquema relacional estrito e transações complexas favorecem o RDS/Aurora; escala massiva, buscas com latência de milissegundos de um dígito e esquema flexível favorecem o DynamoDB. O Aurora oferece alto throughput com armazenamento distribuído, autoescalabilidade de réplicas, failover rápido, Global Database para leituras entre regiões e recuperação de desastres com menor latência. O RDS Multi-AZ fornece replicação síncrona para disponibilidade, mas não para escalabilidade de leitura; réplicas de leitura (RDS/Aurora) lidam com cargas de trabalho com uso intensivo de leitura. Para caching de chave-valor e latência de microssegundos, o ElastiCache (Redis ou Memcached) reduz a carga no banco de dados; o MemoryDB for Redis adiciona durabilidade e persistência compatível com Redis onde os dados precisam ser altamente disponíveis e recuperáveis. Armadilhas comuns incluem subestimar os limites de conexão (conexões máximas do MySQL), não usar pooling de conexões (Lambda/contêineres criando muitas conexões), partições quentes no DynamoDB por design de chave inadequado e negligenciar o design/remoção do cache, levando à obsolescência dos dados. Os trade-offs de decisão geralmente se concentram em custo versus performance e resiliência: instâncias provisionadas do Aurora ou RDS de grande porte custam mais, mas reduzem a latência e simplificam as transações, enquanto o DynamoDB com modo on-demand ou autoescalabilidade pode diminuir a carga operacional, mas exige um planejamento cuidadoso de esquema e capacidade. Criptografia, backups automatizados, PITR e padrões de replicação entre regiões devem ser escolhidos de acordo com o RPO/RTO.

Data Lake, ETL e Mecanismos de Consulta Analítica

O S3 é o data lake durável canônico; projete em torno de particionamento, formatos colunares (Parquet/ORC), compressão e compactação para impulsionar consultas com bom custo-benefício. O AWS Glue e o AWS Glue Data Catalog fornecem ETL serverless, descoberta de esquema e catalogação; o Lake Formation adiciona controle de acesso centralizado, permissões granulares e compartilhamento entre contas para data lakes governados. Para análises interativas, o Amazon Athena consulta dados do S3 diretamente (serverless, pague por consulta), enquanto o Amazon Redshift (com suporte a RA3/Iceberg) fornece um data warehouse MPP gerenciado e de alta performance para BI complexo e joins. Use o Redshift Spectrum para consultar dados do S3 a partir do Redshift sem precisar ingerir tudo. O Kinesis Data Firehose é um caminho de ingestão gerenciado para depositar eventos de streaming no S3 ou no Redshift. Armadilhas comuns de arquitetura incluem o excesso de arquivos pequenos, que causa alto overhead no Athena/Redshift, chaves de partição mal escolhidas que criam desbalanceamento (skew) e a falha em compactar ou converter para formatos colunares. Os trade-offs são latência versus custo: o Athena tem baixo custo operacional para consultas ad-hoc; o Redshift fornece performance sustentada mais alta a um custo provisionado maior. A governança e a linhagem de dados via Glue/Lake Formation são essenciais para conformidade e para a propriedade compartilhada entre múltiplas equipes.

Streaming, Processamento em Tempo Real e Busca

A ingestão e o processamento em tempo real usam o Kinesis Data Streams (throughput baseado em shards e garantias de ordenação), o Kinesis Data Firehose (entrega gerenciada para destinos, ou sinks), o Kinesis Data Analytics (processamento com SQL/Apache Flink) ou o Amazon MSK para necessidades compatíveis com Kafka. Escolha o Kinesis para uma integração serverless nativa da AWS direta; escolha o MSK quando os clientes dependem das ferramentas do ecossistema Kafka. A semântica de entrega “pelo menos uma vez” (at-least-once), os limites de shards, o paralelismo de consumidores e o provisionamento de shards adequados são obstáculos operacionais comuns. Para busca rápida e observabilidade downstream, o Amazon OpenSearch Service fornece indexação, busca em tempo quase real e dashboards Kibana integrados; o gerenciamento do ciclo de vida dos índices e as camadas warm/cold reduzem o custo para dados mais antigos. Use Kinesis + Lambda ou Kinesis + KDA para enriquecer/transformar eventos antes de persisti-los no OpenSearch ou S3. Projete idempotência e desduplicação nos consumidores, pois novas tentativas (retries) ou replays causam duplicatas. Os critérios de decisão equilibram throughput e latência: o Kinesis com muitos shards suporta alto throughput, mas aumenta o custo e o gerenciamento; o Firehose remove a carga do consumidor, mas oferece uma transformação menos flexível.

Migração, Replicação, Governança e Resiliência Operacional

O Database Migration Service (AWS DMS) e a Schema Conversion Tool (SCT) são as principais ferramentas de migração para movimentações homogêneas e heterogêneas, permitindo a captura contínua de dados alterados (CDC). Os padrões de migração incluem rehost (lift-and-shift), replatform (por exemplo, mover para o Aurora) e refactor para o DynamoDB ou serverless, quando apropriado. Use o DMS com validação pré e pós-migração, cópia de tabelas em paralelo e manuseio cuidadoso de LOB/LOBLOB. A replicação entre contas e entre regiões exige acesso à chave do KMS, VPC peering ou Transit Gateway e planejamento de largura de banda de rede; Global Databases e réplicas de leitura (read replicas) são alternativas quando leituras de baixa latência entre regiões são necessárias. A governança e a segurança devem incluir o Lake Formation para compartilhamento de dados, o princípio de menor privilégio do IAM, políticas de recursos para snapshots do S3 e do RDS e VPC endpoints/PrivateLink para evitar saída (egress) pública. Armadilhas operacionais incluem monitoramento insuficiente (atraso de réplica não percebido), não testar failover/runbooks e custos de saída (egress) ocultos durante transferências em massa. A estratégia de backup e PITR (Point-in-Time Recovery) e a recuperação automatizada entram nos trade-offs de RTO/RPO; combine a replicação para disponibilidade com backups regulares para retenção de longo prazo e conformidade.

Problema Prático: Cenário de Caso de Uso

Cenário: A Acme Retail opera uma plataforma de e-commerce em uma AWS Organization com várias contas, com cargas de trabalho de produção em us-east-1 e europe-west-1. Eles armazenam clickstreams e eventos de transação no S3 e operam um banco de dados OLTP on-premises que precisa ser migrado para a AWS com tempo de inatividade mínimo.

Desafio: Migrar o banco de dados OLTP para um destino altamente disponível e escalável para leitura entre regiões, ao mesmo tempo em que se constrói um lago analítico governado no S3 com capacidade de ingestão e consulta em tempo real.

Abordagem Recomendada:

Use o AWS DMS com a SCT para conversão de esquema e configure o CDC contínuo do banco de dados on-premises para o Amazon Aurora (Global Database) em us-east-1 com uma réplica de leitura (read replica) do Aurora em europe-west-1.
Ingerir eventos de clickstream e transação via Amazon Kinesis Data Streams e Firehose; fazer o buffer e entregar os eventos brutos para o S3 em formato Parquet, particionados por data e região.
Catalogar os dados do S3 com o AWS Glue, impor controle de acesso via Lake Formation e executar ETL com jobs do Glue (ou Glue Studio) para produzir conjuntos de dados curados; expô-los aos analistas via Amazon Athena e Redshift Spectrum.
Adicionar ElastiCache (Redis) para cache de alta leitura de dados de produtos e sessões acessados com frequência (hot data); instrumentar o monitoramento de ponta a ponta com o CloudWatch, habilitar o Enhanced Monitoring no Aurora e validar o failover com runbooks.

Justificativa: Esta abordagem minimiza o tempo de inatividade usando o CDC do DMS, fornece leituras globais de baixa latência via Aurora Global Database, estabelece um data lake governado no S3 para agilidade analítica e reduz a carga nos sistemas OLTP com cache e ingestão de streaming desacoplada, em linha com as melhores práticas de resiliência e desempenho corporativo.

← Armazenamento e Gerenciamento de Dados · Todos os domínios · Migração e Modernização →

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