Automatizando Qualidade de Dados em Pipelines

Qualidade de dados é o único tópico do Domínio 3 do qual os outros tópicos dependem silenciosamente: um pipeline perfeitamente orquestrado que move linhas erradas no horário é pior do que nenhum pipeline. O guia de exame DEA-C01 declara o requisito como uma única habilidade, "Execute verificações de qualidade de dados enquanto processa os dados (por exemplo, verificando campos vazios)" (Tarefa 3.4.1, guia do exame DEA-C01, acesso em outubro de 2026), e tudo o que é examinável depende da palavra while. Um perfil semanal da zona de landing é um relatório; uma verificação que roda dentro do job, separa as linhas e faz o gate do próximo passo é engenharia.

Nesta lição você vai:

• ler as cinco subdeclarações da Tarefa 3.4 e defender a regra do "while processing" contra distractors de fim de pipeline;
• mapear as seis dimensões de qualidade às expressões nativas da AWS e aos cenários que o exame escreve;
• montar a lista de sete verificações em voo, nulos/vazios, esquema, integridade referencial, duplicatas, faixa/enumerado, atualidade/watermark, volume, em DQDL, DataBrew e PySpark;
• operar o AWS Glue Data Quality: regras, analyzers, rulesets, os 26 tipos de regra do Studio, resultados no nível da linha, as três ações de falha e as opções de publicação;
• operar a qualidade do AWS Glue DataBrew: anatomia de regra, rulesets que rodam em profile jobs, findings, relatório de validação, eventos, agendamentos e amostragem;
• ligar os padrões de qualidade de jobs do Glue: asserções no script, tabelas de erro, o padrão do prefixo de quarentena e destinos de dead-letter em streaming;
• detectar drift de esquema: job bookmarks versus DynamicFrame resolveChoice, SchemaChangePolicy do crawler, versões de tabela do Data Catalog e alertas de drift;
• fazer o gate da orquestração com payloads do EventBridge e um Choice do Step Functions sobre state e score, e publicar um dashboard de qualidade;
• decidir quarentena versus falhar o job, e por que o guia de exame quer verificação em voo em vez de qualidade no fim;
• estudar quatro estudos de caso de clientes da AWS, uma caixa de atualizações de outubro de 2026 com fontes e 14 questões estilo exame mais quatro verificações interativas.

---

1. Tarefa 3.4: o que "processar enquanto" realmente significa

1.1 As cinco subdeclarações

A armadilha está escrita na primeira linha: "profile semanal da zona de landing" é um relatório sobre os dados de ontem, não uma verificação enquanto os dados são processados. Alternativas construídas em "carregue tudo, depois profile às sextas-feiras" foram feitas para reprovar a 3.4.1.

1.2 Qualidade no fim versus em voo

Os dois têm seu lugar: uma avaliação at rest contra o Data Catalog é legítima para monitorar uma tabela que já está aterrissando. Mas quando a linha de habilidade da questão é a 3.4.1, a resposta é uma verificação que roda durante o processamento ou que faz o gate do próximo passo.

1.3 Qual ferramenta: a matriz de três vias

A própria tabela de Prescriptive Guidance da AWS é a ajuda mais rápida de "qual ferramenta" neste exame:

• 📚 Você sabia? O AWS Glue Data Quality é construído sobre o Deequ de código aberto, "uma biblioteca usada internamente pela Amazon para gerenciar a qualidade de lagos de dados com mais de 60 PB" (AWS Big Data Blog, 06-06-2023). É por isso que o amazon-deequ-glue existe como um exemplo da AWS, mas Deequ-como-produto, Great Expectations, dbt e Soda não estão na lista de escopo do DEA-C01, então uma alternativa construída em torno deles nunca é a melhor resposta.

---

2. As seis dimensões, mapeadas aos cenários do exame

2.1 Dimensão → expressão AWS → cenário

A pontuação de qualidade de dados é simplesmente "a porcentagem de regras de qualidade de dados que passam (resultam em true) quando você avalia um ruleset" (documentação do AWS Glue Data Quality, acesso em outubro de 2026): um número entre 0 e 1.0, não uma nota de aprovação por si só.

2.2 Exemplo trabalhado E1: completude que se esconde atrás de uma string

Uma coluna CSV email chega com 1.000.000 de linhas. No arquivo bruto, 3.000 linhas carregam um campo vazio. Duas regras são escritas sobre os mesmos dados:

