You know that sinking feeling when your dbt job fails because an environment variable vanished or rotated at the wrong time. Secrets are slippery things, and manual syncing between GCP Secret Manager and dbt feels like juggling chainsaws while debugging SQL. It works until it doesn’t, and then you’re staring down your logs like they owe you an apology.
GCP Secret Manager handles secret storage. dbt handles data transformation. Together, they can build a secure and repeatable pipeline—if identity and access policies are mapped right. The goal is simple: keep credentials out of git, eliminate plaintext configs, and let both tools trust each other without a human in the loop.
The workflow starts with identity. Use service accounts with least privilege, then link them to GCP Secret Manager to fetch runtime secrets. dbt Cloud or your CI/CD runner should assume those identities through IAM, not static keys. This is where most teams trip. They skip the IAM handoff, so dbt never sees the right context to pull secrets securely. Once you fix that trust boundary, your transformations can run automatically with rotated credentials from Secret Manager—no sticky notes, no vault exports.
Secret rotation and audit logs are the prizes of this setup. Pin each dbt environment to a unique service account and enable secret versioning. That way, rotation becomes a scheduled upgrade instead of a crisis. GCP provides transparent access logs so you can trace secret usage down to individual task runs. dbt inherits that audit trail automatically when configured with managed identities.