Automatización de la calidad de datos en pipelines

La calidad de datos es el único tema del Dominio 3 del que otros temas dependen en silencio: un pipeline perfectamente orquestado que mueve filas equivocadas según lo programado es peor que no tener pipeline. La guía del examen DEA-C01 enuncia el requisito como una sola habilidad, «Ejecutar comprobaciones de calidad de los datos mientras se procesan los datos (por ejemplo, comprobar campos vacíos)» (Tarea 3.4.1, guía del examen DEA-C01, consultada en octubre de 2026), y todo lo examinable cuelga de esa palabra mientras. Un perfil semanal de la zona de aterrizaje es un informe; una comprobación que se ejecuta dentro del job, separa las filas y bloquea el siguiente paso es ingeniería.

En esta lección aprenderás a:

• leer las cinco subdeclaraciones de la Tarea 3.4 y defender la regla del «mientras se procesa» frente a los distractores de fin de pipeline;
• mapear las seis dimensiones de calidad a expresiones nativas de AWS y a los escenarios que redacta el examen;
• construir la lista de comprobación de siete chequeos en vuelo, nulos/vacíos, esquema, integridad referencial, duplicados, rango/enum, frescura/watermark, volumen, en DQDL, DataBrew y PySpark;
• operar AWS Glue Data Quality: reglas, analizadores, conjuntos de reglas, los 26 tipos de regla de Studio, resultados por fila, las tres acciones de fallo y los valores por defecto de publicación;
• operar la calidad de AWS Glue DataBrew: anatomía de una regla, conjuntos de reglas que se ejecutan en jobs de perfil, hallazgos, el informe de validación, eventos, programaciones y muestreo;
• cablear patrones de calidad de jobs de Glue: aserciones en el script, tablas de errores, el patrón de prefijo de cuarentena y destinos de mensajes muertos en streaming;
• detectar la deriva de esquema: job bookmarks frente a resolveChoice de DynamicFrame, SchemaChangePolicy del crawler, versiones de tablas del Data Catalog y alertas de deriva;
• bloquear la orquestación con cargas de EventBridge y un Choice de Step Functions sobre state y score, y publicar un panel de calidad;
• decidir cuarentena frente a fallar el job, y por qué la guía del examen prefiere lo en vuelo a la calidad al final;
• estudiar cuatro casos de estudio de clientes de AWS, un recuadro de actualizaciones de octubre de 2026 con fuentes y 14 preguntas estilo examen más cuatro comprobaciones interactivas.

---

1. Tarea 3.4: qué significa de verdad «mientras se procesa»

1.1 Las cinco subdeclaraciones

La trampa está escrita en la primera línea: «perfilar la zona de aterrizaje cada semana» es un informe sobre los datos de ayer, no una comprobación mientras se procesan. Las opciones construidas sobre «cargar todo, y luego perfilar los viernes» están diseñadas para fallar en 3.4.1.

1.2 Calidad al final frente a calidad en vuelo

Ambos tienen su lugar: una evaluación en reposo contra el Data Catalog es legítima para monitorizar una tabla que ya está aterrizando. Pero cuando la línea de habilidad de la pregunta es 3.4.1, la respuesta es una comprobación que se ejecuta durante el procesamiento o que bloquea el siguiente paso.

1.3 Qué herramienta: la matriz de tres vías

La propia tabla de Prescriptive Guidance de AWS es la ayuda más rápida de «qué herramienta» en este examen:

• 📚 ¿Sabías que…? AWS Glue Data Quality está construido sobre Deequ de código abierto, «una biblioteca que Amazon usa internamente para gestionar la calidad de lagos de datos de más de 60 PB» (AWS Big Data Blog, 2023-06-06). Por eso existe amazon-deequ-glue como ejemplo de AWS, pero Deequ como producto, Great Expectations, dbt y Soda no están en la lista de servicios en alcance del DEA-C01, así que una opción construida sobre ellos nunca es la mejor respuesta.

---