Leitura: as mesmas 3.000 linhas ruins podem passar ou falhar dependendo do tipo que o leitor infere. É por isso que regras de completude são escritas depois da coerção de tipo, na fronteira de estágio pós-cast, e é por isso que "verificar campos vazios" na 3.4.1 é uma habilidade de posicionamento tanto quanto de escrita de regras.

2.3 Combine cada dimensão com sua assinatura de exame

• 📚 Você sabia? Das seis dimensões, a unicidade é a que mais frequentemente é "imposta" por uma restrição que não impõe nada: o Amazon Redshift afirma que "unicidade, chave primária e chave estrangeira são apenas informativas; elas não são impostas pelo Amazon Redshift quando você popula uma tabela", enquanto "o Amazon Redshift impõe sim restrições de coluna NOT NULL" (documentação do Redshift, acesso em outubro de 2026). Então um INSERT de chave primária duplicada sucede, um INSERT de NULL numa coluna NOT NULL falha, e ambos os comportamentos são examináveis como "qual DDL impede loads duplicados? Nenhuma."

---

3. A lista em voo: sete verificações, posicionadas nas fronteiras de estágio

Cada verificação abaixo pode ser escrita em DQDL (Glue Data Quality), como regra do DataBrew, ou em PySpark puro, o posicionamento é o que rende a marca da 3.4.1.

3.1 Nulo / vazio

3.2 Validação de esquema

ColumnExists, ColumnDataType, ColumnLength, ColumnNamesMatchPattern, SchemaMatch. Um job com destino S3 habilita por padrão uma regra de "pelo menos uma coluna" mais detecção de anomalia na contagem de colunas: uma falha baixa a pontuação mas não falha o job (tutorial do Glue, acesso em outubro de 2026). Regras de esquema respondem validade; drift (Seção 7) responde o que mudou desde a última vez.

3.3 Integridade referencial

3.4 Duplicatas

3.5 Faixa / enumerado

3.6 Atualidade / watermark

Bookmarks dão escopo incremental, não validação: eles rastreiam arquivos e linhas processados e fazem nenhuma verificação de esquema (Seção 7). Streaming usa checkpoints, e a janela padrão do Glue streaming é de 100 segundos.

3.7 Volume

RowCount between X and Y, RowCountMatch, AggregateMatch, CustomSql: "quase qualquer tipo de verificação de qualidade de dados em SQL" (tipos de regra DQDL, acesso em outubro de 2026). Regras de volume são o jeito mais barato de capturar "a origem enviou 4% das linhas de ontem" antes que agregações a jusante publiquem silenciosamente um número pequeno.

3.8 Exemplo trabalhado E2: atualidade contra um SLA

Um SLA diz que pedidos não podem ter mais de 24 horas quando a tabela curada é publicada às 02:00 UTC.

Dois sinais, uma decisão: a regra DQDL limita as linhas, a comparação de watermark limita o load. Alternativas de exame que oferecem apenas uma delas geralmente estão testando se você sabe qual falha cada uma captura.

---

4. AWS Glue Data Quality: DQDL, rulesets, resultados

4.1 Três objetos, dois pontos de entrada

O Studio oferece 26 tipos de regra; uma avaliação de resultados grava no S3 (opcionalmente em tabelas Iceberg/Data Catalog que você pode consultar com Athena), e a detecção de anomalia "requer um mínimo de três pontos de dados".

4.2 O que acontece quando um ruleset falha

4.3 Resultados no nível da linha, e as onze regras que não os produzem

rowLevelOutcomes acrescenta quatro colunas e um status Passed/Failed por linha. Onze tipos de regra não podem ser atribuídos a linhas, AggregateMatch, ColumnCount, ColumnExists, ColumnNamesMatchPattern, CustomSql, RowCount, RowCountMatch, StandardDeviation, Mean, ColumnCorrelation (tutorial do Glue, acesso em outubro de 2026). Então "quais linhas falharam?" é respondido por regras com escopo de linha num job ETL, nunca por uma avaliação de Catalog, e nunca por uma regra agregada.

4.4 Exemplo trabalhado E3: pontuação, e por que você roteia por state, não por score

Um ruleset de 6 regras roda: 4 passam, 2 falham.

Uma regra ignorada não conta como aprovada: a pontuação é regras que passaram sobre as regras avaliadas, então nunca assuma que state e score concordam.

5. AWS Glue DataBrew: regras, rulesets, findings

