I would not approve the permission simply because the application requires administrative access.

I would first determine:

1. What does the application actually need to do?
2. Which API or resource does it need to access?
3. Which specific permissions are required?
4. Can a narrower permission satisfy the requirement?
5. Does the application need delegated or application permissions?
6. What data or operations will the application perform?
7. How is the application authenticating?
8. Who owns and maintains the application?

For example, if an application needs to read a limited set of Microsoft Graph data, granting a directory-wide administrative capability would be excessive.

The goal is to map:

Business Requirement
        ↓
Technical Operation
        ↓
Required API
        ↓
Minimum Required Permission

The application should receive the specific permission required for its function rather than a broad administrative role.

Q46. What is the difference between an application’s Application Object ID and its Service Principal Object ID?

These are different identifiers representing different directory objects.

Application Object ID

Identifies the application object in its home tenant.

Service Principal Object ID

Identifies the service principal object representing that application in a particular tenant.

For a multitenant application:

Application Object
        ↓
Application ID
        ↓
Service Principal in Tenant A
        ↓
Service Principal in Tenant B
        ↓
Service Principal in Tenant C

The Application ID can remain the same while each tenant has a different service principal object.

This distinction is important when troubleshooting permissions and configuring resource access.

Q47. How would you identify which service principal is actually making an API request?

I would correlate the application request with Microsoft Entra and application logs.

I would look for identifiers such as:

• Application/client ID
• Service principal information
• Tenant ID
• Request/correlation ID
• Token claims
• API/resource being accessed
• Sign-in or service-principal activity

For a token-based request, I would inspect the token claims where appropriate.

The objective is to establish:

Request
   ↓
Token
   ↓
Application Identity
   ↓
Service Principal
   ↓
Target API

I would not identify an application solely by its display name because display names are not reliable unique identifiers.

Q48. How would you investigate an unknown or suspicious service principal in a tenant?

I would first identify exactly what the service principal represents.

I would investigate:

• Display name
• Application ID
• Service principal object ID
• Publisher information where available
• Application registration
• Creation date
• Credentials
• API permissions
• Resource permissions
• Recent authentication activity
• Owners
• Whether the application is actually used

I would then determine whether it is:

• A Microsoft application
• A third-party application
• An internally developed application
• A workload identity
• A managed identity
• An application that is no longer required

The investigation should be evidence-based rather than deleting the service principal immediately.

Q49. What is the difference between an application object and a service principal when troubleshooting permissions?

The application object describes the application itself, while the service principal represents that application within a tenant.

For example:

Application Object
      ↓
Defines application
      ↓
Service Principal
      ↓
Tenant-specific identity
      ↓
Resource/API permissions

Therefore, when an application works in its home tenant but fails in another tenant, I would examine the service principal in the affected tenant rather than assuming the application object itself is the problem.

Q50. Why can the same application have different access in different Microsoft Entra tenants?

Because the application’s definition and its tenant-specific service principal are separate concepts.

A multitenant application can have:

One Application Object
        ↓
Service Principal — Tenant A
Service Principal — Tenant B
Service Principal — Tenant C

Each consuming tenant controls how that application is authorized within its own directory.

Therefore, differences in:

• Consent
• API permissions
• Application access
• Service-principal configuration
• Tenant policies
• Application configuration

can result in different behavior between tenants.

Managed Identities

Q51. What is a managed identity in Microsoft Entra ID?

A managed identity provides an Azure resource or workload with an identity in Microsoft Entra ID without requiring administrators to manage a traditional client secret or certificate for that identity.

For example:

Azure VM
   ↓
Managed Identity
   ↓
Microsoft Entra ID
   ↓
Access Token
   ↓
Azure Resource

The Azure platform manages the identity’s credentials.

This is particularly useful for Azure workloads that need to authenticate to supported resources.

Q52. What is the difference between system-assigned and user-assigned managed identities?

System-assigned managed identity

• Created as part of an Azure resource.
• Tied to that resource’s lifecycle.
• Deleted when the associated resource is deleted.

User-assigned managed identity

• Created as a separate Azure resource.
• Has its own lifecycle.
• Can be assigned to multiple supported resources.

Simplified:

System-assigned:

Azure VM
   ↓
Identity


User-assigned:

User-assigned Identity
       ↓
   +---+---+
   ↓       ↓
 VM 1     VM 2

Q53. When would you choose a user-assigned managed identity over a system-assigned managed identity?

I would consider a user-assigned identity when the identity needs to have an independent lifecycle or be reused by multiple supported Azure resources.

For example:

Application Service 1 ──┐
                        ├── User-assigned Identity