2. Las seis dimensiones, mapeadas a escenarios de examen

2.1 Dimensión → expresión de AWS → escenario

El score de calidad de datos es simplemente «el porcentaje de reglas de calidad de los datos que pasan (dan como resultado true) cuando evalúas un conjunto de reglas» (documentación de AWS Glue Data Quality, consultada en octubre de 2026): un número entre 0 y 1.0, no una nota de aprobación por sí mismo.

2.2 Ejemplo resuelto E1: completitud que se esconde detrás de una cadena

Una columna CSV email llega con 1.000.000 de filas. En el archivo en bruto, 3.000 filas llevan un campo vacío. Se escriben dos reglas sobre los mismos datos:

Lectura: las mismas 3.000 filas malas pueden pasar o fallar según el tipo que infiera el lector. Por eso las reglas de completitud se escriben después de la coerción de tipo, en el límite de etapa post-conversión, y por eso «comprobar campos vacíos» en 3.4.1 es una habilidad de colocación tanto como de escritura de reglas.

2.3 Empareja la dimensión con su firma de examen

• 📚 ¿Sabías que…? De las seis dimensiones, la unicidad es la que con más frecuencia se ve «impuesta» por una restricción que no impone: Amazon Redshift afirma que «las restricciones de unicidad, clave primaria y clave externa son solo informativas; Amazon Redshift no las impone cuando poblas una tabla», mientras que «Amazon Redshift sí impone las restricciones de columna NOT NULL» (documentación de Redshift, consultada en octubre de 2026). Así que un INSERT de una clave primaria duplicada tiene éxito, un INSERT de NULL en una columna NOT NULL falla, y ambos comportamientos son examinables como «¿qué DDL evita cargas duplicadas? Ninguna.»

---

3. La lista de comprobación en vuelo: siete chequeos, colocados en los límites de etapa

Cada comprobación de abajo se puede escribir en DQDL (Glue Data Quality), como regla de DataBrew o en PySpark llano: la colocación es lo que rinde la marca de 3.4.1.

3.1 Nulos / vacíos

3.2 Validación de esquema

ColumnExists, ColumnDataType, ColumnLength, ColumnNamesMatchPattern, SchemaMatch. Un job con destino S3 habilita por defecto una regla de «al menos una columna» más detección de anomalías en el número de columnas: un fallo baja el score pero no hace fallar el job (tutorial de Glue, consultado en octubre de 2026). Las reglas de esquema responden a validez; la deriva (Sección 7) responde a qué cambió desde la última vez.

3.3 Integridad referencial

3.4 Duplicados

3.5 Rango / enum

3.6 Frescura / watermark

Los bookmarks dan alcance incremental, no validación: rastrean archivos y filas procesados y no ejecutan ninguna comprobación de esquema (Sección 7). El streaming usa checkpoints, y la ventana por defecto del streaming de Glue es de 100 segundos.

3.7 Volumen

RowCount between X and Y, RowCountMatch, AggregateMatch, CustomSql: «casi cualquier tipo de comprobación de calidad de datos en SQL» (tipos de regla DQDL, consultados en octubre de 2026). Las reglas de volumen son la forma más barata de detectar «la fuente envió el 4 % de las filas de ayer» antes de que los agregados posteriores publiquen silenciosamente un número pequeño.

3.8 Ejemplo resuelto E2: frescura contra un SLA

Un SLA dice que los pedidos no pueden tener más de 24 horas de antigüedad cuando la tabla curada se publica a las 02:00 UTC.

Dos señales, una decisión: la regla DQDL limita las filas, la comparación de watermark limita la carga. Las opciones de examen que ofrecen solo una de las dos suelen estar comprobando si sabes qué fallo detecta cada una.

---

4. AWS Glue Data Quality: DQDL, conjuntos de reglas, resultados

4.1 Tres objetos, dos puntos de entrada