5.1 Anatomia de uma regra

Exemplos de checks do material próprio da AWS: Number of rows = 5000000, Duplicate rows, Unique values = 100% rows, Value is not missing >= 100% rows, Value in column APY between 0 and 100, Number of missing values in column group_name doesn't exceed 5%.

5.2 Rulesets rodam em profile jobs, não em recipe jobs

O CreateRuleset é documentado como "cria um novo ruleset que pode ser usado em um profile job para validar a qualidade de dados de um dataset". Recipe jobs aplicam passos de recipe: essa família popula valores ausentes, remove dados inválidos e remove duplicatas, o que é remediação, não validação. A afirmação falsa canônica neste exame é "anexe o ruleset ao recipe job".

Cotas que as questões citam literalmente (em outubro de 2026): 100 regras por ruleset, 10 rulesets por dataset, 100 rulesets por conta, 100 passos por recipe, 300 nós por conta.

5.3 Findings, relatório de validação e eventos

• Saídas do profile: Summary, Correlations, Value distribution, Column Summary, mais uma aba Column statistics.
• Resultados da validação: na aba Data quality rules / Data quality da execução do job.
• Ajuda do construtor: uma aba Dataset preview e uma aba Recommendations enquanto você autora.
• Relatório: o profile job "produz um relatório de validação além do perfil de dados … na mesma localização dos seus dados de perfil".
• Eventos: um evento do EventBridge por execução e por ruleset:

Uma regra com esse padrão casa todas as validações com falha na conta, o payload examinável é detail-type + validationState, não um ARN por dataset.

5.4 Amostragem (Tarefa 3.4.4)

A redação própria da AWS: "Um tamanho de amostra menor permite ao DataBrew realizar transformações mais rápido … Um tamanho de amostra maior reflete com mais precisão a composição dos dados de origem subjacentes."

• 📚 Você sabia? Os agendamentos do DataBrew são expressões cron de seis campos com um piso rígido: "expressões cron que resultam em taxas mais rápidas que 5 minutos não são suportadas", e dia-do-mês versus dia-da-semana são exclusivos (use ? para um deles). Então a alternativa "a cada 2 minutos, valide o stream" está errada por duas razões independentes, o DataBrew não é um processador de stream, e seu relógio não consegue bater tão rápido (documentação de jobs do DataBrew, acesso em outubro de 2026).

5.5 Exemplo trabalhado E4: um ruleset de RH que cabe nas cotas

Cinco regras sobre um extrato noturno de RH de 5.000.000 de linhas:

5.6 Skew (Tarefa 3.4.5), o gêmeo da dimensão de atualidade

Skew não corrompe linhas; ele destrói a atualidade da execução. Detecte-o com as métricas do driver glue.driver.skewness.job e glue.driver.skewness.stage, a UI do Spark ou estatísticas de tamanho de partição. Mitigações documentadas pela AWS: filtragem de chaves quentes, agregação incremental, salting, broadcast joins, repartition/coalesce, adaptive query execution (padrão no Glue 4.0+), particionamento de entrada e escala vertical: a conclusão da própria AWS é que "não existe uma solução universal única". No exame, "uma task roda 40 minutos enquanto as outras 39 terminam em 30 segundos" ⇒ skew, e a correção nomeada na alternativa é salting na chave quente ou broadcast da tabela pequena.

---

6. Padrões de qualidade de jobs do Glue: asserções, tabelas de erro, quarentena

6.1 Asserções no script, o gate em voo mais forte

Forma em Scala do tutorial da AWS: assert(DQ_Results.filter(_.getField("Outcome").contains("Failed")).count == 0, "…caused the job to fail."). Uma asserção transforma uma pontuação em um job com falha, que é como "rodar verificações enquanto processa" aparece quando a alternativa diz pare antes que dados ruins aterrissem.

6.2 Tabelas de erro, e o nome que não existe

6.3 O padrão do prefixo de quarentena

"O AWS Glue Data Quality ajuda você a identificar os registros exatos que fizeram suas pontuações de qualidade cairem. Identifique-os com facilidade, coloque-os em quarentena e corrija-os.": página de produto do AWS Glue Data Quality, acesso em outubro de 2026

