Use an evidence ledger
An access story may combine several facts that appear to the user as one smooth experience. Authentication establishes an identity; authorization concerns permitted actions on particular targets. An identity provider maintains identity information and supplies identity services. Keep these roles separate in your notes. Record who or what is being identified, which provider is trusted for that identity, and which application action is requested. A blank permission entry means that permission is unknown, rather than automatically approved or denied.
Identity reuse is not one mechanism
Single sign-on describes an experience in which authentication can be reused when accessing resources relying on the same identity, reducing repeated visible sign-in. Federation describes accepting an identity maintained elsewhere through the relevant identity relationship. Synchronization keeps corresponding identity information aligned between directories. These can participate in an overall design, but one term is not proof that all the others are present. In particular, fewer prompts do not establish replicated business permissions, and a replicated user record does not by itself establish an external authentication trust.
Keep the application action explicit
A central identity provider does not make the phrase authorized user a complete statement. Ask authorized for which action on which resource. Reading a draft and publishing it are different actions even if both use the same identity. Equally, an access refusal does not prove authentication failed when the facts locate the refusal at a missing action permission. The formal reinforcement question in this unit revisits that distinction from an earlier AWS learning task; it counts as a learning item, not a newly independent cross-exam capability.
Worked example
Fictional teaching case: a regional orchestra accepts a guest curator’s identity from a partner institution, but wants separate decisions about viewing rehearsal notes and editing public descriptions. The identity relationship can use federation; it does not choose the editing permission. Build three entries: partner identity authentication, accepted identity relationship, and orchestra application actions. If the partner identity is accepted but the editing action has not been assigned, the evidence supports accepted identity with an unresolved editing entitlement. Creating a second password is not necessary merely to express a different application permission.
Transfer check
Consider another fictional system: two applications rely on the same identity provider and a volunteer reaches the second without another visible sign-in. Nobody has described any external partner trust or directory replication. Which claim is supported? Check basis: the described experience supports single sign-on, while federation and synchronization are not established by that fact alone. The second application can still evaluate its own permissions. This changes the evidence task from choosing a partner relationship to limiting an inference about a user experience.
Explain the boundary
Use precise nouns in the final explanation: identity information, authentication relationship, application action and target. Avoid replacing all four with access. This lesson does not teach directory-service internals, protocol configuration or a complete Active Directory model; those official-outline areas remain explicit coverage gaps rather than being inferred from the existence of this unit.
Identity perimeter is an evidence boundary
A cloud application's access decision follows an identity and policy context even when the user connects from a familiar network. A successful sign-in is evidence about the asserted identity, while a denied customer-record operation can still reflect a missing application data role. In a fictional worked case, a visiting analyst reaches the app and signs in, but cannot read one protected dataset. First retain the successful connectivity and authentication observations; then inspect the stated authorization requirement. Repeating the same successful sign-in is not a complete repair for a missing permission. As a transfer check, imagine the person holds a reading role in a different app: that other resource's grant does not establish permission here. The appropriate owner must decide whether access should be assigned, not simply grant it because a login succeeded.
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.
Authentication vs. authorization - Microsoft identity platform | Microsoft LearnWhat is hybrid identity with Microsoft Entra ID? - Microsoft Entra ID | Microsoft LearnIdentity and Access Management (IAM): Core Concepts and Benefits - Microsoft Entra | Microsoft LearnMicrosoft Learn: rd-sc-identity