Identify the boundary before choosing a directory feature
An identity question can describe several different boundaries. One application may depend on old directory protocols. A partner may need to use an existing external identity. An already identified user may need to satisfy a device or authentication condition before access is granted. These are separate problems, and the word identity does not decide among them. Begin with who owns the resource, what protocol the application expects, and which decision is missing. This keeps directory compatibility, external collaboration, sign-in controls and resource permissions from being treated as interchangeable labels.
Managed domains for a particular dependency
Microsoft Entra Domain Services provides managed domain join, LDAP and Kerberos/NTLM capabilities for compatible workloads. It can help an application that cannot readily be changed to modern authentication. The customer does not run the domain-controller VMs for this managed service. That does not make Domain Services a universal replacement for all identity infrastructure. A modern application that already uses Entra ID should not be moved to old protocols simply because the term domain sounds familiar. Identify the actual compatibility requirement and keep the distinction between the application and the managed directory explicit.
External collaboration keeps two organizations visible
With Microsoft Entra B2B collaboration, a partner can access an organization’s shared resources using the partner’s own identity. The organization owning the resource retains control over the collaboration and the access it grants. The guest relationship is not the same as giving every partner an ordinary employee identity in the resource organization. Nor does accepting an invitation grant unrestricted access to all applications and data. Separate proving the partner’s identity from deciding which resource permissions are appropriate, and keep the external party’s role clear when explaining the design.
Conditional Access evaluates an access condition
Conditional Access is an if-then policy mechanism that combines signals such as identity, device state, location or application context with access controls. For example, an organization may require MFA under a stated condition. The official overview places Conditional Access after first-factor authentication and does not describe it as the frontline defense against denial-of-service attacks. This is why it should not be credited with every security responsibility. A role assignment answers what actions a principal may perform on a resource; a sign-in condition determines whether the applicable access requirements have been satisfied.
Worked example: a shared research service
A fictional museum shares a modern application with an external survey team. The museum wants partners to use their own identities, so B2B collaboration addresses that relationship. It also requires an additional authentication control under a defined device condition, so Conditional Access addresses that policy requirement. A separate legacy catalog still requires LDAP and domain join; Domain Services addresses that compatibility boundary if the workload is supported. The museum may therefore have several valid identity capabilities in one environment. None of those decisions by itself specifies the complete resource permissions, data-governance policy or production security design.
Transfer check and Zero Trust reasoning
Change the museum case so a user is connecting from an internal office network. Does that location alone justify bypassing identity or device checks? No: Zero Trust verifies explicitly, limits privileges and assumes breach rather than treating network position as sufficient proof. Now change the application to one that genuinely requires LDAP. Explain why a managed-domain capability can be relevant without making it the choice for every modern sign-in. Finish by stating one fact that would make you choose external collaboration instead. A sound answer ties the mechanism to the boundary and preserves the conditions; it does not rely on an absolute claim that one identity service solves every access problem.
Layered defenses and posture are different evidence
Defense in depth uses complementary security layers rather than relying on one control to stop every attack. In a fictional office, limiting identity permissions, protecting network paths and applying application/data controls address different opportunities for harm. Passing the sign-in check does not prove all other layers are effective. Defender for Cloud provides security posture recommendations and related protection capabilities; a recommendation identifies work to investigate, not proof that every workload is now secure. If a team wants to inspect resource security posture, a data catalog or VM placement mechanism answers a different question. Keep the intended security outcome visible before selecting a feature.
Worked extension and transfer check: one layer fails
The fictional museum finds that a stolen credential passed one identity check. A layered approach asks which other controls can limit exposure rather than declaring the entire environment trusted. If the team next needs recommendations about resource security posture, investigate Defender for Cloud; this is distinct from the previous guest or LDAP decision. Transfer: a new resource still needs appropriate permissions and review even after a Conditional Access policy succeeds. Explain why that success cannot be treated as evidence that every other layer is correct. The check basis is that complementary layers address different failure paths, and a posture recommendation is evidence for investigation rather than universal assurance.
Try it, then explain it.
Complete a short set without looking at the example. After each answer, explain which evidence or rule supports your decision and why the alternatives do not fit.
Sources & authorship
Original OpenExam explanations and examples. References support the concepts; they are not the source of copied questions. Independent educator review is pending.
rd-az-b2brd-az-conditionalrd-az-defenderrd-az-domainsrd-az-identity-module-detailrd-az-mfard-az-rbacrd-az-zero