Studio ofrece 26 tipos de regla; una evaluación escribe resultados en S3 (opcionalmente tablas Iceberg/Data Catalog que puedes consultar con Athena), y la detección de anomalías «requiere un mínimo de tres puntos de datos».

4.2 Qué ocurre cuando falla un conjunto de reglas

4.3 Resultados por fila, y las once reglas que no pueden producirlos

rowLevelOutcomes añade cuatro columnas y un estado por fila Passed/Failed. Once tipos de regla no pueden atribuirse a filas, AggregateMatch, ColumnCount, ColumnExists, ColumnNamesMatchPattern, CustomSql, RowCount, RowCountMatch, StandardDeviation, Mean, ColumnCorrelation (tutorial de Glue, consultado en octubre de 2026). Así que «¿qué filas fallaron?» lo responden las reglas con alcance de fila en un job ETL, nunca una evaluación de Catálogo, y nunca una regla agregada.

4.4 Ejemplo resuelto E3: score, y por qué enrutas por state, no por score

Se ejecuta un conjunto de 6 reglas: 4 pasan, 2 fallan.

Una regla omitida no cuenta como pasada: el score es reglas que pasaron sobre las reglas evaluadas, así que nunca asumas que state y score coinciden.

---

5. AWS Glue DataBrew: reglas, conjuntos de reglas, hallazgos

5.1 Anatomía de una regla

Ejemplos de comprobaciones del material propio de 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 Los conjuntos de reglas se ejecutan en jobs de perfil, no en jobs de receta

CreateRuleset está documentado como «Creates a new ruleset that can be used in a profile job to validate the data quality of a dataset» (Crea un nuevo conjunto de reglas que puede usarse en un job de perfil para validar la calidad de datos de un conjunto de datos). Los jobs de receta aplican pasos de receta: esa familia rellena valores faltantes, elimina datos inválidos y elimina duplicados, lo cual es remediación, no validación. La afirmación falsa canónica en este examen es «adjuntar el conjunto de reglas al job de receta».

Cuotas que las preguntas citan literalmente (en octubre de 2026): 100 reglas por conjunto de reglas, 10 conjuntos de reglas por conjunto de datos, 100 conjuntos de reglas por cuenta, 100 pasos por receta, 300 nodos por cuenta.

5.3 Hallazgos, informe de validación y eventos

• Salidas del perfil: Summary, Correlations, Value distribution, Column Summary, más una pestaña Column statistics.
• Resultados de validación: en la pestaña Data quality rules / Data quality de la ejecución del job.
• Ayuda del constructor: una pestaña Dataset preview y una pestaña Recommendations mientras autoras.
• Informe: el job de perfil «produces a validation report in addition to the data profile … at the same location as your profile data» (produce un informe de validación además del perfil de datos … en la misma ubicación que tus datos de perfil).
• Eventos: un evento de EventBridge por ejecución y por conjunto de reglas:

Una sola regla con ese patrón coincide con todas las validaciones fallidas de la cuenta: el payload examinable es detail-type + validationState, no un ARN por conjunto de datos.

5.4 Muestreo (Tarea 3.4.4)

La propia redacción de AWS: «A smaller sample size allows DataBrew to perform transformations faster … A larger sample size more accurately reflects the makeup of the underlying source data.» (Un tamaño de muestra menor permite a DataBrew realizar transformaciones más rápido … Un tamaño de muestra mayor refleja con más precisión la composición de los datos de la fuente subyacente.)

• 📚 ¿Sabías que…? Las programaciones de DataBrew son expresiones cron de seis campos con un suelo duro: «Cron expressions that lead to rates faster than 5 minutes aren't supported» (no se admiten expresiones cron que lleven a tasas más rápidas que 5 minutos), y el día del mes frente al día de la semana es exclusivo (usa ? para uno de ellos). Así que la opción «cada 2 minutos, validar el flujo» es errónea por dos razones independientes: DataBrew no es un procesador de flujos, y su reloj no puede latir tan rápido (documentación de jobs de DataBrew, consultada en octubre de 2026).

