Service Principal

kALYAN5 — Tue, 30 Dec 2025 10:57:17 GMT

Can two service principal have same name,but unique id's ?

Re: Service Principal

SP_6721 — Tue, 30 Dec 2025 11:30:08 GMT

Hi @kALYAN5 ,

Yes, service principals can share the same display name while still being distinguished by their unique IDs.

Re: Service Principal

kALYAN5 — Tue, 30 Dec 2025 11:45:42 GMT

Hi @SP_6721 ,do you know how and why it behaves like this ?

Re: Service Principal

JAHNAVI — Tue, 30 Dec 2025 15:14:20 GMT

Hi @kALYAN5 ,

2 two service principals can share the same display name, and this works because their IDs differ. The names are not used as primary identifiers. Please find the document for the same : https://docs.databricks.com/aws/en/dev-tools/cli/reference/service-principals-commands#arguments-1

Re: Service Principal

emma_s — Tue, 30 Dec 2025 15:25:40 GMT

Hi @kALYAN5,

Here is an explanation of why service principals share a name but IDs are unique:

Names Are for Human Readability: Organizations use human-friendly names like "automation-batch-job" or "databricks-ci-cd" to make it easy for admins to recognize what a service principal is used for. However, names aren't forced to be unique, since they serve as labels for convenience.
IDs Are Unique, Immutable Identifiers: Each service principal, upon creation, is assigned a globally unique identifier (often a GUID or UUID). This ID is what systems actually use—under the hood—to distinguish and reference principals, regardless of how often names might repeat or change.
Robust Security & Auditability: All authentication, authorization, logging, and auditing relies on the unique service principal ID. This means permissions, activity logs, and system references remain precise, even if several service principals are named identically (for example, if you have both a staging and prod "etl-service-principal").
No Collisions, No Ambiguity: Relying on IDs prevents confusion. If a service principal is deleted and later recreated with the same name, it gets a new ID—and thus won't inadvertently inherit the permissions or identity of the previous instance.

To illusrate the point suppose your team uses Terraform to automate the creation of service principals for Databricks workspaces. You might run:

resource "azuread_service_principal" "sp_a" {
  application_id = azuread_application.this.application_id
  display_name   = "databricks-automation"
}

resource "azuread_service_principal" "sp_b" {
  application_id = azuread_application.that.application_id
  display_name   = "databricks-automation"
}

hcl

Both sp_a and sp_b can have the display name "databricks-automation". However:

Each will have a different application_id (the GUID assigned by Entra ID),
In Databricks, when linked, each will get a distinct Databricks service principal ID as well as the same display name,
All access grants, API usage, and audits in Databricks are tied to this unique ID—not the name—so there’s no ambiguity or risk to security or traceability

A further illustration: If an old service principal named "databricks-automation" is deleted, and a new one with the same name is created later, the new object gets a completely new ID. The system treats it as a separate entity, meaning any access or permissions would need to be explicitly reassigned

Benefits of This Approach

You can safely reuse naming conventions and handle automation at scale.
Permissions and history always remain linked to a unique, immutable ID.
Security is enhanced, and accidental lock-outs or privilege escalation due to name collisions are avoided

This pattern is standardized in platforms like Databricks and Azure AD for the balance of usability (human-friendly names) and system integrity (unique IDs). It means admins and automated tools can operate flexibly, while systems maintain reliable security and audit trails.

topic Re: Service Principal in Data Engineering

Service Principal

Re: Service Principal

Re: Service Principal

Re: Service Principal

Re: Service Principal

Benefits of This Approach