01 · The challenge
What happens to the pipeline when its owner leaves?
Personal access tokens and user-owned scheduled jobs are an operational risk. When someone’s permissions change or they leave, the automation tied to them can quietly break.
02 · What I did
What I owned and built.
- Mapped service-principal authentication paths across Azure, Databricks, and source-control workflows.
- Worked through job and pipeline ownership changes, and identified the limits around immutable creator metadata.
- Reviewed Git credential and federated identity (OIDC) options for automated deployment and runtime access.
- Identified secret-rotation and least-privilege considerations for application credentials.
03 · Architecture
How it fits together.
Federated identity (OIDC)
Entra ID app registrations
Team-owned · run-as identity
Least-privilege access
04 · Key decisions
The judgment behind the build.
Why federated identity over stored secrets?
Short-lived tokens issued at run time remove a whole class of leaked or expired secrets.
Why map constraints before migrating?
Some metadata, like a job’s creator, can’t be changed. Knowing that up front avoids breaking production jobs mid-migration.
Why least privilege?
A service identity that can do everything is just a shared password with extra steps. Scoping access limits the blast radius.
05 · Impact
What changed because of the work.
- Sets a path toward automation the team owns rather than any one individual.
- Clarified migration constraints before anyone touched production workloads.
06 · What’s next
Where it goes from here.
Complete the remaining ownership changes, validate unattended runs, and codify credential-rotation procedures.
This case study is a sanitized reconstruction. Organization names, proprietary code, data, and internal schemas are intentionally left out.