Application Service 2 ──┘

This can simplify identity management when multiple workloads need the same application identity.

A system-assigned identity is often simpler when the identity should belong exclusively to one resource.

Q54. What is the relationship between a managed identity and a service principal?

A managed identity is represented in Microsoft Entra ID by a service principal.

Conceptually:

Azure Resource
      ↓
Managed Identity
      ↓
Service Principal
      ↓
Microsoft Entra ID

The important distinction is that administrators do not manage a normal application registration and client secret for the managed identity in the same way as a traditional application.

Q55. Why doesn’t a managed identity have an application object like a normal app registration?

A managed identity is designed to provide an Azure resource with an identity without requiring the administrator to create and manage a conventional app registration and its credentials.

The identity is represented by a service principal associated with the managed identity.

Therefore:

Normal Application
Application Object
        ↓
Service Principal


Managed Identity
Azure Resource
        ↓
Service Principal

This is one of the key differences between traditional application identity and managed identity.

Q56. An Azure VM has a managed identity but cannot access Key Vault. How would you troubleshoot it?

I would separate identity availability from authorization.

I would check:

1. Is the managed identity enabled on the VM?
2. Is the correct identity being used?
3. Can the workload obtain a token?
4. Is the token intended for the Key Vault resource?
5. Does the identity have the required Key Vault permissions?
6. Is the correct RBAC role or Key Vault permission model configured?
7. Are there Key Vault network restrictions?
8. Are there firewall/private endpoint/DNS issues?
9. What error is returned by the application?

The troubleshooting model is:

VM
 ↓
Managed Identity
 ↓
Token Acquisition
 ↓
Key Vault Authorization
 ↓
Network Access
 ↓
Secret/Key/Certificate

Having a managed identity does not automatically grant access to Key Vault.

Q57. Can a managed identity access Microsoft Graph?

Yes, where the workload and Microsoft Entra configuration support the required authentication and authorization model.

However, simply enabling a managed identity does not automatically grant Microsoft Graph permissions.

The identity must have the appropriate permissions for the operation being performed.

Therefore:

Managed Identity
       ↓
Token
       ↓
Microsoft Graph
       ↓
Required Permission

If the token is obtained successfully but Graph returns an authorization error, I would investigate the permissions assigned to the application’s service principal and the API request being made.

Workload Identity Federation

Q58. What is a Federated Identity Credential (FIC)?

A Federated Identity Credential establishes a trust relationship that allows an external workload identity provider to be trusted by Microsoft Entra ID.

Instead of storing a long-lived client secret, the workload presents an external OIDC token.

Simplified:

External Workload
      ↓
OIDC Token
      ↓
Federated Identity Credential
      ↓
Microsoft Entra ID
      ↓
Microsoft Entra Access Token

The external token is evaluated against the federation configuration.

Q59. What are the issuer, subject and audience in a Federated Identity Credential?

These values help Microsoft Entra ID determine whether the external token is from the expected issuer and represents the expected workload.

Issuer

Identifies the external identity provider.

Subject

Identifies the specific workload identity according to the external provider.

Audience

Identifies the intended token audience.

Conceptually:

External Token
 ├── Issuer
 ├── Subject
 └── Audience
        ↓
Compare with FIC configuration
        ↓
Trust decision

A mismatch in any of the required values can cause federation authentication to fail.

Q60. How does Microsoft Entra ID validate an external OIDC token during workload identity federation?

The workload first obtains an OIDC token from the trusted external identity provider.

Microsoft Entra ID then evaluates the token against the configured federated identity credential.

Conceptually:

External IdP
     ↓
OIDC Token
     ↓
Microsoft Entra
     ↓
Validate issuer/subject/audience
     ↓
Trusted workload?
     ↓
Issue Entra access token

The external token does not simply become the Azure access token. Microsoft Entra ID performs the federation exchange and issues an appropriate Entra token.

Q61. How would you troubleshoot a workload identity federation failure?

I would check:

1. External identity provider.
2. OIDC token generation.
3. Issuer.
4. Subject.
5. Audience.
6. Federated Identity Credential configuration.
7. Application/client ID.
8. Tenant ID.
9. Token request.
10. Target resource/API.
11. Application logs.
12. Microsoft Entra sign-in or authentication logs where applicable.

The most common troubleshooting approach is to compare the actual token claims with the configured federation values.

Actual Token
     ↓
Issuer
Subject
Audience
     ↓
Compare
     ↓
Federated Credential

Q62. How would you configure workload identity federation for a Kubernetes workload?

The exact implementation depends on the Kubernetes platform and identity integration being used.

