Security is often discussed as an Azure feature, yet no single feature decides who can access data, which workloads are exposed or whether an administrator may delete production resources. Microsoft AZ-900 introduces the major identity, protection and governance concepts so candidates can recognize the appropriate boundary for a question. The exam is foundational, but the distinctions matter in real organizations: authentication is not authorization, a private network is not proof of trust, and a managed cloud service does not automatically make every customer configuration secure.
Imagine a company with a sales application, a finance reporting environment and a cloud operations team. Employees need access appropriate to their roles, developers deploy applications, and contractors should not retain permissions when a project finishes. The security design must handle human identities, workload identities, resource permissions, network reachability and audit evidence. Azure provides many building blocks, but each performs only part of that job.
Begin with identity: who is making the request?
Microsoft Entra ID is a cloud identity and access management service that can authenticate users and support application identity scenarios. Older material may call it Azure Active Directory; Microsoft Entra ID and the former Azure AD name refer to the renamed service rather than two independent identity providers. Understanding the current terminology helps candidates avoid confusing identity functions with on-premises Active Directory domain services or with Azure resource management.
Authentication establishes that a requester can present accepted credentials and satisfy the relevant sign-in requirements. Authorization decides what the authenticated principal may do. An employee can successfully sign in and still lack permission to open a finance report. A service application can have a valid identity but no access to a particular storage container. Strong authentication is valuable, but broad authorization can still expose sensitive data. A sound design applies both, with permissions granted for the minimum necessary scope.
Multifactor authentication raises assurance by requiring an additional supported factor or authentication method, while single sign-on reduces repeated sign-in friction across compatible applications. They address different user problems. A phishing-resistant method can offer stronger protection than a weaker second factor, but the exact requirement depends on policy and supported applications. Exam scenarios may contrast convenience, user verification and risk-based control; do not assume one identity feature substitutes for all the others.
Conditional Access makes identity decisions contextual
Conditional Access can evaluate defined signals and enforce specified grant or session controls for protected resources. An organization might require stronger authentication for sensitive apps, restrict unsupported clients or require an enrolled device to report compliant state where appropriate. This is policy evaluation, not a blanket authorization to everything in the tenant. A user still needs application and resource permissions after satisfying the sign-in conditions. The basics of Microsoft Entra Conditional Access help explain how conditions and controls combine.
Consider a remote employee using a company laptop from an unusual location. A sign-in policy may require a stronger authentication method or take other actions based on configured rules. That does not mean Azure automatically identifies every malicious session or continuously verifies every application action. Sign-in policy, endpoint compliance, data access and monitoring operate across different stages. The organization must decide which signals are sufficiently reliable for its risk tolerance and test policies before broad enforcement.
Emergency access also matters. An excessively broad access policy may lock out the administrators needed to repair it. Privileged accounts require especially strong protection, audit and recovery procedures. Exemptions should be narrow, documented and monitored, not a general escape hatch for users who prefer fewer prompts. Even at the fundamentals level, understanding the consequence of applying a policy at the wrong scope is more useful than memorizing a sequence of buttons.
Scope resource authorization with Azure RBAC
Azure role-based access control governs actions on Azure resources at scopes such as management groups, subscriptions, resource groups and individual resources. Broad roles at a high scope can affect many descendants. A developer who needs to deploy into one test resource group does not automatically need owner-level rights to every production subscription. Design around job responsibility and the smallest workable scope. A role is a collection of permitted actions, and the assignment binds that role to a principal at a particular scope.
Distinguish Azure management permissions from application data permissions. Having permission to manage a storage account is not necessarily the same thing as being authorized to read every object through the data plane. Similarly, access to a SQL resource in the portal does not imply unlimited rights inside every database. Services may have separate management and data roles. The concepts behind role-based access control make these differences easier to reason about, but an exam question’s exact resource and action determine the relevant permission path.
Privileged Identity Management and related governance capabilities can help manage elevated access for appropriate environments, but the foundational objective is simpler: reduce standing privilege, monitor important assignments and review them when responsibilities change. Offboarding needs to remove unnecessary access, including service accounts and delegated permissions. A temporary consultant who keeps rights for months after leaving is a security risk even if the original assignment was legitimate.
Shared responsibility changes by service type
Azure protects its underlying physical cloud infrastructure within the relevant shared-responsibility model, while customers retain responsibility for data, identities, access choices and other workload-specific controls. The exact division differs between infrastructure, platform and software services. A virtual machine customer must care about its guest operating system and applications; a managed database service removes some infrastructure chores but still requires secure schema access and sensible data handling. ‘It is hosted in Azure’ never means ‘the customer has no security work.’
Think through a ransomware scenario. Azure’s infrastructure security does not automatically ensure that a customer application uses least privilege or that its data is backed up with adequate recovery separation. A vendor-provided security feature may require configuration, licensing or appropriate integration before it reduces risk. A good control map states what the provider operates, what the customer configures and which evidence shows that the requirement is satisfied. This is one of the most durable cloud security concepts across service families.
Data protection includes encryption in transit and at rest, key management and secure network access. Different encryption methods protect against different threats. For example, encrypting a disk limits some offline disclosure risks but does not prevent an authorized application from querying a sensitive record. A private endpoint can reduce public network exposure for a supported service, yet does not automatically authorize or deny individual users. These distinctions become detailed implementation questions in Microsoft AZ-500, but AZ-900 candidates should first understand their purposes.
Use governance to prevent mistakes at scale
Azure Policy can evaluate and enforce or report on resource configuration rules according to supported effects and assignments. Organizational requirements might restrict deployment locations or require specific tagging practices. Role-based access control instead governs what actions principals are permitted to take. The two controls complement one another: an administrator with resource deployment permission may still encounter a policy restriction on a disallowed configuration. Governance is about defining an acceptable operating environment, not only handing permissions to the right users.
Resource locks can help prevent accidental deletion or modification of protected resources according to lock level. They are not a substitute for backups, least privilege or complete application protection. Tags help allocate resources to owners, projects or budgets, but a tag by itself is not an access-control boundary. Management groups and subscriptions help apply broad organization, while resource groups help organize related assets. Exam questions sometimes offer all these terms as alternatives; identify whether the requirement concerns who may act, which configurations are acceptable or how resources should be classified.
Microsoft Defender for Cloud and other security management capabilities can provide posture visibility and recommendations according to enabled plans and resources. Recommendations are not the same as complete threat prevention, and a dashboard score does not prove compliance with every business or legal requirement. Microsoft Sentinel is associated with security information and event management capabilities, a distinct purpose from changing an individual VM’s access settings. Tools contribute signals and controls; security teams still need response plans and accountability.
Monitor controls and design for human mistakes
Security measures should be testable. Review significant sign-in events, role changes, policy violations and configuration drift through the relevant telemetry tools. Log collection itself must respect retention, sensitivity and access limits. A team cannot investigate a privilege escalation if it has no record of administrative changes, but an enormous log archive is not useful if it contains sensitive data without controls or no one looks at alerts. Prioritize events that correspond to real decisions and response ownership.
Misconfiguration is one of the ordinary risks of an easy-to-provision environment. New storage, a virtual machine with a public address or a broad role assignment can appear quickly. Naming conventions, policy guardrails, access reviews and automation help prevent mistakes from propagating. Test emergency procedures and rollback for high-impact security changes. Security is not only defending against adversaries; it is also limiting the effect of errors made by authorized people.
For AZ-900, translate each prompt into the type of boundary involved. ‘Who can manage these resources?’ suggests Azure RBAC. ‘Which users must satisfy additional sign-in conditions?’ suggests identity and Conditional Access. ‘Which configurations may be deployed?’ suggests policy governance. ‘What is the customer still responsible for?’ requires the shared-responsibility model. The ability to separate these questions is the foundation for implementing a secure Azure environment without assuming that any one branded service solves everything.