A amostra de referência InsuranceLake da AWS enuncia o contrato com precisão: "A ação de quarentena remove as linhas individuais que falham na verificação de qualidade … e as armazena em uma localização de armazenamento de quarentena separada e em uma tabela do Data Catalog", com regras aplicadas imediatamente depois do schema mapping … antes de qualquer transformação ser executada, nos estágios before_transforms / after_transforms / after_sparksql, e a pasta S3 <table>_quarantine_* e a tabela do catálogo são criadas independentemente de alguma linha ter sido colocada em quarentena, então o monitoramento a jusante nunca precisa adivinhar se o caminho existe.

6.4 Streaming: o lado de dead-letter da qualidade

Para consumidores Lambda do Kinesis/Kinesis Data Firehose, o caminho de falha de qualidade é o on-failure destination, não um alarme de console: DestinationConfig.OnFailure → SQS, SNS, S3 ou Amazon MSK, com BisectBatchOnFunctionError para isolar o registro venenoso, MaximumRetryAttempts 0 to 10.000, MaximumRecordAgeInSeconds 60 to 604.800, e ReportBatchItemFailures retornando batchItemFailures para tratamento parcial de lote. Uma DLQ no nível da função é o mecanismo mais antigo; o on-failure destination é o atual, e os dois não são intercambiáveis num par de alternativas. Jobs do Glue streaming usam checkpoint em vez de job bookmarks.

6.5 Exemplo trabalhado E5: a separação de quarentena

Um milhão de linhas aterrissa; o job carrega 6 regras, 4 das quais com escopo de linha:

Leia as duas metades juntas: o caminho de dados colocou 4.000 linhas em quarentena e publicou 996.000; o caminho de controle publicou state = FAILED e uma pontuação de 0,67: enquanto o job ainda reportou sucesso porque a ação era Nenhum (None). Três sinais diferentes, três respostas diferentes para "funcionou?".

---

7. Detecção de drift de esquema: o que realmente enxerga um formato alterado

7.1 Bookmarks não são detecção de drift

Combine o crawler com o evento do EventBridge Glue Data Catalog Table State Change (UpdateTable, CreatePartition, UpdatePartition, DeletePartition mais variantes em lote) para alertas de drift; o comportamento LOG significa que o catálogo nunca é mutado por um crawler só de alerta.

7.2 resolveChoice, o reparo que custa dados

O crawler amostra apenas um prefixo de 2 MB; uma fonte em que 2 linhas de 160.000 trazem strings numa coluna numérica vira choice<long,string>:

A ordem importa: resolveChoice → apply_mapping → toDF(). Escolher cast sem uma regra de completude converte um problema de esquema num problema de dados que você nunca vê.

7.3 Exemplo trabalhado E6: a ilusão da restrição no Redshift

A mesma verificação escrita como regra DQDL, IsPrimaryKey "id" = "não NULL e único", rejeita a duplicata. CHECK e restrições de exclusão são não suportadas no Redshift. Então "o load falhou porque uma duplicata de chave primária foi rejeitada" está errado, e "adicione uma regra de unicidade no job" está certo.

---

8. Orquestração: gate do pipeline pelo resultado de qualidade

8.1 Os payloads do EventBridge que você precisa reconhecer

O equivalente do DataBrew é source: aws.databrew, detail-type: DataBrew Ruleset Validation Result, detail.validationState: FAILED. O drift do crawler do Glue chega como Glue Data Catalog Table State Change. Três serviços, três strings de detail-type, o exame testa se você consegue escolher a certa.

8.2 Step Functions: o estado Choice é o gate

Semântica da Amazon States Language que vale decorar: Choices[] são avaliados em ordem, e "se nenhuma Choice for avaliada como verdadeira … e nenhum Default for fornecido, a state machine lançará um erro": é por isso que a AWS recomenda um Default.

8.3 Dashboards e métricas

O caminho documentado do QuickSight é EventBridge → Lambda → S3 → crawler → Athena → QuickSight, dando uma série temporal de pontuação em vez de um veredito por execução. As métricas do CloudWatch vivem sob dataQualityEvaluationContext (padrão desligado) e os logs sob /aws-glue/data-quality/output e /aws-glue/data-quality/error. Uma questão perguntando "como os analistas veem a tendência de qualidade em 90 dias?" é uma questão de dashboard, não de alerta: a resposta precisa de resultados armazenados mais uma camada de BI, não de um tópico SNS.

8.4 O pipeline inteiro, em uma imagem

Cada seta acima é uma dependência: nada a jusante pode existir até que o artefato a montante tenha sido produzido. Ordene o gate inteiro do mesmo jeito:

