AZ-500 Secure identity and access Practice Question
Which THREE of the following are valid methods to secure service principals in Microsoft Entra ID?
⚠ Common exam trap
A common mix-up: candidates confuse user identity security controls (like MFA) with workload identity security controls, assuming MFA can be applied to service principals, when in fact it cannot.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Use certificate-based credentials instead of client secrets
Option A is correct because certificate-based credentials are a more secure alternative to client secrets for service principals; the public key is registered in Microsoft Entra ID and the private key is held by the app, so no shared secret is transmitted or stored, reducing the risk of credential theft. Option C is correct because Conditional Access for workload identities is a policy engine specifically designed to evaluate service principal sign-ins and can block or restrict them based on conditions such as location, risk, or IP range, which helps protect non-human identities. Option E is correct because Managed Identities for Azure resources let Azure create and rotate the service principal's credentials automatically, eliminating the need to store and manage secrets or certificates in code or configuration. Option B is not appropriate because assigning a service principal the Global Administrator role grants excessive, unnecessary privileges and does not secure the principal; it increases risk. Option D is not valid because Azure Multi-Factor Authentication applies to interactive user sign-ins and cannot be enforced for a service principal, which authenticates non-interactively with secrets, certificates, or federated credentials.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Use certificate-based credentials instead of client secrets
Why this is correct
Certificates rely on a public/private key pair: Microsoft Entra ID stores and validates only the public key, while the private X.509 key stays protected in a certificate store or hardware security module. This removes shared client secrets from source code and configuration, and certificate expiry and rollover can be automated. Because a client secret is simply a string that can be copied or leaked, certificate-bound credentials provide substantially stronger authentication assurance for service principals.
- ✗
Assign the service principal to the Global Administrator role to monitor its activity
Why it's wrong here
Placing the service principal into the Global Administrator role does not monitor or secure anything; it grants the workload directory-wide, high-privilege administrative access. Monitoring should instead be performed via Microsoft Entra ID sign-in logs, audit logs, and alerting on anomalous activity. Global Administrator is a privileged role, so assigning it to a service principal is a security risk and a direct violation of the least-privilege principle.
- ✓
Configure Conditional Access for workload identities to restrict sign-in conditions
Why this is correct
Conditional Access policies can now target workload identities, including service principals, to enforce conditions such as sign-in risk, source IP location, and device state before a token is issued. This complements user-based policies and restricts non-interactive sign-ins to trusted networks or compliant clients. The policy applies when the service principal authenticates to a cloud application, though it does not cover every Azure Resource Manager sign-in path.
- ✗
Enable Azure Multi-Factor Authentication for the service principal sign-in
Why it's wrong here
Azure Multi-Factor Authentication is designed for interactive user sign-ins that can present a second factor such as a phone app, phone call, or code. Service principals authenticate non-interactively using a certificate or client secret and cannot complete a second-factor challenge, so MFA is not enforced for those workload sign-ins. Therefore, enabling MFA for a service principal is not a valid security control and leaves the workload identity without that layer of protection.
- ✓
Use Managed Identities for Azure resources to avoid managing credentials
Why this is correct
Managed Identities provide an automatically managed Microsoft Entra ID identity for Azure resources; the platform creates and rotates the credentials automatically, so developers never store or retrieve the secret. Code running inside the resource obtains tokens from the Azure Instance Metadata Service, which presents the credential on behalf of the resource. This eliminates the risk of credential leakage from source code, configuration files, or developer workstations, making managed identities the preferred choice for Azure-hosted workloads.
Go deeper
Related to this question
About these practice questions
Courseiva writes every AZ-500 question from scratch — 617 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-500 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-500 exam.