This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Manage identity, access, and governance (20–25%)
--> Secure access to resources by using Microsoft Entra ID
--> Implement and configure identity for applications, including enterprise applications and app registrations
Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.
Overview
Modern cloud applications need identities just as users and devices do. Microsoft Entra ID provides the identity platform that applications use to authenticate, obtain tokens, access APIs, and authorize users or workloads.
For the SC-500 exam, it is important to understand the difference between an application registration, an application object, and an enterprise application/service principal. You should also understand how to configure authentication, permissions, consent, credentials, application roles, and access controls.
A particularly important concept is that App registrations and Enterprise applications are related but serve different purposes.
Microsoft Entra represents an application through an application object and service principal objects. The application object is essentially the application’s definition or blueprint, while the service principal is the application’s local identity in a particular tenant.
1. Application Identity in Microsoft Entra ID
An application that needs to authenticate through Microsoft Entra ID generally needs to be represented in the directory.
Consider an application called Contoso Expense Manager.
The application might need to:
- Authenticate employees.
- Request access to Microsoft Graph.
- Call a custom API.
- Restrict access to members of a particular group.
- Use certificates instead of passwords.
- Support single sign-on.
- Operate across multiple Microsoft Entra tenants.
Microsoft Entra provides the identity infrastructure needed to accomplish these tasks.
The two most important objects to understand are:
| Object | Primary purpose |
|---|---|
| Application object | Defines the application and its identity configuration |
| Service principal | Represents an instance of the application in a specific tenant |
A useful way to remember this is:
Application object = blueprint
Service principal = local instance
An application normally has one application object in its home tenant, while it can have multiple service principals, including one in each tenant where the application is used.
2. What Is an App Registration?
An app registration is the process of registering an application with Microsoft Entra ID.
When you register an application, you tell Microsoft Entra how the application should interact with the identity platform.
An app registration can define:
- Application name
- Supported account types
- Redirect URIs
- Authentication configuration
- API permissions
- Exposed APIs
- Application roles
- Client credentials
- Certificates
- Federated credentials
- Other identity-related configuration
Microsoft Entra uses this information when issuing tokens and determining how the application interacts with users and APIs.
Common application types
Applications can include:
- Web applications
- Single-page applications
- Mobile applications
- Desktop applications
- Web APIs
- Daemon/background applications
The application type affects how authentication and credentials should be configured.
3. Application Object vs. Service Principal
This is one of the most important concepts for the SC-500 exam.
Suppose a software vendor creates a multitenant application called Contoso CRM.
The vendor registers the application in its home tenant.
That registration creates an application object.
When another organization’s tenant uses the application, Microsoft Entra creates a service principal in that customer’s tenant.
Therefore:
APPLICATION
│
▼
Application Object
(Home Tenant)
│
┌─────────┼─────────┐
▼ ▼ ▼
Service Service Service
Principal Principal Principal
Tenant A Tenant B Tenant C
The application object contains the application’s global/default configuration.
The service principal represents the application’s identity within a particular tenant and contains tenant-specific settings such as permissions and assignments.
Exam tip
If a question asks:
“Where does an administrator configure which users in their organization can access an application?”
Think:
Enterprise application / service principal
If it asks:
“Where does the developer configure redirect URIs, exposed APIs, or application credentials?”
Think:
App registration / application object
4. App Registrations vs. Enterprise Applications
The Microsoft Entra admin center provides separate experiences for these objects.
App registrations
App registrations primarily manage the application’s definition.
Typical activities include:
- Registering an application
- Configuring authentication
- Configuring redirect URIs
- Defining API permissions
- Creating client secrets
- Uploading certificates
- Defining application roles
- Exposing APIs
Enterprise applications
Enterprise applications primarily manage the application’s presence and access within a particular tenant.
Typical activities include:
- Assigning users and groups
- Managing application access
- Configuring tenant-specific settings
- Reviewing permissions and consent
- Managing Conditional Access-related controls
- Managing single sign-on configuration for applicable applications
- Viewing sign-in information
Microsoft describes Enterprise Applications as the management experience for service principals.
Simple exam distinction
| If the question says… | Think… |
|---|---|
| Register an application | App registrations |
| Configure redirect URI | App registrations |
| Add client secret | App registrations |
| Add certificate | App registrations |
| Configure API permissions | App registrations |
| Define application roles | App registrations |
| Assign users to an application | Enterprise applications |
| Assign groups to an application | Enterprise applications |
| Control tenant-specific application access | Enterprise applications |
| Review application sign-ins | Enterprise applications |
| Manage a service principal | Enterprise applications |
5. Application IDs and Object IDs
Several identifiers can appear when working with applications.
Two particularly important identifiers are:
Application (client) ID
The Application (client) ID identifies the application.
Applications use this value when communicating with Microsoft Entra ID.
It is commonly referred to as the:
- Client ID
- Application ID
- App ID
Object ID
The Object ID identifies a specific Microsoft Entra directory object.
An application object and a service principal each have their own object ID.
This distinction becomes particularly important when managing applications programmatically.
Exam warning
Do not automatically treat:
Application (client) ID
and
Object ID
as interchangeable.
They identify different things.
6. Configure Supported Account Types
When registering an application, you must determine who can use it.
Common choices include:
Accounts in this organizational directory only
This creates a single-tenant application.
The application is intended for users in the application’s home Microsoft Entra tenant.
This is commonly appropriate for an organization’s internal line-of-business applications.
Accounts in any organizational directory
This creates a multitenant application.
Users from other Microsoft Entra tenants can authenticate to the application, subject to the appropriate configuration and consent.
This is common for SaaS applications intended for customers from multiple organizations.
Accounts in any organizational directory and personal Microsoft accounts
This allows organizational accounts and supported personal Microsoft accounts.
Exam decision
If a question says:
“The application will only be used by employees of the organization.”
A single-tenant configuration is generally the appropriate choice.
If the question says:
“The application is a SaaS application that must be accessed by customers from multiple Microsoft Entra tenants.”
Think:
Multitenant application.
Microsoft Entra’s application model explicitly distinguishes single-tenant and multitenant applications.
7. Configure Authentication
The Authentication configuration of an app registration determines how users or applications authenticate.
Depending on the application type, configuration can include:
- Platform configuration
- Redirect URIs
- Front-channel logout URL
- ID token issuance
- Access token issuance
- Supported authentication flows
The authentication configuration must correspond to the application architecture.
For example:
- A web application has a server component and can protect confidential credentials.
- A single-page application executes in the browser and cannot safely store a client secret.
- A daemon application runs without interactive user involvement.
Understanding the difference between public clients and confidential clients is important.
8. Redirect URIs
A redirect URI, also called a reply URL, specifies where Microsoft Entra ID sends the authentication response after authentication.
For example:
https://app.contoso.com/signin-oidc
The redirect URI is an important security control.
Microsoft Entra validates the redirect URI against the URIs configured for the application.
Why does this matter?
Imagine an attacker attempting to manipulate an authentication response so that it is sent to an unauthorized location.
Restricting valid redirect URIs helps prevent this type of attack.
Exam scenario
If the question says:
“Users successfully authenticate, but the application returns an error because the authentication response cannot be redirected to the application.”
Check:
Redirect URI configuration.
The redirect URI configured by the application must correspond to an allowed URI in the app registration.
9. Client Secrets
A client secret is a credential that a confidential client can use to authenticate itself to Microsoft Entra ID.
Client secrets are commonly used by:
- Web applications
- Daemon applications
- Background services
- Server-side applications
For example:
Application │ │ client ID + client secret ▼Microsoft Entra ID │ ▼Access token
Security concerns
Client secrets are sensitive credentials.
They should:
- Never be embedded in source code.
- Never be committed to a public Git repository.
- Be protected from unauthorized access.
- Be rotated regularly.
- Have appropriate expiration periods.
For Azure-hosted applications, a managed identity may eliminate the need to manage a client secret altogether.
10. Certificates
Certificates provide another way for a confidential application to authenticate.
Instead of sending a shared secret, the application proves possession of the corresponding private key.
For confidential clients, Microsoft recommends certificates over client secrets when practical because certificates provide stronger security characteristics.
A simplified model is:
Application │ │ Certificate/private key ▼Microsoft Entra ID │ │ validates public key ▼Authentication
Exam consideration
If a question asks for a more secure alternative to a client secret for a confidential application, consider:
Certificate-based authentication.
11. Federated Credentials
Federated credentials provide another approach for workload authentication.
They are particularly useful when an external workload already has an identity issued by a trusted identity provider.
Instead of storing a long-lived client secret, the workload can exchange a trusted token for a Microsoft Entra access token.
This can be especially valuable for:
- CI/CD pipelines
- GitHub Actions
- Kubernetes workloads
- Other supported external workload identity scenarios
The major security benefit is reducing the need for long-lived application secrets.
12. Managed Identities
For Azure resources that support managed identities, a managed identity is often preferable to maintaining credentials manually.
For example:
Azure Function │ │ Managed Identity ▼Microsoft Entra ID │ ▼Azure Key Vault
The application does not need to store a client secret.
Microsoft explicitly recommends considering managed identities instead of manually managed service principals when an application runs on an Azure service that supports managed identities and accesses resources that support Microsoft Entra authentication.
Exam tip
If the scenario says:
“An Azure-hosted application needs to access Azure Key Vault without storing credentials.”
Think:
Managed identity.
13. API Permissions
Applications frequently need to access APIs.
For example, an application might need to access:
- Microsoft Graph
- Azure resources
- A custom API
- Another organization’s API
The app registration can specify the APIs and permissions the application requires.
There are two major permission models you should know.
14. Delegated Permissions
Delegated permissions are used when an application accesses a resource on behalf of a signed-in user.
The effective access is generally constrained by both:
- The permissions granted to the application.
- The privileges available to the signed-in user.
For example:
User │ │ signs in ▼Application │ │ delegated permission ▼Microsoft Graph
A typical example would be an application that reads a user’s profile or email while that user is actively using the application.
Exam clue
If the scenario says:
“The application accesses data on behalf of the signed-in user.”
Think:
Delegated permissions.
15. Application Permissions
Application permissions are designed for applications that operate without a signed-in user.
They are commonly used by:
- Background services
- Daemons
- Scheduled jobs
- Automation
- Server-to-server applications
For example:
Background service │ │ Application permission ▼Microsoft Graph
Because application permissions can grant broad access, they require careful governance and frequently require administrator consent.
Microsoft Graph, for example, supports application permissions that allow non-interactive applications to access organizational resources.
Key distinction
| Delegated | Application |
|---|---|
| User is involved | No user required |
| Runs on behalf of user | Runs as the application |
| User context matters | Application identity determines access |
| Interactive scenarios | Daemon/background scenarios |
Exam shortcut
“On behalf of a user” → Delegated
“As the application” → Application
16. Consent
Consent is the mechanism through which permissions requested by an application can be authorized.
There are two major concepts:
User consent
A user may be allowed to consent to certain permissions depending on tenant configuration and the permissions requested.
Admin consent
An administrator can consent to permissions on behalf of users in the organization.
Admin consent is particularly important when the requested permissions are considered privileged or when organizational policy requires administrator approval.
For example:
Application │ │ requests Mail.Read ▼Microsoft Entra │ ▼Admin consent │ ▼Permission granted
Security principle
Do not automatically grant every requested permission.
Instead:
Grant the minimum permissions necessary for the application to perform its function.
This follows the principle of least privilege.
17. Application Roles
Application roles allow an application to implement role-based authorization.
For example, an application could define:
- Reader
- Contributor
- Administrator
A user or group can then be assigned an application role.
Application roles can also be assigned to service principals for application-to-application authorization.
When an appropriate role is assigned, Microsoft Entra can include the role in the token through the roles claim.
Example:
User │ │ assigned "ReportReader" ▼Application │ ▼Token │ └── roles: ReportReader
The application can inspect the claim and determine what functionality the user is authorized to perform.
18. Enterprise Application Access Control
Enterprise applications allow administrators to control who can use an application in their tenant.
For example, an organization may have 10,000 employees but only 200 should have access to a particular application.
The administrator can configure the application so that access is assigned to:
- Specific users
- Groups
This provides centralized control over application access.
Service principals maintain tenant-specific information such as local user and group assignments, permissions, and policies.
19. Assignment Required
An enterprise application can be configured to require users to be explicitly assigned before they can access the application.
This is useful when an organization wants to prevent every user from automatically accessing an application.
For example:
10,000 employees │ ▼Enterprise Application │ │ Assignment required ▼Only assigned users/groups
This is particularly useful for sensitive applications.
Exam scenario
If the requirement is:
“Only users explicitly assigned to the application should be allowed to access it.”
Think:
Require user assignment / configure enterprise application assignments.
20. Single Sign-On
Enterprise applications can support different single sign-on approaches depending on the application.
Common technologies include:
- OpenID Connect
- OAuth
- SAML
- Password-based SSO
- Integrated Windows authentication for appropriate scenarios
SSO allows users to authenticate through Microsoft Entra ID rather than maintaining separate authentication experiences for every application.
For modern applications, OpenID Connect and OAuth 2.0 are particularly important concepts.
21. Conditional Access and Applications
Conditional Access can be used to apply access requirements to applications.
For example, an organization might require:
- MFA
- A compliant device
- A trusted location
- Specific authentication strength
- Risk-based controls
A simplified example:
User │ ▼Enterprise Application │ ▼Conditional Access │ ├── MFA required ├── Device must be compliant └── Risk must be acceptable │ ▼Access granted
This provides an important security layer beyond simply registering the application.
22. Application Ownership and Governance
Applications should have clear ownership.
Application owners may be responsible for:
- Maintaining application configuration
- Managing credentials
- Reviewing permissions
- Monitoring usage
- Removing obsolete applications
- Ensuring permissions remain appropriate
Poor application governance can create significant security risks.
For example, an organization might have:
- Hundreds of unused app registrations
- Expired certificates
- Forgotten client secrets
- Excessive API permissions
- Applications owned by employees who have left the organization
These conditions increase the attack surface.
23. Least Privilege for Applications
Least privilege applies to applications just as it does to users.
An application should receive only the permissions it needs.
For example, suppose an application only needs to read calendar information.
Giving it permission to:
Read and write all mailboxes
would violate least privilege.
A better design is to grant the smallest permission scope necessary.
Security checklist
For every application, ask:
- What resources does it need?
- What permissions does it need?
- Does it need delegated or application permissions?
- Does it really need write access?
- Can a managed identity be used?
- Can a certificate or federated credential replace a secret?
- Who can access the application?
- Is administrator consent required?
- Are the permissions periodically reviewed?
- Is the application still required?
24. Common SC-500 Exam Traps
Trap 1: Confusing app registrations with enterprise applications
Remember:
App registration → application definition
Enterprise application → tenant-specific service principal and access management
Trap 2: Confusing application object and service principal
Remember:
Application object → blueprint
Service principal → instance in a tenant
Trap 3: Using delegated permissions for a daemon
If no user is signed in, delegated permissions generally aren’t the appropriate model.
Think:
Application permissions.
Trap 4: Using a client secret unnecessarily
If an Azure resource supports managed identity and the target resource supports Microsoft Entra authentication, a managed identity can eliminate credential management.
Trap 5: Giving an application excessive permissions
Always consider:
Least privilege.
Trap 6: Confusing Application ID and Object ID
The Application (client) ID identifies the application.
The Object ID identifies a particular Microsoft Entra object.
Trap 7: Assuming every application is single-tenant
SaaS applications frequently require multitenant configuration.
Trap 8: Treating application permissions and Azure RBAC as the same thing
Application API permissions and Azure RBAC are separate authorization mechanisms.
An application can have Microsoft Graph permissions while also having an Azure RBAC role assignment against an Azure resource.
25. SC-500 Quick Reference
| Concept | Remember |
|---|---|
| App registration | Defines/registers an application |
| Application object | Global/home-tenant application definition |
| Service principal | Tenant-specific application identity |
| Enterprise application | Management experience for service principals |
| Application (client) ID | Identifies the application |
| Object ID | Identifies a particular directory object |
| Single tenant | Users from the application’s home tenant |
| Multitenant | Users from multiple Entra tenants |
| Redirect URI | Where authentication response is returned |
| Client secret | Credential for confidential clients |
| Certificate | Stronger credential option for confidential clients |
| Federated credential | Reduces need for long-lived secrets |
| Managed identity | Azure-managed workload identity |
| Delegated permission | Application acts on behalf of a user |
| Application permission | Application acts without a user |
| Admin consent | Administrator authorizes requested permissions |
| Application role | Role-based authorization for an application |
| Enterprise application assignment | Controls which users/groups can access |
| Conditional Access | Applies contextual access requirements |
| Least privilege | Grant only required access |
Practice Exam Questions
Question 1
A company develops an internal web application that will only be used by employees in its Microsoft Entra tenant. The application must authenticate employees using Microsoft Entra ID.
Which configuration should you use?
A. Register the application as single-tenant
B. Register the application as multitenant
C. Create an enterprise application without an app registration
D. Configure the application to accept personal Microsoft accounts
Answer: A
Explanation:
A single-tenant application is appropriate when the application is intended for identities from the organization’s home Microsoft Entra tenant. A multitenant configuration is intended for applications that need to support users from multiple Microsoft Entra tenants.
Question 2
A SaaS vendor has developed an application that must be used by customers in hundreds of different Microsoft Entra tenants. Each customer must be able to configure access for users within its own tenant.
What should the application use?
A. A separate application registration in every customer tenant
B. A multitenant application with a service principal in each customer tenant
C. A single service principal shared across all customer tenants
D. A managed identity created in each customer tenant
Answer: B
Explanation:
A multitenant application has an application object in its home tenant and can have a service principal representing the application in each customer tenant. The customer tenant administrators manage the local service principal through Enterprise Applications.
Question 3
An administrator needs to ensure that only members of the Finance group can access a third-party enterprise application. Where should the administrator primarily configure this tenant-specific access?
A. App registrations > Authentication
B. App registrations > Certificates & secrets
C. Enterprise applications > Users and groups
D. App registrations > Expose an API
Answer: C
Explanation:
Enterprise Applications provides tenant-specific management of the application’s service principal, including user and group assignments. App registrations is primarily concerned with the application’s definition and identity configuration.
Question 4
A background service runs every night without any user interaction. It needs to access Microsoft Graph to perform its assigned task.
Which permission model is most appropriate?
A. Delegated permissions
B. User consent only
C. Application permissions
D. Interactive authentication
Answer: C
Explanation:
Application permissions are intended for applications that operate without a signed-in user. A daemon or background service is a classic example. Delegated permissions are designed for applications acting on behalf of a user.
Question 5
A web application currently uses a client secret to authenticate to Microsoft Entra ID. The security team wants to replace the secret with a stronger credential-based mechanism for the confidential application.
Which option should you consider?
A. Redirect URI
B. Application role
C. Delegated permission
D. Certificate credential
Answer: D
Explanation:
Certificates can be used by confidential clients to authenticate the application and are generally preferred over client secrets when practical. A redirect URI controls where authentication responses are returned; it isn’t an application credential.
Question 6
An Azure-hosted application needs to retrieve secrets from Azure Key Vault. The security team does not want developers to store a client secret in application configuration.
Which solution provides the best approach when the Azure services involved support Microsoft Entra authentication?
A. Use a managed identity
B. Store the client secret in source code
C. Create a second client secret with a longer expiration
D. Store the password in an environment variable
Answer: A
Explanation:
A managed identity allows an Azure resource to authenticate to supported resources without requiring developers to manage an application credential. This reduces the risk associated with storing and rotating secrets.
Question 7
An application needs to read a user’s email while the user is signed in. The application should access the data within the user’s context rather than operating independently.
Which permission model should be used?
A. Application permissions
B. Delegated permissions
C. Managed identity permissions
D. Azure resource locks
Answer: B
Explanation:
Delegated permissions allow an application to access resources on behalf of a signed-in user. Application permissions are intended for scenarios where the application operates without a user.
Question 8
A developer reports that authentication succeeds, but Microsoft Entra ID cannot return the authentication response to the web application.
Which app registration setting should you investigate first?
A. Application roles
B. API permissions
C. Redirect URI
**D. Enterprise application assignment
Answer: C
Explanation:
The redirect URI specifies where Microsoft Entra ID returns the authentication response. The URI used by the application must correspond to an allowed redirect URI configured for the application.
Question 9
A custom API defines three application roles: Reader, Contributor, and Administrator. A user is assigned the Reader role. The API needs to determine which role the user has after authentication.
Which token information should the API inspect?
A. The roles claim
B. The redirect_uri claim
C. The client secret
D. The application object ID
Answer: A
Explanation:
Application roles can be assigned to users, groups, service principals, or supported managed identities. When appropriate, Microsoft Entra ID includes assigned application roles in the token’s roles claim, allowing the application to implement role-based authorization.
Question 10
A security team discovers that an enterprise application is available to every employee, but company policy requires users to be explicitly assigned before they can use it.
What should the administrator configure?
A. Change the application’s client ID
B. Require user assignment and assign the appropriate users or groups
C. Add another redirect URI
D. Change the application from single-tenant to multitenant
Answer: B
Explanation:
Requiring assignment allows the organization to control which users or groups can access an enterprise application. This is particularly useful for sensitive applications where broad access is not appropriate.
Final Exam Takeaways
If you remember only a handful of things from this topic, remember these:
- App registration = application definition.
- Application object = blueprint for the application.
- Service principal = application’s identity/instance in a specific tenant.
- Enterprise Applications = primarily where tenant administrators manage service principals and application access.
- Single-tenant = one organization’s tenant.
- Multitenant = users from multiple Microsoft Entra tenants.
- Delegated permissions = application acts on behalf of a user.
- Application permissions = application acts without a user.
- Managed identity = preferred way to avoid managing credentials for supported Azure workloads.
- Certificates are generally preferable to client secrets for confidential clients when practical.
- Redirect URIs are critical to authentication configuration.
- Application roles enable role-based authorization.
- Enterprise application assignments control who can access an application.
- Admin consent is important for authorizing privileged application permissions.
- Always apply least privilege to application permissions and access.
The biggest SC-500 mental model is:
Register the application → configure how it authenticates → define what it can access → create/manage its service principal → control who can use it → enforce least privilege and Conditional Access.
Go to the SC-500 Exam Prep Hub main page