9. Quarentena versus falhar o job, e o trade-off que o exame realmente pergunta

9.1 A decisão em uma linha cada

• Em voo vence o no fim para a 3.4.1, mas uma avaliação de Catalog at rest está certa para monitorar uma tabela que já aterrissa.

• DataBrew para regras sem código, de coluna/tabela, de posse do analista, rodando como profile job; Glue Data Quality para verificações no job, resultados no nível da linha e Flex/auto scaling; código customizado para qualquer coisa com lógica entre linhas que nenhum tipo de regra cobre.

• Roteie por state, pontue por score: são sinais diferentes (E3).

• Bookmarks dão escopo, crawlers e SchemaMatch detectam drift: nunca o contrário.

• Amostragem é para previews; pontuações precisam da varredura completa.

• 📚 Você sabia? A metade de reprodução do loop de quarentena agora tem um mecanismo no lake: desde 23-04-2026 o Amazon Redshift consegue UPDATE / DELETE / MERGE em tabelas Apache Iceberg particionadas e não particionadas, incluindo Amazon S3 Tables, e desde o Patch 202 da AWS um DELETE de Iceberg numa tabela do Lake Formation precisa da permissão DELETE, UPDATE/MERGE precisam de INSERT + DELETE, e toda instrução DML de Iceberg também precisa de ALTER. Então "corrigir as linhas em quarentena e mesclá-las de volta" é uma operação comum, enquanto um lab que concedeu apenas INSERT agora falha no meio da remediação (documentação de mudanças de comportamento do AWS Redshift, acesso em outubro de 2026).

---

Atualizações de 2026 (em outubro de 2026)

• 📚 Você sabia? Os nomes de serviço em volta deste tópico fossilizam rápido: Kinesis Data Firehose virou Amazon Data Firehose (09-02-2024) mas a lista de escopo do DEA ainda imprime o nome antigo, e Amazon QuickSight virou a família Quick Suite / Quick Sight (09-10-2025). Para qualidade de dados especificamente a regra é mais simples e mais durável: Glue Data Quality está em GA desde 06-06-2023 e ainda é baseado em Deequ: as regras de posicionamento (em voo vs at rest, nível de linha vs agregado) não mudaram, então estude essas em vez das notas de versão (documentação da AWS, acesso em outubro de 2026).

Casos Reais

A AWS publica como essas abstrações ficam em produção. Todos os números abaixo são afirmações de clientes ou da AWS, não auditadas, com a fonte nomeada para você conferir, o ponto examinável é o padrão (qual dimensão de qualidade era a restrição, qual serviço fez o trabalho, qual número se moveu), não o marketing.

Caso A, Nasdaq: atualidade como dimensão de qualidade limitante

"Conseguimos suportar com facilidade o salto de 30 bilhões de registros para 70 bilhões de registros por dia por causa da flexibilidade e da escalabilidade do Amazon S3 e do Amazon Redshift.": Robert Hunt, VP de Engenharia de Software, Nasdaq

Leia o caso da bolsa como uma questão de atualidade disfarçada: o prazo é externo e não negociável, então o gate de qualidade precisa rodar em voo, uma regra RowCount between X and Y mais uma verificação de atualidade/watermark no estágio de pré-escrita, porque não há janela para profilear depois e recarregar.

Caso B, PayU: consistência e atualidade em 40 bancos de dados

"Em 1 mês, reduzimos as consultas em 77 por cento, o que teria sido um exercício de 6 meses no ambiente anterior.": PayU (estudo de caso da AWS, acesso em outubro de 2026)

O padrão examinável: atualidade é uma dimensão mensurável, não um adjetivo. Passar de um lote diário para um feed sub-30-minutos muda o que "atualidade" significa operacionalmente, e cada passo nesse caminho (Glue → S3 → Redshift) precisa de uma verificação de fronteira, porque a aceleração multiplica o número de oportunidades de uma linha ruim chegar a um consumidor.

Caso C, FINRA: volume e completude sob o relógio de um regulador

"A FINRA processa aproximadamente 6 terabytes de dados e 37 bilhões de registros num dia médio … Em dias movimentados, as bolsas de valores podem gerar mais de 75 bilhões de registros.": John Brady, VP de Cyber Security/CISO da FINRA (blog da AWS, acesso em outubro de 2026)