At a high level, I would:

1. Establish the Kubernetes workload identity/OIDC issuer.
2. Create or identify the Microsoft Entra application or supported user-assigned managed identity.
3. Configure a Federated Identity Credential.
4. Match the expected issuer.
5. Match the workload subject.
6. Configure the expected audience.
7. Grant the required permissions to the identity.
8. Configure the Kubernetes workload to use the identity.
9. Test token acquisition and resource access.

The important design principle is:

Kubernetes Workload
        ↓
OIDC Identity
        ↓
Federated Credential
        ↓
Microsoft Entra
        ↓
Target Resource

No long-lived client secret is required for that federation path.

Q63. What security considerations are important when using workload identity federation?

I would ensure that the federation trust is as specific as practical.

Important considerations include:

• Restrict the issuer to the expected identity provider.
• Use a narrowly defined subject.
• Use the correct audience.
• Avoid unnecessarily broad workload matching.
• Grant only required resource/API permissions.
• Protect the external workload environment.
• Monitor authentication activity.
• Remove obsolete federation configurations.

A weak federation configuration can allow an unintended workload to obtain access.

Q64. Can workload identity federation eliminate all application credentials?

No.

It can eliminate the need for a long-lived client secret or certificate for a supported federation scenario, but the workload still requires an identity and authorization configuration.

For example:

Without Federation:

Workload
 ↓
Client Secret
 ↓
Microsoft Entra


With Federation:

Workload
 ↓
OIDC Identity
 ↓
Federated Credential
 ↓
Microsoft Entra

The second model removes the long-lived secret from that authentication path, but permissions and trust configuration are still required.

Application Authorization and Token Troubleshooting

Q65. What is the difference between Microsoft Graph API permissions and access to an Azure resource?

They represent different authorization models.

For example:

Microsoft Graph
      ↓
Graph API permissions


Azure Storage
      ↓
Azure resource authorization

An application having Microsoft Graph permissions does not automatically give it access to Azure Storage.

Likewise, permission to an Azure resource does not automatically grant Microsoft Graph access.

I would always identify the actual target resource/API first.

Q66. An application successfully obtains an access token but receives HTTP 403 from an API. What would you investigate?

A successful token request proves that authentication/token issuance succeeded, but it does not prove that the application is authorized for the requested operation.

I would check:

1. Token audience (aud).
2. Required scopes or roles.
3. Application versus delegated permission model.
4. Tenant.
5. Target API.
6. Resource-specific authorization.
7. Application roles where applicable.
8. Conditional access or security controls where applicable.
9. Application-side authorization.
10. API logs.

The distinction is:

Token obtained
     ↓
Authentication succeeded
     ↓
API request
     ↓
Authorization failed
     ↓
HTTP 403

Q67. How do you determine whether an application problem is authentication or authorization related?

I would separate the troubleshooting process.

Authentication problem

The application cannot successfully establish its identity or obtain an appropriate token.

Examples:

• Invalid client credential
• Invalid client
• Invalid authorization code
• Certificate problem
• Token acquisition failure

Authorization problem

The application obtains a token but does not have the required permission.

Examples:

• Missing scope
• Missing application role
• Incorrect audience
• Insufficient API permission
• Resource-specific authorization failure

Simplified:

Can the application obtain a valid token?
        |
     No ───→ Authentication problem
        |
       Yes
        ↓
Can the API authorize the requested operation?
        |
     No ───→ Authorization problem
        |
       Yes
        ↓
      Success

Q68. An application successfully obtains a token, but the API rejects it. What would you check?

I would inspect the token and request context.

Important checks include:

• aud — intended API
• iss — issuer
• tid — tenant
• scp — delegated scopes where applicable
• roles — application roles where applicable
• Token expiration
• Client/application identity
• API endpoint
• API-side authorization rules

For example, an application could obtain a valid Microsoft Entra token intended for Microsoft Graph and incorrectly present it to a different API.

The token can be valid while still being unusable for that API.

Q69. An application receives invalid_client. What are the likely causes?

Possible causes include:

• Incorrect client ID
• Incorrect client secret
• Expired client secret
• Incorrect certificate
• Invalid client assertion
• Incorrect tenant endpoint
• Incorrect client authentication method
• Credential not configured as expected

I would verify the exact authentication flow and compare the application’s configuration with the Microsoft Entra application registration.

I would avoid immediately generating another credential without identifying the original failure.

Q70. An application receives invalid_grant. How would you investigate it?

The exact cause depends on the authentication flow.

I would check:

• Authorization code validity
• Code expiration
• Redirect URI
• Client configuration
• Tenant
• Requested scopes
• Certificate/client assertion where applicable
• User/session context where applicable
• Whether the grant has already been used
• Application logs
• Microsoft Entra error details

I would first identify which OAuth/OIDC flow is being used, because invalid_grant can have different causes depending on the flow.

Q71. An application works in one tenant but fails in another. What would you check?

I would compare the two tenant configurations.

Important areas include:

• Supported account types
• Service principal existence
• Consent
• API permissions
• Application configuration
• Redirect URIs
• Tenant-specific policies
• User assignment where applicable
• Application roles
• SSO configuration
• Provisioning configuration
• Tenant-specific application settings

I would create a comparison:

Working Tenant
      ↕
Compare
      ↕
Failing Tenant

The difference is often more useful than troubleshooting the application in isolation.

Q72. An Enterprise Application exists, but users receive Access Denied. How would you troubleshoot it?

I would first determine whether the user is successfully authenticating.

Then check:

1. User assignment.
2. Group assignment.
3. Application role assignment.
4. Enterprise Application configuration.
5. Conditional Access result.
6. SSO claims where applicable.
7. Application-side authorization.
8. Provisioning status if the application requires an account.

The key distinction is:

Enterprise Application exists
        ≠
User is automatically authorized

The service principal existing in the tenant does not by itself guarantee user access.

Q73. A certificate-based application suddenly stops authenticating. What would you investigate?

I would check:

• Certificate expiration
• Certificate thumbprint/identifier
• Correct certificate configured in the application
• Private-key availability
• Private-key permissions
• Application registration credential
• Certificate rollover
• Server certificate store
• Application logs
• Microsoft Entra authentication errors
• Recent certificate changes

I would particularly verify that the certificate registered in Microsoft Entra corresponds to the certificate/private key actually being used by the application.

Advanced Application and Enterprise Application Scenarios

Q74. What is the difference between authentication, authorization, SSO and provisioning?

These are related but different functions.

Authentication

Determines who or what the identity is.

Authorization

Determines what that identity is allowed to do.

SSO

Allows an authenticated identity to access an application without separately entering credentials for that application, according to the configured protocol and trust.

Provisioning

Creates, updates or disables the corresponding account in the target application.

Simplified:

Authentication
      ↓
Who are you?

Authorization
      ↓
What are you allowed to do?

SSO
      ↓
How do you access the application?

Provisioning
      ↓
Does the application have your account?

Q75. A SAML application authenticates users successfully, but the application displays an error immediately afterward. How would you isolate the problem?

I would determine whether Microsoft Entra successfully issued the SAML response.

Then inspect:

• SAML response
• NameID
• Required claims
• Attribute mappings
• Audience
• Recipient
• Destination
• Assertion validity
• Application-side logs
• Application user mapping

The troubleshooting flow would be:

User Authentication
       ↓
SAML Response
       ↓
Application Receives Assertion
       ↓
Claim/User Mapping
       ↓
Application Authorization

If authentication succeeds but the application rejects the assertion or cannot map the user, the issue may be on the SAML/application side rather than the user’s Microsoft Entra password or MFA.

Q76. A user is assigned to an Enterprise Application but still cannot access it. What would you investigate?

I would verify:

1. Assignment is actually present.
2. The assignment is direct or through the expected group.
3. The user is a member of the required group.
4. The application requires assignment.
5. Application role assignment is correct.
6. Conditional Access is not blocking access.
7. SSO configuration is correct.
8. Provisioning has created the required target account.
9. The target application recognizes the user’s identifier.

Assignment alone does not guarantee that the downstream application has correctly provisioned or authorized the user.

Q77. How would you troubleshoot SCIM provisioning when users are created but their attributes are incorrect?

I would inspect the provisioning configuration rather than immediately recreating the users.

I would check:

• Source attribute
• Target attribute
• Attribute mapping
• Transformation rules
• Matching attributes
• Scope
• Provisioning logs
• Target application schema
• Target application behavior

For example:

Microsoft Entra Attribute
        ↓
Attribute Mapping
        ↓
SCIM Request
        ↓
Target Application Attribute

I would identify exactly where the incorrect value was introduced.

Q78. How would you design application access using groups rather than assigning hundreds of users individually?

For an application that supports group-based assignment, I would use appropriately managed groups and assign the group to the application.

Conceptually:

Users
  ↓
Group
  ↓
Enterprise Application
  ↓
Application Role

This simplifies application assignment and reduces administrative effort.

However, the actual design should account for:

• Group membership model
• Application roles
• Provisioning
• Licensing requirements where applicable
• Nested-group behavior supported by the application
• Access requirements

