Glue data catalog and lake formation governance
Skill vaquarkhan/data-engineering-agent-skills/skills/glue-data-catalog-and-lake-formation-governance
Production-grade Agent Skills for data engineering AI agents: 73 workflows, platform presets, safe backfill/replay, Kafka & Spark reliability, MCP observability, and VS Code/JetBrains installers.
npx -y skills add vaquarkhan/data-engineering-agent-skills --skill glue-data-catalog-and-lake-formation-governanceAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 21 stars21 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Guides agents through AWS-native data catalog and lake governance workflows. Use when designing or reviewing Glue Data Catalog, Lake Formation permissions, governed sharing, metadata quality, and access boundaries for S3, Athena, Redshift, EMR, or Glue pipelines.
SKILL.md
3.1 KB, 566 tokens by cl100k_base, as published. Nobody here has run it
Glue Data Catalog And Lake Formation Governance
Overview
Use this skill when AWS governance is anchored in Glue Data Catalog and Lake Formation, not only in generic metadata tools. It helps agents design catalog structure, access controls, governed sharing, and publish-safe dataset access across lake and warehouse workflows.
When to Use
- designing
Glue Data Catalogdatabase or table organization - defining
Lake Formationpermissions, tag-based access, or sharing boundaries - reviewing governed access for
S3,Athena,Glue,EMR, orRedshift - improving metadata quality for AWS-native data discovery
- aligning platform-native governance with regulated-data and publish controls
Do not treat Lake Formation and the catalog as only platform-admin setup. They are part of delivery design.
Workflow
-
Define the governed asset boundary. Clarify which datasets, tables, zones, and consumers need AWS-native governance.
-
Design the catalog structure. Decide:
- database boundaries
- table naming and ownership
- metadata quality expectations
- partition and location conventions
-
Define the access model. Include:
- principals and roles
- tag-based access where appropriate
- row or column restrictions when required
- cross-account or consumer sharing behavior
-
Align publish behavior with governance. Require:
- certified versus raw asset distinctions
- explicit publish approval or validation gates where needed
- lineage and ownership visibility for shared assets
-
Validate operational behavior. Check how permissions, schema evolution, new partitions, and cross-service access behave under real delivery conditions.
Common Rationalizations
| Rationalization | Reality |
|---|---|
| "IAM alone is enough." | Dataset governance often needs finer-grained sharing, tagging, and lake access patterns than broad service-level IAM. |
| "We can clean up catalog metadata later." | Poor metadata and unclear ownership make governed data hard to discover and trust. |
| "Lake Formation is only for the platform team." | Producers still need to design publish boundaries and access assumptions around it. |
Red Flags
- database and table ownership are unclear
Lake Formationpermissions are bolted on after publish design- catalog metadata does not distinguish trusted and experimental assets
- cross-account sharing or consumer access paths are undocumented
- schema and partition changes are not validated against governance behavior
Verification
- Catalog structure and ownership are intentionally designed
-
Lake Formationpermissions and sharing boundaries are explicit - Metadata quality supports discovery and governance
- Publish and access behavior are aligned
- Operational behavior is validated for schema and access changes
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.