Service principals for applications in Azure - Commands & Configuration

Introduction

When an application needs to access Azure resources securely, it uses a service principal. This is like giving the app its own identity and permissions, so it can work without needing a user to sign in.

When you want an app to access Azure resources automatically without user interaction.

When setting up automated scripts or services that need to manage Azure resources.

When you want to control and limit what an app can do in your Azure environment.

When integrating third-party apps that need permission to your Azure resources.

When building CI/CD pipelines that deploy or manage Azure infrastructure.

Commands

This command creates a service principal named 'my-app-sp' with Contributor role on the specified subscription. It gives the app permissions to manage resources in that subscription.

Terminal

az ad sp create-for-rbac --name my-app-sp --role Contributor --scopes /subscriptions/00000000-0000-0000-0000-000000000000

Expected Output

{

  "appId": "11111111-1111-1111-1111-111111111111",

  "displayName": "my-app-sp",

  "name": "http://my-app-sp",

  "password": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",

  "tenant": "22222222-2222-2222-2222-222222222222"

}

→

--name - Sets the name of the service principal.

→

--role - Assigns a role to the service principal for permissions.

→

--scopes - Defines the scope where the role applies, like a subscription.

This command lists the service principal named 'my-app-sp' to verify it was created successfully.

Terminal

az ad sp list --display-name my-app-sp

Expected Output

[{

  "appId": "11111111-1111-1111-1111-111111111111",

  "displayName": "my-app-sp",

  "objectId": "33333333-3333-3333-3333-333333333333",

  "servicePrincipalType": "Application"

}]

→

--display-name - Filters the list by the service principal's name.

This command deletes the service principal by its appId when it is no longer needed, cleaning up permissions.

Terminal

az ad sp delete --id 11111111-1111-1111-1111-111111111111

Expected Output

No output (command runs silently)

→

--id - Specifies the objectId of the service principal to delete.

Key Concept

If you remember nothing else from this pattern, remember: a service principal is a secure identity for an app to access Azure resources without a user.

Common Mistakes

Not specifying the correct scope when creating the service principal.

The service principal will not have permissions where needed, causing failures.

Always set the --scopes flag to the exact subscription or resource group the app needs access to.

Sharing the service principal password publicly or in unsecured places.

This exposes your Azure resources to unauthorized access.

Keep the password secret and use secure storage like Azure Key Vault.

Not deleting unused service principals.

Unused principals increase security risks and clutter your environment.

Regularly review and delete service principals that are no longer needed.

Summary

Create a service principal with az ad sp create-for-rbac to give an app permissions.

Verify the service principal exists with az ad sp list using its name.

Delete the service principal with az ad sp delete when it is no longer needed.

Practice

1. What is the main purpose of a service principal in Azure?

easy

A. To allow applications to access Azure resources securely without user accounts

B. To create user accounts for Azure administrators

C. To monitor network traffic in Azure

D. To store data in Azure Blob Storage

Solution

1. Step 1: Understand service principal role

   A service principal acts like an identity for an application to access Azure resources securely.

2. Step 2: Compare options

   Only To allow applications to access Azure resources securely without user accounts describes this purpose correctly; others describe unrelated Azure features.

3. Final Answer:

   To allow applications to access Azure resources securely without user accounts -> Option A

4. Quick Check:

   Service principal = app identity for secure access [OK]

Hint: Service principals are app identities, not user accounts [OK]

Common Mistakes:

• Confusing service principals with user accounts
• Thinking service principals manage storage or network
• Assuming service principals are for monitoring

2. Which Azure CLI command correctly creates a service principal with contributor role for a specific resource group?

easy

A. az ad sp create --name MyApp --role reader --scopes /subscriptions/123/resourceGroups/MyGroup

B. az sp create --name MyApp --role contributor --scope /resourceGroups/MyGroup

C. az ad create-sp --name MyApp --role admin --scope /subscriptions/123/resourceGroups/MyGroup

D. az ad sp create-for-rbac --name MyApp --role contributor --scopes /subscriptions/123/resourceGroups/MyGroup

Solution

1. Step 1: Identify correct Azure CLI syntax

   The correct command to create a service principal is 'az ad sp create-for-rbac' with parameters for name, role, and scopes.

2. Step 2: Validate options

   az ad sp create-for-rbac --name MyApp --role contributor --scopes /subscriptions/123/resourceGroups/MyGroup uses correct command and parameters. Others have wrong commands, roles, or parameter names.

3. Final Answer:

   az ad sp create-for-rbac --name MyApp --role contributor --scopes /subscriptions/123/resourceGroups/MyGroup -> Option D

4. Quick Check:

   Correct CLI command = az ad sp create-for-rbac --name MyApp --role contributor --scopes /subscriptions/123/resourceGroups/MyGroup [OK]

