AWSAWS Certified Generative AI Developer - Professional2026-101.3 Implement data validation and processing pipelines for FM consumption
Separate input profiling from runtime health
Completed by the knowledge check
Learning objective
Validate and profile inputs using AWS Glue Data Quality, SageMaker Data Wrangler, and Lambda metrics.
Core idea
Profiling discovers the shape and defects of a dataset. Validation tests it against an explicit contract. Runtime monitoring measures whether the processing system operates reliably. These activities complement one another, but they answer different questions.
Use SageMaker Data Wrangler to explore and diagnose input data, AWS Glue Data Quality to evaluate repeatable rules, and Lambda metrics to distinguish processing health from application-defined input outcomes. A healthy Lambda invocation can reject every record in a defective delivery. A high-quality dataset can arrive at a function that times out. Neither observation establishes the other.
Data Wrangler is integrated into Amazon SageMaker Canvas; in Amazon SageMaker Studio you open it through Canvas, while Studio Classic hosts the original Data Wrangler interface. Keep the exam’s Data Wrangler terminology while recognizing this product placement.
How it works
Profile before prescribing rules
Data Wrangler’s Data Quality and Insights Report analyzes imported data and helps identify missing values, invalid values, outliers, and other warnings. Its target-column analysis and quick modeling can expose issues such as class imbalance or target leakage. These diagnostics help you investigate the data; they do not prove that a foundation model will produce acceptable answers.
For a foundation-model input pipeline, begin with the fields that determine source identity, content, language, version, and intended use. Inspect unusual lengths, unexpected value patterns, and missing metadata. Use the report to discover candidate rules, then confirm which conditions matter to the downstream task with reviewed examples.
AWS’s report documentation distinguishes using the first 50,000 imported rows from using the entire imported dataset. The entire-dataset report uses a SageMaker Processing job for additional compute. When interpreting a report, record the population analyzed. A sample drawn from the beginning of a sorted delivery might miss a defective source represented later in the file.
Even an entire-dataset profile describes the dataset you imported, not every future delivery. Recreate profiles when input sources or transformation logic change. Keep the dataset identity with the report so an attractive chart cannot be mistaken for evidence about a different release.
Convert findings into repeatable validation
AWS Glue Data Quality uses DQDL rules and supports evaluation through the Data Catalog and through Glue ETL jobs. Catalog evaluation fits ongoing assessment of cataloged tables. ETL evaluation fits a pipeline that must detect and filter defects before it loads the resulting dataset.
Translate a profiling observation into a rule only after deciding what it means. An unusually long text field might contain legitimate legal language, a concatenated file, or parser noise. A ColumnLength check can measure the condition, but the application owner must choose its accepted range. Use IsComplete for mandatory fields, ColumnValues for allowed values or patterns, and ReferentialIntegrity for required reference relationships. Threshold design belongs to 1.3.1.
The Data Catalog entry point can recommend rules as a starting point; rule recommendations are not supported in ETL jobs, which run authored DQDL. Review them against the business contract rather than accepting them as authoritative. A recommendation derived from defective data can describe the defect as normal. Preserve approved rule versions and evaluated outcomes for each release.
For record routing, Glue ETL produces DataQualityRulesPass, DataQualityRulesFail, and DataQualityEvaluationResult columns; see 1.3.1 for the admission contract. Do not assume every aggregate rule has a meaningful row-level interpretation. The DQDL rule-type table documents which rules support row-level results; for example, RowCount concerns the dataset, while IsComplete can identify record-level problems.
Observe Lambda at two levels
Lambda publishes invocation and performance metrics to Amazon CloudWatch. Invocations counts executed function invocations. Errors reports function errors; it does not measure whether an accepted input was factually correct. Duration measures processing time and excludes cold-start time. Throttles counts throttled invocation requests, which do not count as either Invocations or Errors.
Use these metrics to diagnose execution. Increasing duration can identify a transformation bottleneck. Throttles can indicate that the pipeline cannot admit work at the incoming rate. Errors can expose exceptions or timeouts. Read each metric’s definition before combining counters: dividing unrelated populations can produce a misleading rate.
Add application-defined counters for data outcomes. For example, InputAccepted, InputRejected, and MissingSourceId can represent validation decisions. These are your metric names, not built-in Lambda metrics. Lambda’s best-practice guidance recommends emitting custom metrics asynchronously through logs using Embedded Metric Format (EMF), rather than making synchronous metric API calls in the processing path.
Count records separately from invocations when a function handles multiple records. Keep the denominator explicit and avoid counting the same accepted artifact twice on replay. AWS recommends idempotent Lambda code because duplicate events can occur. A validation metric should describe a known unit, not accidentally become a counter of delivery attempts.
Use structured logs for detailed diagnostic context and metrics for trends and alarms. A practical division keeps record identifiers and rule outcomes in logs while reporting bounded categories such as failure reason in custom metrics. Do not put document content into a metric merely to make a dashboard searchable.
Key distinctions and trade-offs
Exploration versus enforcement: A Data Wrangler report explains observed data. A reviewed DQDL ruleset provides repeatable tests. Pipeline routing enforces the resulting decision.
Input failure versus execution failure: A cleanly rejected invalid record is an expected application outcome. An exception during validation is a processing failure. Alerting on the same counter for both prevents useful diagnosis.
Samples versus full populations: Sampling reduces analysis work and can reveal patterns quickly. Full-population analysis better measures rare defects within the imported dataset. Neither removes the need for validation of subsequent deliveries.
Keep evaluation evidence from each layer. A troubleshooting engineer should be able to determine whether a release was assessed against the intended rules, whether records were admitted, and whether execution completed. One overall success indicator cannot answer all three questions.
Architecture / decision scenario
A support summarization pipeline receives weekly ticket exports and handles new ticket events through Lambda. A Data Wrangler report reveals that one export source emits whitespace-only identifiers. The team adds approved Glue rules for identifier completeness and allowed source values, then checks every weekly release before loading it.
The Lambda path applies the corresponding event contract. It returns a controlled rejection for invalid identifiers and emits the custom MissingSourceId counter through EMF. Built-in Errors stays low because the handler works as designed.
Later, a release of the transformation code produces rising Errors and Duration without a corresponding increase in rejected inputs. The team investigates runtime behavior rather than weakening the quality rule. The dashboards make these two incidents distinguishable.
Common exam traps
- Treating low Lambda
Errorsas proof of high input quality. - Treating Data Wrangler’s quick-model result as an FM answer-quality evaluation.
- Assuming a report on sampled data certifies the entire delivery.
- Accepting recommended Glue rules without checking the business contract.
- Calling custom rejection counters built-in Lambda metrics.
- Expecting Glue rule recommendations inside an ETL job.
What to remember
- Profile to discover, validate to test, and route to enforce.
- Data Wrangler is integrated into SageMaker Canvas.
- Glue offers repeatable DQDL evaluation in the Catalog and ETL paths.
- Separate CloudWatch runtime metrics from application-defined quality metrics.
- Keep populations and denominators explicit when comparing outcomes.
Knowledge check
A weekly export is sorted by source system, and the defective source appears near the end of the file. A Data Wrangler Data Quality and Insights Report built on the first 50,000 rows shows no missing identifiers. The team needs to measure rare defects across this whole import. What should it do?
Glue Data Quality recommends a ruleset for a table whose current data already contains whitespace-only identifiers. How should the team use the recommendations?
A Lambda function validates incoming tickets and cleanly rejects those without a source identifier by returning a controlled application response. The built-in Errors metric stays near zero during a bad delivery. How should the team make these rejections visible?
Errors , because every rejection is a function errorInvocations metricErrors counts function errors such as exceptions and timeouts, not inputs the handler rejects as designed. An application-defined counter reports the data outcome with its own record denominator, and Lambda guidance is to emit custom metrics asynchronously through EMF rather than synchronous API calls in the processing path.After a transformation-code release, Lambda Errors and Duration rise, while the custom count of rejected inputs stays flat. What does this pattern indicate?
ErrorsInvocations nor Errors .