Yes, using a single GX configuration to validate data across your medallion architecture is a best practice. Here’s how I would think about it:
Running a Checkpoint
Reading GX configs concurrently is totally safe, so there’s no problem pulling your config from a single bucket into multiple functions simultaneously. Validation results are written as uniquely-keyed files (suite + run name + timestamp + batch), so concurrent runs won’t conflict. Just give each layer a distinct run name (or take the defaults) rather than pinning a fixed run name/time, which would cause overwrites. When you sync results back, upload only the validation results directory rather than the whole gx/ folder, and make sure you’re not using a deleting sync (e.g. gsutil rsync -d).
Updating GX Config
Updating your GX config concurrently isn’t safe. GX has no locking or conflict resolution, so concurrent writes are last-writer-wins. Maintain a single source of truth: keep the config in Git and push updates from CI, or update it manually from one place. Your validation functions should treat the config as read-only. As long as config updates come from a single source, you’re safe.
Building Data Docs
Don’t build Data Docs concurrently, which means: don’t build them from your validation functions. Build when you’re ready to publish or consume the site — could be a fourth function that publishes on a schedule, a job triggered after validations complete, or a manual hook. As long as you have a single Data Docs writer, you’re safe.
Thanks for the question, and I hope that helps!