5.5 Ejemplo resuelto E4: un conjunto de reglas de RR. HH. que cabe en las cuotas

Cinco reglas sobre una extracción nocturna de RR. HH. de 5.000.000 de filas:

5.6 Desbalance (Tarea 3.4.5): el gemelo de la dimensión de oportunidad

El desbalance no corrompe filas; destruye la oportunidad de la ejecución. Detectalo con las métricas del driver glue.driver.skewness.job y glue.driver.skewness.stage, la UI de Spark o estadísticas de tamaño de partición. Mitigaciones documentadas por AWS: filtrado de claves calientes, agregación incremental, salting, joins de broadcast, repartition/coalesce, ejecución adaptativa de consultas (activada por defecto en Glue 4.0+), particionado de entrada y escalado vertical: la conclusión de la propia AWS es que «there is no single universal solution» (no hay una única solución universal). En el examen, «una tarea tarda 40 minutos mientras las otras 39 terminan en 30 segundos» ⇒ desbalance, y la corrección que nombra la opción es saltear la clave caliente (salt) o hacer broadcast de la tabla pequeña.

6. Patrones de calidad en jobs de Glue: aserciones, tablas de errores, cuarentena

6.1 Aserciones dentro del script: la puerta en vuelo más fuerte

Forma Scala del tutorial de AWS: assert(DQ_Results.filter(_.getField("Outcome").contains("Failed")).count == 0, "…caused the job to fail."). Una aserción convierte un score en un job fallido, que es así como se ve «ejecutar comprobaciones mientras se procesa» cuando la opción dice detenerse antes de que aterricen datos malos.

6.2 Tablas de errores, y el nombre que no existe

6.3 El patrón del prefijo de cuarentena

«AWS Glue Data Quality helps you identify the exact records that caused your quality scores to go down. Easily identify them, quarantine and fix them.» (AWS Glue Data Quality te ayuda a identificar exactamente los registros que hicieron bajar tus scores de calidad. Identifícalos, ponlos en cuarentena y corrígelos con facilidad.): página de producto de AWS Glue Data Quality, consultada en octubre de 2026

La muestra de referencia InsuranceLake de AWS enuncia el contrato con precisión: «The quarantine action removes individual rows that fail the quality check … stores them in a separate quarantine storage location and Data Catalog table» (La acción de cuarentena elimina las filas individuales que no superan la comprobación de calidad … y las almacena en una ubicación de almacenamiento de cuarentena y una tabla del Data Catalog aparte), con reglas aplicadas justo después del mapeo de esquema … antes de que se ejecute ninguna transformación, en las etapas before_transforms / after_transforms / after_sparksql, y la carpeta S3 <table>_quarantine_* y la tabla del catálogo se crean independientemente de que alguna fila se ponga en cuarentena, de modo que la monitorización posterior nunca tiene que adivinar si la ruta existe.

6.4 Streaming: el lado de mensajes muertos de la calidad

Para los consumidores Lambda de Kinesis/Kinesis Data Firehose, la ruta de fallo de calidad es el destino en caso de fallo (on-failure destination), no una alarma de consola: DestinationConfig.OnFailure → SQS, SNS, S3 o Amazon MSK, con BisectBatchOnFunctionError para aislar el registro venenoso, MaximumRetryAttempts 0 to 10.000, MaximumRecordAgeInSeconds 60 to 604.800, y ReportBatchItemFailures devolviendo batchItemFailures para manejo de lotes parciales. Una DLQ a nivel de función es el mecanismo más antiguo; el destino en caso de fallo es el actual, y los dos no son intercambiables en un par de opciones. Los jobs de streaming de Glue usan checkpoints en lugar de bookmarks de job.

6.5 Ejemplo resuelto E5: la división de cuarentena

Aterrizan un millón de filas; el job lleva 6 reglas, 4 de ellas con alcance de fila:

Lee las dos mitades juntas: la ruta de datos puso en cuarentena 4.000 filas y publicó 996.000; la ruta de control publicó state = FAILED y un score de 0,67: mientras que el job aun informaba éxito porque la acción era None. Tres señales distintas, tres respuestas distintas a «¿funcionó?».

---

7. Detección de deriva de esquema: qué ve de verdad una forma cambiada

7.1 Los bookmarks no detectan deriva

Combina el crawler con el evento de EventBridge Glue Data Catalog Table State Change (UpdateTable, CreatePartition, UpdatePartition, DeletePartition más variantes de lote) para alertas de deriva; el comportamiento LOG significa que el catálogo nunca se muta por un crawler cuyo fin es solo alertar.

7.2 resolveChoice: la reparación que cuesta datos

El crawler muestrea solo un prefijo de 2 MB; una fuente con 2 filas de 160.000 con cadenas en una columna numérica se convierte en choice<long,string>:

El orden importa: resolveChoice → apply_mapping → toDF(). Elegir cast sin una regla de completitud convierte un problema de esquema en un problema de datos que nunca ves.

7.3 Ejemplo resuelto E6: la ilusión de las restricciones de Redshift

La misma comprobación escrita como regla DQDL, IsPrimaryKey "id" = «not NULL and unique» (no NULL y única), sí rechaza el duplicado. Las restricciones CHECK y de exclusión no se admiten en Redshift. Así que «la carga falló porque se rechazó un duplicado de clave primaria» es falso, y «añadir una regla de unicidad en el job» es cierto.

---

8. Orquestación: pon una compuerta al pipeline sobre el resultado de calidad

8.1 Los payloads de EventBridge que debes reconocer

La contraparte de DataBrew es source: aws.databrew, detail-type: DataBrew Ruleset Validation Result, detail.validationState: FAILED. La deriva del crawler de Glue llega como Glue Data Catalog Table State Change. Tres servicios, tres cadenas detail-type: el examen comprueba si puedes elegir la correcta.

8.2 Step Functions: el estado Choice es la compuerta

Semántica de Amazon States Language que vale la pena memorizar: Choices[] se evalúan en orden, y «If no Choices evaluate to true … and no Default is provided, the state machine will throw an error» (si ninguna Choice se evalúa como verdadera … y no se proporciona ningún Default, la máquina de estados lanzará un error): por eso AWS recomienda un Default.

8.3 Paneles y métricas

La ruta documentada de QuickSight es EventBridge → Lambda → S3 → crawler → Athena → QuickSight, dando una serie temporal del score en lugar de un veredicto por ejecución. Las métricas de CloudWatch viven bajo dataQualityEvaluationContext (por defecto apagadas) y los registros bajo /aws-glue/data-quality/output y /aws-glue/data-quality/error. Una pregunta que pregunte «¿cómo ven los analistas la tendencia de calidad durante 90 días?» es una pregunta de panel, no de alarma: la respuesta necesita resultados almacenados más una capa de BI, no un tema de SNS.

8.4 El pipeline completo, en una imagen

Cada flecha de arriba es una dependencia: nada aguas abajo puede existir hasta que el artefacto que lo precede se haya producido. Ordena toda la compuerta de la misma manera:

---

9. Cuarentena frente a fallar el job, y el compromiso que el examen realmente pregunta

9.1 La decisión en una línea cada una

• En vuelo le gana a al-final para 3.4.1, pero una evaluación de Catálogo en reposo es correcta para monitorizar una tabla que ya está aterrizando.

• DataBrew para reglas sin código, propiedad del analista, a nivel de columna/tabla, ejecutadas como job de perfil; Glue Data Quality para comprobaciones en el job, resultados por fila y Flex/autoescalado; código a medida para cualquier cosa con lógica entre filas que ningún tipo de regla cubre.

• Enruta por state, puntúa por score: son señales distintas (E3).

• Los bookmarks acotan; los crawlers y SchemaMatch detectan deriva: nunca al revés.

• El muestreo es para vistas previas; los scores necesitan el barrido completo.

