{"id":2934,"date":"2026-10-08T18:04:50","date_gmt":"2026-10-08T18:04:50","guid":{"rendered":"https:\/\/www.exam-topics.net\/blog\/?p=2934"},"modified":"2026-10-08T18:04:50","modified_gmt":"2026-10-08T18:04:50","slug":"az-900-identity-access-and-trust","status":"publish","type":"post","link":"https:\/\/www.exam-topics.net\/blog\/az-900-identity-access-and-trust\/","title":{"rendered":"AZ-900: Identity, Access, and Trust"},"content":{"rendered":"

Picture a finance analyst opening an Azure-hosted reporting application from a hotel Wi-Fi network. The organization wants to verify who is signing in, check whether the attempt is unusually risky, and allow only the permissions necessary for the analyst’s work. Those are three different security questions: authentication, sign-in policy and authorization. The AZ-900 exam<\/a> expects candidates to recognize the Azure services and concepts behind each one, even though it does not test advanced configuration of security policies.<\/p>\n

A surprising amount of cloud confusion begins when teams use \u201caccess\u201d to mean everything from proving identity to opening a firewall port. An application can have excellent network isolation but overly generous administrator permissions. A user can authenticate successfully and still be blocked by a sign-in rule. A securely stored password cannot compensate for granting an account permission to delete production resources. Azure Fundamentals becomes more intuitive once these boundaries are drawn.<\/p>\n

Directory identity is not the same as a user account on a VM<\/h2>\n

Microsoft Entra ID supplies cloud identity and access-management capabilities for users, applications and services. It is not simply a hosted copy of traditional Windows Server Active Directory. Many Microsoft 365 and Azure sign-in experiences use Entra ID, but a Windows workload requiring classic domain protocols or legacy Group Policy may need different directory capabilities. Microsoft Entra Domain Services can provide managed domain features for selected workloads without an organization operating domain controllers in the conventional way. These distinctions matter when a scenario contrasts cloud authentication with legacy application requirements.<\/p>\n

Older study material may call Entra ID \u201cAzure Active Directory.\u201d That historical name persists in screenshots and articles; it does not identify a different current identity product. The Azure AD to Microsoft Entra ID naming change<\/a> helps reconcile older tutorials with current terminology. A candidate should interpret the technical requirement rather than conclude that two names necessarily imply two competing services.<\/p>\n

Directory identities also include service principals and managed identities for applications. A background process often needs to read a secret or send a message to a service. Using a personal employee account for that task couples availability and permissions to a human user lifecycle. Managed identity patterns let compatible Azure resources obtain identity-backed access without embedding traditional credentials in application code. That is a principle, not a guarantee that every dependency automatically understands managed identity.<\/p>\n

Authentication asks who; authorization asks what<\/h2>\n

Authentication establishes that a subject is who it claims to be. Common techniques include passwords, multifactor authentication, passwordless methods and federated sign-in. Single sign-on aims to reduce repeated authentication prompts across trusted applications, while MFA adds a factor beyond a password. Passwordless authentication can also be designed around strong cryptographic methods rather than assuming that no proof of identity is needed. The security value depends on the method, registration protections, device state and resistance to phishing\u2014not merely the number of prompts.<\/p>\n

Authorization governs what an authenticated subject is allowed to do. Azure role-based access control uses role assignments at defined scopes to grant resource permissions. Someone permitted to view a storage account’s configuration is not necessarily permitted to read the data inside it; management-plane and data-plane permissions can be separate. The most important AZ-900 distinction is conceptual: a successful sign-in does not convey unlimited rights to the subscription. Access is deliberately narrowed by role and scope.<\/p>\n

This is why role-based access control<\/a> is a better mental model than collecting administrator accounts. A small support group might need to restart an application but not change payment-processing secrets. Assigning broad subscription ownership for convenience turns an operational exception into a standing risk.<\/p>\n

Conditional Access adds context to the sign-in decision<\/h2>\n

A Conditional Access policy evaluates conditions associated with an access attempt and applies configured access controls. Depending on licensing, signals, supported applications and policy configuration, those conditions may consider properties such as user, resource, device state or sign-in risk. A familiar example is requiring stronger authentication for an access attempt to a sensitive application. But Conditional Access is not synonymous with multifactor authentication: it is a framework that can use MFA as one possible control among others.<\/p>\n

Consider the analyst who normally works from a managed office laptop. When they sign in from an unfamiliar device, the security team may require additional evidence of trust or deny access to certain data. The design must distinguish the user’s identity from the posture of the device and from the sensitivity of the application. An identity provider evaluates those signals; a network firewall alone cannot decide all of them.<\/p>\n

The mechanics of Microsoft Entra Conditional Access<\/a> become more important in role-based studies such as SC-300<\/a>. For AZ-900, focus on the purpose: adapt access requirements to context without treating every sign-in as identical. Poorly scoped rules can also cause outages, which is why exclusions and emergency access require careful planning.<\/p>\n

Zero Trust describes an approach, not one Azure switch<\/h2>\n

Zero Trust treats access as something to verify continuously using the available evidence rather than granting lasting trust simply because a user or device sits on an internal network. Its familiar themes include explicit verification, least-privilege access and assuming that compromise is possible. Those principles can be expressed through identity controls, device posture, network segmentation, monitoring and data protection. Buying a product with \u201czero trust\u201d in its marketing name does not automatically create a Zero Trust architecture.<\/p>\n

Defense in depth is related but not identical. It means using multiple layers of protection so one control’s failure does not immediately expose the entire asset. An attacker who obtains a password could still be impeded by phishing-resistant authentication, narrow resource roles, network restrictions, application authorization and sensitive-data controls. No layer is perfect; the point is to keep a single weakness from turning into unrestricted access.<\/p>\n

The shared responsibility model sets the baseline for these designs. Azure operates its physical infrastructure, but customers retain responsibility for many identity, access, data and application decisions. Even in a managed platform, someone must decide whether an application should access personal information, how administrators are approved and what evidence should be retained after a security incident. Fundamentals questions often test that ownership distinction through plain-language scenarios.<\/p>\n

Permissions need scopes, not just role names<\/h2>\n

Azure resource access is organized through management groups, subscriptions, resource groups and resources. A role assignment applies at a particular scope and, subject to the system’s rules, can influence access to lower scopes. Consequently, a narrow permission assigned at a broad scope may reach more resources than intended. This is a frequent misunderstanding: users focus on whether a role sounds powerful while ignoring the boundary where it is assigned.<\/p>\n

A development engineer may need to operate one test environment without modifying production infrastructure. Giving that engineer Contributor at the test resource-group scope is categorically different from assigning the same role at a subscription scope. The exact permission set of built-in roles matters during administration, but the AZ-900 concept is to combine a role with an intentionally limited scope. Resource locks and Azure Policy affect operations and governance in other ways; they do not transform an excessive access grant into a least-privilege design.<\/p>\n

An administrative incident illustrates the difference. Suppose a user can sign into the Azure portal but cannot create a virtual machine. Authentication worked; authorization or policy may be blocking creation. Suppose the user cannot sign in at all: the initial evidence likely belongs to identity and sign-in policy. Starting with the failed layer avoids a common habit of granting more permissions to solve every problem.<\/p>\n

Security visibility is broader than the sign-in screen<\/h2>\n

Microsoft Defender for Cloud can assess security posture and surface recommendations or alerts across supported workloads and environments. It is not a replacement for deciding who gets an Azure subscription role. Azure Monitor provides operational telemetry; identity services record sign-in and access-related information; application logs describe software activity. Each helps answer a different part of a security question. A failed sign-in and a storage account exposed publicly are different kinds of evidence even if both represent security risk.<\/p>\n

At the fundamentals level, learn the distinction between preventing a failure and detecting one. Multifactor authentication can strengthen authentication; Azure RBAC limits authorized actions; policy can evaluate or constrain configurations; monitoring can reveal incidents or operating conditions. A mature program combines those controls and tests whether the intended behavior actually occurs. It also accounts for exceptions: emergency access procedures should be documented rather than improvised by permanently exempting privileged accounts.<\/p>\n

The perspective becomes especially useful for a company adopting both Azure and Microsoft 365. Identity decisions can affect users across products, while the exact resource permissions and application data controls remain workload-specific. An SC-900<\/a> candidate explores security, compliance and identity fundamentals more broadly; the AZ-900 task is to know where identity, resource authorization and Azure security capabilities fit in the cloud architecture.<\/p>\n

Diagnose the layer before naming a service<\/h2>\n

Return to the travelling analyst. A password prompt succeeds, but the reporting application is blocked on an unmanaged device. More subscription permissions will not fix a Conditional Access decision. A colleague can open the application but cannot modify an Azure resource. A sign-in policy change will not necessarily supply an RBAC assignment. A third employee can access data through an application despite lacking Azure portal rights. Their application-level permissions are not identical to Azure management-plane roles.<\/p>\n

These small differences are central to sound security reasoning. Ask what is being protected, what decision was made, where the decision is enforced and who operates that control. Azure exposes many security features, but AZ-900 is less about remembering every setting than about knowing when a situation concerns identity, sign-in context, authorization, cloud posture or the shared responsibility model. Once those categories are distinct, unfamiliar scenarios become much easier to interpret.<\/p>\n","protected":false},"excerpt":{"rendered":"

Picture a finance analyst opening an Azure-hosted reporting application from a hotel Wi-Fi network. The organization wants to verify who is signing in, check whether the attempt is unusually risky, and allow only the permissions necessary for the analyst’s work. Those are three different security questions: authentication, sign-in policy and authorization. The AZ-900 exam expects […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[10,1],"tags":[],"class_list":["post-2934","post","type-post","status-publish","format-standard","hentry","category-microsoft","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/posts\/2934","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/comments?post=2934"}],"version-history":[{"count":1,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/posts\/2934\/revisions"}],"predecessor-version":[{"id":3437,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/posts\/2934\/revisions\/3437"}],"wp:attachment":[{"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/media?parent=2934"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/categories?post=2934"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/tags?post=2934"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}