Two decisions in an access request
Authentication establishes or verifies identity; authorization determines what the identified principal may do. Microsoft Entra ID is a centralized cloud identity provider;Azure resource authorization determines relevant permitted actions and scope. These participate in related but different parts of an access process. A user can sign in successfully yet lack a resource action. Conversely,broad resource permissions do not prove that an identity was protected appropriately. This lesson covers selected identity and RBAC concepts,not every directory,federation,external-identity or conditional-access feature.
Read actions together with scope
Azure RBAC assigns a role to a security principal at a scope. The role defines allowed actions and the scope identifies where the assignment applies. A narrow action set at an unnecessarily broad scope can still expose more resources than the task needs. A narrow scope with an unnecessarily powerful role can still grant extra actions. Existing assignments also matter: adding a narrower role is not a general way to cancel broader grants. The exact permission evaluation must be checked for real services and data-plane actions.
Worked example
A fictional astronomy outreach group defines a study-only role that can read resource configuration. A volunteer needs that view for one project resource group, without updates. First identify the needed actions: reading configuration, not changing it. Next identify scope: the one project group, not all groups in the subscription. Combining that limited action set and limited scope follows the requirement. If a separate broad grant already existed, merely adding the limited role would not establish the desired final restriction; the exercise must state existing grants before claiming a unique access result.
A factor is not a resource role
Multifactor authentication uses more than one authentication factor to reduce reliance on a single proof such as a password. It does not, by itself, assign an Azure role or turn a read-only authorization into an update permission. Similarly, replacing a password method does not determine the correct management scope. For conceptual cases, ask which weakness is being addressed: identity proof, credential risk, permitted actions or resource reach. Keep production account changes and security configuration outside this learning exercise.
Transfer check
A fictional student signs in with two factors and then receives a permission denial when trying to delete a resource. The stated role permits reads only, and there are no other grants. Does the second factor imply the deletion should have been authorized? Check basis: no. The factor strengthens authentication; the supplied authorization still lacks delete. Explain both the successful identity step and the missing action permission. If the case instead changed the role or scope, re-evaluate that separate condition rather than treating authentication as the answer to every access question.
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. authorizationHow it works: Microsoft Entra multifactor authenticationWhat is Azure role-based access control (Azure RBAC)?