• 📚 ¿Sabías que…? La mitad del replay del bucle de cuarentena ahora tiene un mecanismo en el lago: desde 2026-04-23 Amazon Redshift puede ejecutar UPDATE / DELETE / MERGE sobre tablas Apache Iceberg particionadas y no particionadas, incluidas Amazon S3 Tables, y desde el Patch 202 de AWS un DELETE de Iceberg sobre una tabla de Lake Formation necesita el permiso DELETE, UPDATE/MERGE necesitan INSERT + DELETE, y cada sentencia DML de Iceberg necesita además ALTER. Así que «corregir las filas en cuarentena y fusionarlas de vuelta» es una operación ordinaria, mientras que un laboratorio que solo concedió INSERT ahora falla a mitad de la remediación (documentación de cambios de comportamiento de AWS Redshift, consultada en octubre de 2026).

---

Actualizaciones de 2026 (en octubre de 2026)

---

Casos Reales

AWS publica cómo se ven estas abstracciones en producción. Cada cifra de abajo es declarada por el cliente o por AWS y no auditada, con la fuente nombrada para que puedas comprobarla: el punto examinable es el patrón (qué dimensión de calidad era la restricción vinculante, qué servicio hizo el trabajo, qué número se movió), no el marketing.

Caso A, Nasdaq: la oportunidad como dimensión de calidad vinculante

«Pudimos soportar con facilidad el salto de 30.000 millones a 70.000 millones de registros al día gracias a la flexibilidad y escalabilidad de Amazon S3 y Amazon Redshift.»: Robert Hunt, VP de Ingeniería de Software, Nasdaq

Lee el caso de la bolsa como una pregunta de oportunidad disfrazada: el plazo es externo y no negociable, así que la compuerta de calidad debe ejecutarse en vuelo, una regla RowCount between X and Y más una comprobación de frescura/watermark en la etapa de pre-escritura, porque no hay ventana para perfilar después y recargar.

Caso B, PayU: consistencia y frescura en 40 bases de datos

«En 1 mes redujimos las consultas un 77 por ciento, lo que habría sido un ejercicio de 6 meses en el entorno anterior.»: PayU (estudio de caso de AWS, consultado en octubre de 2026)

El patrón examinable: la frescura es una dimensión medible, no un adjetivo. Pasar de un lote diario a un flujo de menos de 30 minutos cambia lo que «oportunidad» significa operativamente, y cada paso de esa ruta (Glue → S3 → Redshift) necesita una comprobación de límite, porque la aceleración multiplica el número de oportunidades de que una fila mala llegue a un consumidor.

Caso C, FINRA: volumen y completitud bajo el reloj de un regulador

«FINRA processes approximately 6 terabytes of data and 37 billion records on an average day … On busy days, the stock markets can generate 75 billion+ records.» (FINRA procesa aproximadamente 6 terabytes de datos y 37.000 millones de registros en un día promedio … En días concurridos, los mercados de valores pueden generar más de 75.000 millones de registros.): John Brady, VP de Ciberseguridad/CISO, FINRA (blog de AWS, consultado en octubre de 2026)

Lee FINRA como un problema de diseño de reglas de volumen: un día concurrido lleva aproximadamente el doble que un día promedio, así que RowCount = 37.000.000.000 es la primera vez que falla cuando el mercado se mueve. La forma examinable es un rango, RowCount between <suelo de día tranquilo> y <techo de día concurrido>, evaluado en vuelo en el límite de pre-escritura y acompañado de completitud sobre las columnas de las que depende la vigilancia, de modo que un feed truncado se detecte antes de que el agregado aguas abajo publique un número plausible.

Caso D, Hearst: 30 TB de clickstream al día, compuerta por lote

«I don't know how we could have made our clickstream data pipeline work without Amazon Kinesis services. It would have involved many weeks of engineering.» (No sé cómo habríamos hecho funcionar nuestro pipeline de datos de clickstream sin los servicios de Amazon Kinesis. Habría supuesto muchas semanas de ingeniería.): Peter Jaffe, Científico de Datos, Hearst (AWS, consultado en octubre de 2026)