Leia a FINRA como um problema de desenho de regra de volume: um dia movimentado carrega cerca de duas vezes um dia médio, então RowCount = 37.000.000.000 está errado na primeira vez que o mercado se move. A forma examinável é uma faixa, RowCount between <piso de dia calmo> and <teto de dia movimentado>, avaliada em voo na fronteira de pré-escrita e pareada com completude nas colunas das quais a vigilância depende, para que um feed truncado seja capturado antes que a agregação a jusante publique um número com aparência plausível.

Caso D, Hearst: 30 TB de clickstream por dia, com gate por lote

"Não sei como teríamos feito nosso pipeline de dados de clickstream funcionar sem os serviços da Amazon Kinesis. Teria envolvido muitas semanas de engenharia.": Peter Jaffe, Cientista de Dados, Hearst (AWS, acesso em outubro de 2026)

Leia a Hearst como a metade de streaming da Tarefa 3.4.1: com 30 TB chegando continuamente não existe janela de fim de load para profilear depois, então a qualidade vira um gate por lote, ReportBatchItemFailures mais um on-failure destination para isolar registros venenosos (Seção 6.4), checkpoints em vez de job bookmarks, e uma regra de volume/atualidade em cada micro-lote antes de ser gravado. O nome da história também carrega uma armadilha: Kinesis Data Firehose virou Amazon Data Firehose em 09-02-2024 sem mudança de API, e a lista de escopo do DEA-C01 ainda imprime o nome antigo, os dois estão corretos.

• 📚 Você sabia? Nenhum desses estudos de caso da AWS menciona uma ferramenta de qualidade: a AWS publica os resultados e deixa a montagem para você. Isso é desenho deliberado de exame: o DEA-C01 nunca pede que você lembre o ruleset de um cliente, ele pede que você reconheça que um prazo de abertura de mercado implica um gate de pré-escrita, e que quarenta bancos de dados de origem implica verificações de consistência entre datasets (estudos de caso da AWS, acesso em outubro de 2026).
• 📚 Você sabia? Coloque um carimbo de data em todo número de caso que você citar: os 6 TB / 37 bilhões de registros por dia da FINRA vêm de um blog AWS Public Sector de 03-10-2017, enquanto a cifra "mais de 100 bilhões de eventos por dia de 22 bolsas e 1.500 corretoras" pertence ao Consolidated Audit Trail e a um comunicado da AWS de 04-12-2019: dois sistemas diferentes, duas datas diferentes, e a AWS não publicou nenhum total mais novo de dia médio. Uma alternativa de exame que os mistura ("a FINRA processa 100 bilhões de registros por dia") está testando sua disciplina de fonte, não sua aritmética (AWS, acesso em outubro de 2026).

Perguntas de Prática (Practice Questions)

Veredito Comparativo: como este tópico se compara no dia do exame

• Verso outras nuvens: o DEA-C01 testa apenas serviços da AWS: nada pergunta que você compare o Glue Data Quality com um produto de qualidade de um concorrente. Responda com um serviço da AWS, um tipo de regra documentado pela AWS ou um payload da AWS; qualquer alternativa que pivote para um benchmark de terceiros não verificado (incluindo ferramentas ausentes da lista de escopo) está fora de escopo por construção.
• Verso autogerenciado / on-premises: a resposta da AWS é sempre gerenciado e declarativo sobre feito-a-mão e manual: um ruleset em DQDL ou uma regra do DataBrew vence um validador artesanal, porque é versionado, auditável, agendável e alertável. Uma alternativa descrevendo um framework customizado que você precisa manter é o distractor, não o bônus.
• Verso outro serviço da AWS: escolha por posicionamento, não por prestígio, DataBrew para validação sem código via profile e findings, Glue Data Quality para dentro do job e resultados no nível da linha (e avaliações de Catalog para monitoramento at rest), código customizado em Lambda/EMR só para lógica que nenhum tipo de regra cobre. Crawlers detectam mudança de esquema, EventBridge entrega resultados, Step Functions faz gate da promoção, nenhum deles avalia qualidade de linha.
• Verso um processo manual e humano: o prazo de abertura de mercado da Nasdaq e a mudança da PayU de diário para frescor sub-30-minutos (ambos afirmados por clientes, acesso em outubro de 2026) mostram por que o exame prefere um gate automatizado: humanos fazem triagem da quarentena, eles não descobrem a falha. Trate toda porcentagem publicada como "o cliente alcançou", nunca como "a AWS garante".