The goal is to avoid hundreds of individual assignments while keeping application access predictable.

Application Proxy

Q79. What is Microsoft Entra Application Proxy?

Microsoft Entra Application Proxy provides published access to supported on-premises web applications through Microsoft Entra ID.

A simplified architecture is:

Internet User
      ↓
Microsoft Entra ID
      ↓
Application Proxy
      ↓
Connector
      ↓
On-Premises Web Application

The connector is installed inside the organization’s network and establishes outbound communication to the Microsoft service.

This allows organizations to publish supported internal web applications without directly exposing the application server to the internet.

Q80. What is the role of the Application Proxy Connector?

The connector acts as the on-premises component that communicates with the Application Proxy service and facilitates access to the published application.

I would troubleshoot:

• Connector installation
• Connector service status
• Connector group
• DNS
• On-premises application reachability
• Firewall/proxy connectivity
• Application URL
• Authentication configuration
• Connector logs

A useful troubleshooting sequence is:

User
 ↓
Microsoft Entra
 ↓
Application Proxy Service
 ↓
Connector
 ↓
Internal Application

Senior Application Identity Architecture

Q81. When would you choose a managed identity, certificate, client secret or workload identity federation?

I would select the authentication mechanism based on the workload architecture.

Managed identity

Useful for supported Azure-hosted workloads.

Client secret

Simple, but requires secure storage and lifecycle management.

Certificate

Useful when certificate-based application authentication is appropriate and private-key protection can be managed securely.

Workload identity federation

Useful when an external workload can provide a trusted OIDC identity and I want to avoid a long-lived client secret.

A simplified decision model is:

Azure workload?
      |
     Yes
      ↓
Managed Identity may fit

External OIDC workload?
      |
     Yes
      ↓
Workload Identity Federation may fit

Traditional application?
      |
      +── Certificate
      |
      +── Client Secret

The final decision depends on the application’s capabilities and security requirements.

Q82. How would you design application authentication for separate development, test and production environments?

I would avoid using one application identity and credential set for every environment unless there is a specific reason to do so.

A cleaner model is:

Development
    ↓
Development Application Identity

Test
    ↓
Test Application Identity

Production
    ↓
Production Application Identity

This provides separation between environments.

I would also separate:

• Credentials
• Redirect URIs
• API permissions where appropriate
• Configuration
• Secrets
• Resource access

A production credential should not be unnecessarily present in development systems.

Q83. How would you troubleshoot an application that works interactively but fails when running as a background service?

I would first determine whether the two execution modes use different authentication flows.

For example:

Interactive Application
       ↓
Signed-in User
       ↓
Delegated Permission


Background Service
       ↓
Application Identity
       ↓
Application Permission

I would check:

• Authentication flow
• Client credential
• Certificate/secret
• Managed identity
• Application permissions
• Token acquisition
• Token audience
• API authorization
• Service account/environment configuration

A background process cannot automatically be assumed to have the same identity context as an interactive user.

Q84. As a senior administrator, how would you design application identity architecture for a large enterprise?

I would design the architecture around clear separation between:

Application
     ↓
Identity
     ↓
Authentication Method
     ↓
API Permissions
     ↓
Target Resource

I would establish consistent technical standards for:

• Application registrations
• Service principals
• Managed identities
• Workload identity federation
• Client credentials
• Certificates
• API permissions
• Consent
• Application ownership information
• Credential monitoring
• Authentication logging
• Development/test/production separation

I would prefer passwordless or secretless approaches such as managed identities and workload identity federation where they fit the workload.

The objective is to make application authentication:

secure, traceable, maintainable and appropriate to the workload.

Connect-MgGraph -Scopes "Application.Read.All"

Get-MgApplication

Get-MgApplication -ApplicationId "<Application-Object-ID>"

Get-MgServicePrincipal

Get-MgServicePrincipal -Filter "appId eq '<Application-ID>'"

Get-MgServicePrincipal -ServicePrincipalId "<Service-Principal-Object-ID>"

Next Part

Microsoft Entra ID Interview Questions –Part 5: Governance, PIM, Access Reviews & Privileged Identity

The next part will focus on the remaining governance and privileged access topics:

• Microsoft Entra RBAC
• Administrative roles
• Least privilege at the identity-governance level
• PIM
• Eligible/Active assignments
• JIT activation
• Approval/MFA for activation
• Time-bound assignments
• PIM for Groups
• Access Reviews
• Entitlement Management
• Access Packages
• Administrative Units
• Guest/external identity governance
• Lifecycle governance
• Privileged account security
• Role-assignment incidents