One tooling project, not one pipeline per environment

Speaker notes

• Two patterns exist: per-environment projects each running their own pipeline copy (simple but duplicates maintenance and security review N times), versus one dedicated tooling project deploying across project boundaries with scoped cross-project IAM.
• PCDE expects the tooling-project pattern by default as codebase and team count grow — it centralizes pipeline security review to one place instead of N duplicated copies.
• Tell the real incident: a team granted roles/editor to a pipeline service account 'temporarily' during a migration, and four months later nobody wanted to revoke it because build steps had quietly started depending on permissions they never should have had — the underlying lesson is defining a pipeline's actual required permission set BEFORE granting access, so there's a baseline to audit against.

Deck map