Lee Hearst como la mitad de streaming de la Tarea 3.4.1: con 30 TB llegando continuamente no hay ventana de fin de carga para perfilar después, así que la calidad se convierte en una compuerta por lote, ReportBatchItemFailures más un destino en caso de fallo para aislar los registros venenosos (Sección 6.4), checkpoints en lugar de bookmarks de job, y una regla de volumen/frescura en cada micro-lote antes de escribirlo. El nombre de la historia también lleva una trampa: Kinesis Data Firehose se convirtió en Amazon Data Firehose el 2024-02-09 con ningún cambio de API, y la lista de servicios en alcance de DEA-C01 aun imprime el nombre antiguo, ambos son correctos.

• 📚 ¿Sabías que…? Ninguno de estos estudios de caso de AWS menciona ninguna herramienta de calidad: AWS publica los resultados y deja el cableado a ti. Eso es diseño de examen deliberado: DEA-C01 nunca te pide recordar el conjunto de reglas de un cliente, te pide reconocer que un plazo de apertura de mercado implica una compuerta de pre-escritura, y que cuarenta bases de datos de origen implican comprobaciones de consistencia entre conjuntos de datos (estudios de caso de AWS, consultados en octubre de 2026).
• 📚 ¿Sabías que…? Pon fecha a cada cifra de caso que cites: los 6 TB / 37.000 millones de registros al día de FINRA provienen de un blog de Sector Público de AWS del 2017-10-03, mientras que la cifra de «más de 100.000 millones de eventos al día de 22 bolsas y 1.500 brokers-dealers» pertenece al Consolidated Audit Trail y a un comunicado de prensa de AWS del 2019-12-04: dos sistemas distintos, dos fechas distintas, y AWS no ha publicado ningún recuento total de día promedio más reciente. Una opción de examen que los mezcla («FINRA procesa 100.000 millones de registros a diario») está probando tu disciplina de fuentes, no tu aritmética (AWS, consultado en octubre de 2026).

---

Preguntas de Práctica (Practice Questions)

Veredicto comparativo: cómo se compara este tema el día del examen

• Frente a otra nube: DEA-C01 prueba solo servicios de AWS: nada te pide comparar Glue Data Quality con el producto de calidad de un competidor. Responde con un servicio de AWS, un tipo de regla documentado por AWS o un payload de AWS; cualquier opción que gire hacia un benchmark de terceros no verificado (incluidos herramientas ausentes de la lista de servicios en alcance) queda fuera de alcance por construcción.
• Frente a herramientas autogestionadas / on-premises: la respuesta de AWS siempre es gestionado y declarativo sobre personalizado y manual: un conjunto de reglas DQDL o DataBrew le gana a un validador casero, porque está versionado, es auditable, se programa y se puede alertar. Una opción que describe un framework personalizado que debes mantener es el distractor, no la ventaja.
• Frente a otro servicio de AWS: elige por colocación, no por prestigio, DataBrew para validación de perfil sin código y hallazgos, Glue Data Quality para evaluaciones en el job y resultados por fila (y las evaluaciones de Catálogo para monitorización en reposo), código personalizado en Lambda/EMR solo para lógica que ningún tipo de regla cubre. Los crawlers detectan cambios de esquema, EventBridge entrega resultados, Step Functions compuerta la promoción, ninguno de ellos evalúa la calidad de las filas.
• Frente a un proceso manual y humano: el plazo de apertura de mercado de Nasdaq y el salto de PayU de diario a frescura de menos de 30 minutos (ambos declarados por el cliente, consultados en octubre de 2026) muestran por qué el examen prefiere una compuerta automatizada: los humanos triajan la cuarentena, no descubren el fallo. Trata cada porcentaje publicado como «lo logró el cliente», nunca como «lo garantiza AWS».