A county assessor's office has parcel records spread across several legacy source databases with inconsistent table structures. An ML engineer wants to build a unified view of the schemas before designing a feature-engineering pipeline. Which use of AWS Glue best fits this discovery step?
Select an answer to reveal the explanation.
Short Explanation
Think of Glue crawlers like a scout sent ahead into unfamiliar territory — they walk through each legacy database, map what's actually there, and report back a catalog you can review before committing to a plan. Skipping that scouting step and coding straight against known table names is exactly how mismatched legacy schemas bite you later. Crawler-discovered catalog entries turn an unknown, inconsistent landscape into something you can actually inspect and design against.
Full Explanation
Glue crawlers connect to each data source, infer table structure (column names, types, partitions), and register the result in the Glue Data Catalog, giving an engineer a queryable, reviewable inventory of what each legacy system actually contains before any transformation logic gets written — essential when structures are known to be inconsistent across sources. Skipping discovery and coding directly against assumed table names risks building a pipeline on outdated or incomplete assumptions about legacy schemas that were never formally inventoried, which is a common source of silent pipeline breakage when a source table's structure doesn't match what the engineer expected. Claiming a crawler physically merges databases misunderstands what a crawler does — it catalogs metadata about existing sources, it does not move, copy, or restructure the underlying data itself; merging happens later, in an ETL job written against the catalog. Reaching for Glue DataBrew's redaction profile confuses two different Glue capabilities — DataBrew redaction masks sensitive values like PII, it isn't a schema-standardization or discovery tool, and it wouldn't resolve structural inconsistency across legacy tables. Scope note: crawler-inferred types should be spot-checked against source documentation, since automated inference can misjudge ambiguous columns, such as a zip code stored as a number. Operational check: after crawling, manually review a sample of discovered table schemas against known source documentation before writing transformation logic against them.