Follow a fictional museum’s mixed identity requirements without confusing a protocol, a guest relationship and an access policy.
Answer with a boundary, not a brand list
Start an Azure identity comparison by naming the missing decision. A legacy application may need managed LDAP or domain join. An external collaborator may need to use an existing identity. A sign-in may need additional controls based on device or other signals. These requirements can coexist, so a useful answer does not insist that the organization select one feature for its entire identity architecture. This article uses a fictional museum to compare the boundaries. It is a foundation explanation with original examples, not a deployment procedure or a guarantee that a particular configuration satisfies every security or compliance obligation.
Write down the resource and the person
The museum owns a research application and an older catalog. Employees, external survey partners and application components may all interact with different resources, but they are not the same kind of principal. Before choosing a mechanism, state who requests access, which organization owns the resource, and what evidence of identity already exists. A request that says a partner needs the research application is not a request to make the partner an employee, nor is it automatically a requirement for legacy directory protocols. Clear roles prevent a familiar service name from substituting for an actual explanation.
Legacy protocol compatibility is a specific requirement
The old catalog depends on LDAP and domain join, and changing its authentication code is outside the current transition. Microsoft Entra Domain Services provides managed domain capabilities for compatible workloads, including LDAP and Kerberos/NTLM, without the customer managing the domain controllers. This directly addresses the protocol dependency. It does not establish that every application should authenticate through the managed domain, or that a modern application should adopt an older protocol. The official documentation positions this as a bridge for relevant legacy dependencies. Keep compatibility separate from blanket claims about the best identity architecture for every workload.
A guest relationship crosses an organization boundary
The survey partner already has an identity and needs the museum’s shared application. B2B collaboration permits sharing company resources with guests who use their own identities while the museum retains control over its data and the collaboration. The external identity and the guest representation are related, but they do not erase the resource owner’s access decisions. Granting a guest access to one application is not evidence that the guest should receive all employee permissions. It is also not evidence that a managed LDAP domain is needed. Describe the collaboration requirement and the resource’s permissions explicitly.
A sign-in condition is not the whole permission model
Suppose the museum has already decided which application functions a partner may use. It now requires additional authentication when a specified device condition is not met. Conditional Access can evaluate signals and apply if-then access controls such as requiring MFA. The official overview describes these policies after first-factor authentication, rather than as a universal first barrier against every network attack. A resource role and a Conditional Access policy answer different questions. Having an application permission does not prove that the sign-in satisfies the required conditions; meeting a sign-in condition does not automatically grant every resource permission.
Use Zero Trust to challenge a shortcut
A colleague suggests that office-network connections should be trusted automatically because they come from inside the museum. Zero Trust provides a better reasoning framework: verify explicitly, use least privilege and assume breach. The purpose of that framework is to avoid treating location alone as sufficient evidence. It does not mean that risk disappears when several Microsoft features are enabled, or that every feature should be turned on without a requirement. In the case, identify the identity and device signals that matter, the limited access needed, and the consequences if an account or device is compromised. Keep unresolved design questions visible rather than inventing a complete security assurance.
Resolve overlapping answers with the stated conditions
Several proposed answers may involve identities, but their immediate jobs differ. Domain Services provides the stated legacy protocol compatibility. B2B collaboration represents the external partner relationship. Conditional Access evaluates applicable access conditions. Resource permissions remain a separate authorization concern. When an option seems plausible, ask which requirement it would close and which requirement would remain. If the case never says that an application uses LDAP, selecting a managed domain may be an unjustified assumption. If it never identifies an external collaborator, a B2B guest flow may not be relevant. Adding services is not a substitute for naming the missing condition.
Apply the comparison and keep the scope bounded
Create a small requirement record for a new case: resource owner, user organization, required protocol, existing identity evidence, requested permission and conditional access requirement. An unknown cell is a question to investigate, not a value to guess. The two checks below change one boundary at a time so you can explain your choice without relying on a memorized slogan. After answering, use the linked lesson and practice to contrast the strongest alternative. These examples provide selected AZ-900 foundations; operational rollout, licensing, exact policy configuration and learner-validated readiness remain outside this article’s claim.
Apply the guide
A partner needs one shared application and already has an external identity. Does this fact by itself create a requirement for an LDAP managed domain?Reveal explanation
No. It describes an external collaboration boundary. A managed LDAP domain needs a separate supported application-protocol requirement.
A user has the appropriate resource role but fails a required device/MFA access condition. Does the role assignment automatically satisfy that condition?Reveal explanation
No. Resource authorization and the applicable sign-in access controls are distinct. The user must satisfy both relevant requirements.
Turn the idea into practice.
Apply the rule to a new case, then explain your choice.
Practice this skillSources & authorship
Official factual references informed original teaching; retained source bodies and archive questions are private research inputs.
Original OpenExam article, fictional examples and diagram; no source questions reproduced.
Independent educator review is pending. This guide is not an official exam paper or a video transcript.
rd-az-conditionalrd-az-zerord-az-domainsrd-az-b2brd-az-mfard-az-rbac