Hint: Use 'az ad sp create-for-rbac' with correct role and scope [OK]

Common Mistakes:

• Using wrong command like 'az sp create'
• Misspelling 'scopes' or 'scope'
• Assigning incorrect roles like 'admin' or 'reader'

3. Given this Azure CLI output after creating a service principal:

{
  "appId": "abcd-1234",
  "displayName": "MyApp",
  "password": "secret",
  "tenant": "tenant-5678"
}

What does the appId represent?

medium

A. The password to access the service principal

B. The unique identifier for the service principal application

C. The tenant ID where the service principal is created

D. The display name of the Azure subscription

Solution

1. Step 1: Understand Azure CLI output fields

   The 'appId' is the unique ID for the service principal's application identity.

2. Step 2: Match fields to meanings

   'password' is the secret, 'tenant' is the Azure tenant ID, 'displayName' is the name shown.

3. Final Answer:

   The unique identifier for the service principal application -> Option B

4. Quick Check:

   appId = service principal unique ID [OK]

Hint: appId is the app's unique ID, not password or tenant [OK]

Common Mistakes:

• Confusing appId with password or tenant
• Thinking appId is subscription name
• Mixing displayName with appId

4. You run this command to create a service principal:

az ad sp create-for-rbac --name MyApp --role contributor --scopes /subscriptions/123/resourceGroups/MyGroup

But you get an error: Insufficient privileges to complete the operation.
What is the most likely cause?

medium

A. The role 'contributor' does not exist

B. The resource group name is incorrect

C. Your user account lacks permission to create service principals

D. The Azure CLI is not installed

Solution

1. Step 1: Analyze error message

   'Insufficient privileges' means the user does not have rights to create service principals.

2. Step 2: Check other options

   Resource group name errors or missing CLI cause different errors; 'contributor' is a valid role.

3. Final Answer:

   Your user account lacks permission to create service principals -> Option C

4. Quick Check:

   Permission error = user lacks rights [OK]

Hint: Check user permissions if 'Insufficient privileges' error appears [OK]

Common Mistakes:

• Assuming resource group name typo causes privilege error
• Thinking role name is invalid
• Ignoring user permission requirements

5. You want to create a service principal that can only read data from a storage account named mystorage in resource group MyGroup. Which Azure CLI command correctly limits permissions to just that storage account?

hard

A. az ad sp create-for-rbac --name MyApp --role Storage Blob Data Reader --scopes /subscriptions/123/resourceGroups/MyGroup/providers/Microsoft.Storage/storageAccounts/mystorage

B. az ad sp create-for-rbac --name MyApp --role contributor --scopes /subscriptions/123/resourceGroups/MyGroup

C. az ad sp create-for-rbac --name MyApp --role reader --scopes /subscriptions/123

D. az ad sp create-for-rbac --name MyApp --role Storage Account Contributor --scopes /subscriptions/123/resourceGroups/MyGroup/providers/Microsoft.Storage/storageAccounts/mystorage

Solution

1. Step 1: Identify required permission and scope

   To allow only read access to blobs, use role 'Storage Blob Data Reader' scoped to the specific storage account.

2. Step 2: Evaluate options

   az ad sp create-for-rbac --name MyApp --role Storage Blob Data Reader --scopes /subscriptions/123/resourceGroups/MyGroup/providers/Microsoft.Storage/storageAccounts/mystorage uses correct role and precise scope. az ad sp create-for-rbac --name MyApp --role contributor --scopes /subscriptions/123/resourceGroups/MyGroup is too broad (contributor on resource group). az ad sp create-for-rbac --name MyApp --role reader --scopes /subscriptions/123 scopes too wide with reader role. az ad sp create-for-rbac --name MyApp --role Storage Account Contributor --scopes /subscriptions/123/resourceGroups/MyGroup/providers/Microsoft.Storage/storageAccounts/mystorage grants more permissions than needed.

3. Final Answer:

   az ad sp create-for-rbac --name MyApp --role Storage Blob Data Reader --scopes /subscriptions/123/resourceGroups/MyGroup/providers/Microsoft.Storage/storageAccounts/mystorage -> Option A

4. Quick Check:

   Least privilege with correct role and scope = az ad sp create-for-rbac --name MyApp --role Storage Blob Data Reader --scopes /subscriptions/123/resourceGroups/MyGroup/providers/Microsoft.Storage/storageAccounts/mystorage [OK]

Hint: Use least privilege role scoped to exact resource [OK]

Common Mistakes:

• Using broad roles like contributor unnecessarily
• Scoping to resource group instead of specific storage account
• Choosing roles that allow write or delete permissions