Start here! Get your feet wet with the Microsoft cloud and begin your journey to earning your Microsoft Certified: Azure Fundamentals certification!
Gauge your current knowledge
Gauge your current knowledge
Microsoft Entra ID is a cloud-based directory and identity management service that acts as the backbone for authentication and authorization in Azure. When you sign up for an Azure subscription, a dedicated Entra ID tenant—the organization’s own instance of the service—is created automatically. The tenant contains users, groups, and applications, and you can add custom domains like contoso.com to make sign-in names familiar. Each Azure subscription is linked to one Entra tenant, which establishes a trust relationship between billing and identity. Administrators use user and group management to organize access, assign roles such as Global Administrator or Privileged Role Administrator, and control subscription settings. Single sign-on (SSO) lets users sign in once and access multiple cloud and on-premises apps without repeated passwords, and integration with on-premises directories via Microsoft Entra Connect synchronizes user accounts and credentials for a hybrid identity approach.
Microsoft Entra Domain Services provides a managed domain in Azure that offers familiar Windows Server Active Directory features—such as domain join, group policy, and DNS—without requiring you to deploy or manage domain controllers. It synchronizes user accounts and credentials from Entra ID (or from on-premises Active Directory via Microsoft Entra Connect) into the managed domain, so the same identities work in the cloud as on-premises. The service supports LDAP, Kerberos, and NTLM authentication, which allows legacy and custom applications to authenticate against the cloud domain. You can also apply Group Policy to secure domain-joined virtual machines. Key use cases include lift-and-shift migrations (moving on-premises apps to Azure without changing authentication code), supporting remote branch offices, enabling older apps that require LDAP or NTLM, and offloading domain controller maintenance to Azure.
Microsoft Entra ID and Microsoft Entra Domain Services work together to provide consistent identity and access control across your cloud environment. Role-based access control (RBAC) in Entra ID lets you grant permissions based on least privilege using built-in or custom roles assigned to security principals at specific scopes. When integrating with Azure Virtual Machines, you can join VMs to Domain Services for seamless domain authentication, apply Entra ID conditional access policies, and use Group Policy to enforce security settings. For Azure App Services and databases, integration includes configuring Managed Identities in Entra ID so apps can securely access resources without storing credentials, enabling Entra ID authentication for web apps to provide single sign-on, and connecting Azure SQL Database to Entra ID for unified credential management. Organizations can also deploy Microsoft Entra joined devices to integrate laptops and PCs directly with Entra ID, enabling single sign-on both to cloud and on-premises resources and enforcement of Conditional Access through device compliance.
Entra ID and Domain Services simplify identity management and strengthen security across hybrid environments. A single wizard in the Microsoft Entra admin center enables Domain Services for your tenant, and after setup, user accounts and credentials are synchronized automatically. Entra Domain Services supports NTLM and Kerberos authentication, and high availability is built in by deploying multiple domain controllers—often across Azure Availability Zones—with replica sets for geographical disaster recovery and one-way forest trusts for secure connections to on-premises domains. Microsoft Entra ID adds advanced security features such as multifactor authentication, Conditional Access policies, and identity protection to detect suspicious activity. Best practices include enabling MFA for all users (especially administrators), applying Conditional Access rules to protect sensitive workloads, implementing Azure RBAC for fine-grained permissions, using Privileged Identity Management (PIM) for just-in-time access, and regularly reviewing security reports and audit logs.
Single sign-on (SSO) lets users sign in once and access multiple applications without re-entering credentials. This approach reduces password fatigue and the risk of weak or reused passwords. Azure integrates SSO through Microsoft Entra ID, which provides pre-integrated connectors for thousands of SaaS apps like Microsoft 365 and Salesforce. When an application does not support standard protocols like SAML or OAuth, you can use password-based SSO, where Azure AD securely stores credentials and fills them into the app’s sign-in page. Choose password-based SSO when an app only accepts a username and password, lacks support for token-based authentication, or needs a quick setup for legacy or custom web applications.
Multi-Factor Authentication (MFA) requires users to present multiple forms of evidence before accessing a resource, combining at least two factors: something you know (password), something you have (phone or hardware key), and something you are (fingerprint). Even if a password is stolen, the attacker still needs the second factor to sign in. Azure MFA supports verification methods such as Microsoft Authenticator app notifications or codes, OATH tokens, SMS, voice calls, and FIDO2 security keys. You can enable MFA using Security Defaults for a quick tenant-wide rollout or Conditional Access policies for granular control. Best practices include requiring MFA for all administrator accounts, blocking legacy authentication protocols that don’t support MFA, and asking users to register more than one verification method for fallback.
Passwordless authentication removes traditional passwords and uses stronger methods based on cryptographic keys, biometrics, or device-based credentials. Windows Hello for Business replaces passwords with a two-factor system tied to the device, using biometrics or a PIN stored securely on the device. FIDO2 security keys are physical USB, NFC, or Bluetooth devices that use public key cryptography—users plug in or tap the key to authenticate without entering a password or username. The Microsoft Authenticator app enables passwordless sign-in on mobile and desktop devices by using key-based authentication tied to the phone, unlocking with a PIN or biometric scan. These methods are phishing-resistant and reduce the risk of credential theft.
Authentication policies in Azure help control how users verify their identity. Self-Service Password Reset (SSPR) with optional Password Writeback allows users to recover their own accounts. Password Hash Synchronization keeps on-premises and cloud passwords in sync. Smart Lockout and Password Protection block brute-force attacks and weak passwords. Conditional Access policies give granular control over sign-in events: they can require MFA for high-risk sign-ins, block legacy authentication, enforce device-based access so only compliant devices can access resources, and apply risk-based rules to challenge or block suspicious activity. Integrating applications with Azure AD simplifies user access while maintaining security—for example, using the Azure AD Application Gallery to enable SSO for thousands of SaaS apps, or deploying Azure AD Application Proxy to secure on-premises web apps with corporate credentials.
Azure AD B2B collaboration allows organizations to share applications and services with guests from external companies. Instead of managing local credentials for these guests, the resource directory trusts the partner’s home identity provider to handle authentication. If a partner leaves their company and their home account is disabled, they automatically lose access to your shared resources. Administrators can set up entitlement management to define automated, time-bound access packages for specific external partners, ensuring that permissions are regularly reviewed and revoked when no longer needed. B2B collaboration integrates with core Microsoft services like SharePoint and OneDrive, allowing users to securely share files and collaboration spaces without exposing the wider network.
Azure AD B2C is a cloud service designed to manage identity and access for customer-facing applications. It lets customers sign in using their existing social or enterprise accounts from providers like Google, Facebook, and Microsoft accounts, removing the need to create yet another username and password. Organizations can fully customize the sign-up and sign-in screens—modifying the interface layout, language options, and branding elements to match their company identity. Built-in security features include multi-factor authentication and conditional access policies to protect customer data. The service integrates with other Azure services, allowing developers to build a secure, unified cloud environment that scales automatically as the customer base grows.
Managing external identities involves configuring how outside users interact with your cloud resources. Administrators use external user leave settings to control whether guest users can remove themselves from the tenant. When a guest user leaves, their account enters a soft deletion state for 30 days, during which an administrator can restore the user along with group memberships and access rights. For immediate removal, administrators can permanently delete the account, which triggers an irreversible deletion process that completes within 30 days. Administrators configure external identity providers to support protocols like SAML/WS-Fed and OpenID Connect, as well as social federation. To comply with privacy regulations like GDPR, organizations must publish clear privacy information so external guests can find contact details. Regular audit logs and access reviews help track these external accounts.
Microsoft Entra External ID acts as the central control plane to connect external identities to custom web and mobile applications. To establish trust between the application and external identity providers, Azure supports standards like SAML/WS-Fed and OpenID Connect alongside social logins. Traffic flows securely from the application to the identity provider to verify the user, and then returns a token to grant access. Administrators configure sign-up and sign-in user flows that define the exact steps a customer takes, such as verifying an email address or inputting custom attributes. When a user account is removed, the system places it into a soft deleted state for a 30-day grace period, ensuring accidental deletions can be recovered, after which the system automatically triggers permanent deletion.
Using external identities introduces distinct security mechanisms. For B2B scenarios, organizations can enforce Conditional Access and multi-factor authentication on guest users before they access corporate resources. For B2C environments, built-in features like email verification and custom user flows protect registration. However, B2B collaboration relies on the security of the partner’s identity provider, so an organization is partially dependent on the partner’s credential strength. For B2C, administrators face operational constraints such as a default seven-day log retention period and different licensing rules. Best practices include combining Conditional Access with risk-based policies that trigger MFA during unusual sign-in events, conducting regular access reviews to check if guests still require access, and configuring audit logs to spot suspicious patterns.
Microsoft Entra Conditional Access is a security tool that acts like a gatekeeper, evaluating signals such as user identity, device state, location, and application context before allowing access. Policies combine two main parts: assignments (who the policy applies to and what resources they are trying to reach) and controls (requirements like multi-factor authentication or a compliant device). By combining these elements, administrators enforce least privilege access. Policies can target users, groups, guest users, directory roles, or workload identities, and administrators should exclude emergency access accounts (break-glass accounts) to prevent accidental lockout. Conditional Access works as a policy engine that uses signals to make access decisions, and policies can run in report-only mode to test settings before enforcement.
Each Conditional Access policy has two key components: Assignments and Access controls. Assignments define which users, groups, guest users, or workload identities are included or excluded, which cloud apps or actions are targeted, and conditions such as location, device state, or risk signals. A policy only triggers when all assignment criteria are met. Access controls specify what happens when assignments and conditions match. Grant controls can block access entirely or grant access while requiring MFA, a compliant device, password change, or acceptance of terms of use. Session controls enforce limits such as sign-in frequency or application-enforced restrictions. To avoid accidental lockout, administrators should exclude break-glass and service accounts from policies, and use Conditional Access templates or report-only mode to validate settings before turning them on.
Conditional Access uses identity-driven signals to make access decisions, acting like an if-then statement: if a user tries to access a resource, then a policy is applied. These policies are enforced after first-factor authentication. Signals include user or group membership, IP location information (using trusted IP ranges or blocking by country), device state (platform, compliance, or hybrid Azure AD join status), the application being accessed, and real-time risk signals from Microsoft Entra ID Protection and Microsoft Defender for Cloud Apps. Based on these signals, administrators set conditions that trigger specific controls—blocking access entirely for untrusted sign-ins, granting access but requiring MFA or a compliant device, or requiring users to accept terms of use or change their password. This flexible approach allows organizations to apply the right level of security without hindering productivity.
After disabling security defaults, administrators enable Conditional Access policies in the Azure portal. Organizations with Microsoft Entra ID P2 licenses can also configure risk-based policies that respond to user or sign-in risk levels. Administrators can start with secure foundations templates to cover basic scenarios like requiring MFA or blocking legacy authentication, then expand with advanced controls. When configuring a policy, administrators define who is in scope by selecting users, groups, directory roles, or external user types, and use exclusions to protect break-glass accounts. To prevent administrator lockout, policies should apply to a small pilot group first with at least one emergency access account excluded. After deployment, administrators monitor and test policy impact by reviewing sign-in logs and Global Secure Access logs, and use Microsoft Secure Score and identity score features to measure security posture.
Troubleshooting Conditional Access often starts with the What If tool, which simulates how a policy applies to a specific user or sign-in. Administrators can temporarily disable a policy to confirm if it is causing sign-in blocks. Monitoring uses Azure AD sign-in logs and the Conditional Access insights workbook in Azure Monitor, which provides visual reports on policy usage and trends. Using report-only mode and impact reports helps evaluate policy changes safely—policies in report-only mode do not enforce controls but still generate logs showing what would have happened. Best practices include using consistent naming conventions for policies, excluding emergency access accounts, and scheduling regular reviews of logs and insights to keep policies aligned with changing business needs.
Azure role-based access control (RBAC) is the main authorization system in Azure. You grant access by assigning roles to a security principal (user, group, service principal, or managed identity) at a chosen scope. Each role definition is a collection of permissions for operations like read, write, or delete. Azure provides many built-in roles sorted into job function roles (for tasks like managing VMs) and privileged administrator roles (for high-level control). If none meets your needs, you can create custom roles to follow the principle of least privilege. A role assignment links a role to a principal within a specific scope. Azure scopes are organized in a hierarchy: management group, subscription, resource group, and resource. Roles at a higher level automatically apply to all child scopes, enabling inheritance of permissions. Azure RBAC uses an additive model—a user’s effective permissions are the union of all their role assignments. If a deny assignment exists, it overrides any allow permissions.
A role assignment consists of three elements: a security principal, a role definition, and a scope. Scopes in Azure RBAC are hierarchical—permissions assigned at a higher level (like a subscription) are inherited by lower levels (resource groups or individual resources). For example, if a role is assigned at the subscription level, it automatically applies to all resource groups and resources within that subscription unless explicitly overridden. Understanding scope inheritance is crucial: when a role is assigned at a broader scope, it cascades down to all contained resources. To manage access efficiently, assign roles at the lowest scope necessary to minimize the risk of over-permissioning, and regularly review role assignments and scopes.
To assign a role, you first identify a security principal who needs access—a user (individual with a Microsoft Entra ID profile), a group (collection of users that inherits the same role), a service principal (identity for applications or services to authenticate), or a managed identity (automatically managed identity by Azure for cloud applications). Permissions are grouped into role definitions (roles) organized into two categories: job function roles (like Virtual Machine Contributor or Storage Blob Data Reader) and privileged administrator roles (like Owner, which includes the ability to assign roles to others). When built-in roles don’t match your needs, you can create custom roles that let you pick specific Actions and DataActions to grant or deny. Roles can be assigned at multiple scopes, and group membership is transitive—nested groups inherit role assignments. Because Azure RBAC uses an additive model, a user’s effective permissions are the sum of all their role assignments across scopes.
Implementing RBAC effectively requires following the principle of least privilege—grant users only the permissions they need to perform their job functions. Conduct regular reviews of role assignments to identify and remove unnecessary access. Use Azure Policy to enforce RBAC policies by automating compliance checks and ensuring resources comply with corporate standards. By adhering to least privilege, conducting regular reviews, and utilizing Azure Policy, organizations can manage access to resources while maintaining a secure and compliant environment.
Azure Monitor and the Azure Activity Log capture events related to role assignments, such as creations, updates, and deletions. In the Azure portal, the Access control (IAM) blade provides a central view of role assignments—the Role assignments tab lists who has access at each scope, and the Check access feature lets you audit specific users, groups, service principals, or managed identities. Azure CLI and PowerShell offer commands to automate audits, such as az role assignment list and Get-AzRoleAssignment. Azure Security Center flags overly permissive roles and recommends remediation steps, helping you apply the Principle of Least Privilege. Continuous monitoring and proactive auditing of Azure RBAC configurations reduce security risks and maintain compliance.
Zero Trust is a security model built on never trust, always verify. It assumes that threats can originate from both inside and outside the corporate network, so no user or device is trusted by default. The model relies on three core principles: Verify explicitly (always authenticate and authorize based on all available data points, including user identity, location, and device health), Use least privilege (limit user access with just-in-time and just-enough access models), and Assume breach (minimize the impact of a security event by segmenting access, verifying end-to-end encryption, and monitoring continuously). Azure implements these principles primarily through Microsoft Entra ID (for single sign-on, conditional access, and device registration), Azure RBAC and Privileged Identity Management (PIM) (to enforce least privilege), and continuous monitoring tools like Identity Secure Score and risk-based conditional access.
Azure builds its Zero Trust architecture on centralized identity management via Microsoft Entra ID. Organizations use Conditional Access policies and Multi-Factor Authentication to enforce strict access control based on real-time signals such as device compliance, geographic location, user or group membership, and sign-in risk level. Setting up a secure architecture involves enabling password protection, deploying passwordless authentication methods, assigning least-privilege roles, and configuring PIM to manage elevated administrative access. Teams can use Microsoft Entra ID deployment plans and track progress using their identity secure score.
Under Zero Trust, every user, application, and device must be fully authenticated and authorized before gaining access to any resource. At the heart of Azure IAM is Microsoft Entra ID, which provides a unified identity platform for hybrid and cloud environments. It handles authentication and authorization, supports a reverse proxy to extend secure remote access to on-premises applications, and integrates MFA and SSO. To enforce least privilege, administrators use RBAC to assign specific permissions, and Privileged Identity Management (PIM) requires users to request temporary elevation with business justification and approval. Regular access reviews verify that users still require their assigned permissions over time, preventing long-term access accumulation.
Azure provides specialized security tools that isolate workloads and restrict traffic. Azure DDoS Protection defends against large-scale attacks, Virtual Network Service Endpoints and Azure Private Link route traffic over the private Microsoft backbone, Azure Bastion provides secure remote management, and Azure Front Door protects web applications at the network edge. These network controls work alongside identity controls (SSO, MFA, Conditional Access) and governance tools (RBAC, PIM). For threat management, Microsoft Defender for Cloud and Azure Security Center continuously assess resource configurations and provide active threat protection, while Azure Sentinel acts as a cloud-native SIEM to collect data and automate incident responses.
Adopting Zero Trust in Azure delivers improved security posture by stopping many cyber threats, reducing the risk of data breaches by preventing lateral movement, and simplifying compliance with regulatory requirements through detailed auditing and granular access controls. However, organizations must plan for practical challenges: managing granular security policies across thousands of users, devices, and applications introduces operational complexity; advanced security tools may require additional licensing costs, training, and specialized administrative resources; frequent authentication checks can impact user experience; and a Zero Trust environment requires continuous updates, threat monitoring, and policy reviews to remain effective against evolving threats.
Defense-in-depth is a security strategy that uses multiple layers of protection to safeguard cloud resources. Instead of relying on a single security control, this model places several barriers between an attacker and valuable data or systems. The core idea is that if one layer fails or is bypassed, the next layer still provides protection. This layered approach reduces the overall risk of a successful breach because an attacker would have to break through each barrier in sequence. In Azure, defense-in-depth is a fundamental principle for designing secure environments, ensuring that no single point of failure can compromise the entire system.
The defense-in-depth model in Azure includes several distinct layers. Physical security protects data center buildings and hardware from unauthorized physical access. Identity and access management uses tools like Microsoft Entra ID and Azure RBAC to verify who users are and what they can do. Perimeter security secures the network’s outer boundaries with firewalls and other technologies. Network security controls traffic inside the virtual network using services such as Network Security Groups (NSGs) and Azure Firewall. Compute security ensures virtual machines and other compute resources are hardened against attacks. Application security involves secure coding practices and regular assessments to protect applications from exploits. Data security encrypts data both at rest and in transit, using tools like Azure Storage Service Encryption and Azure Key Vault to keep sensitive information safe.
Applying defense-in-depth in Azure means using a combination of services that work together across the layers. At the identity and access management layer, administrators use Microsoft Entra ID, Azure RBAC, and MFA. The network security layer employs Network Security Groups, Azure Firewall, Azure DDoS Protection, Azure VPN Gateway, and Web Application Firewall (WAF). At the host and workload protection layer, Microsoft Defender for Cloud monitors security events, while Azure Key Vault stores secrets, keys, and certificates. Encryption services such as Storage Service Encryption and Transparent Data Encryption safeguard data at rest, and organizations can use client-side encryption before uploading data. The data protection and monitoring layer includes Azure Backup and Azure Site Recovery for disaster recovery, along with Azure Monitor Logs and Azure Storage Analytics to collect telemetry and detect unusual activity.
To evaluate how well defense-in-depth works, teams test their security layers under realistic conditions. For example, they might simulate a DDoS attack to see if Azure DDoS Protection can mitigate it, attempt unauthorized sign-ins to validate that MFA blocks the attempt, and review logs in Azure Monitor to ensure alerts are triggered when suspicious activity occurs. In a case study of an e-commerce site, the team would check how the network layer (NSGs, Azure Firewall), identity layer (Microsoft Entra ID, RBAC), and data layer (encryption, Key Vault) respond together. By assessing each layer under realistic conditions, teams identify gaps and improve their overall security posture.
Implementing a defense-in-depth strategy offers enhanced protection through multiple barriers, risk mitigation because the failure of a single layer does not lead to a complete breach, and comprehensive coverage by addressing physical, identity, network, compute, application, and data security. In Azure, the identity layer enforces least privilege, the network layer filters threats, and the compute and data layer protects sensitive assets. The monitoring and governance layer (Azure Monitor, Microsoft Sentinel, Azure Policy) delivers continuous insight and automated policy enforcement, enabling faster incident response and improved service resilience. Together, these layers increase the reliability of Azure deployments and help organizations meet compliance requirements.
Microsoft Defender for Cloud is a unified security management service that provides continuous security assessments and advanced threat protection across Azure and hybrid cloud environments. It centralizes security management, making it easier to monitor and respond to threats from a single dashboard. The service operates through two main pillars: Cloud Security Posture Management (CSPM) and threat detection. CSPM provides hardening guidance and compliance recommendations by scanning resources against best practices, while threat detection uses real-time monitoring and analytics to identify suspicious activities and generate alerts. These alerts can be integrated with other tools like Azure Monitor for streamlined incident response.
This function focuses on continuously assessing and improving the security health of your Azure resources. Defender for Cloud provides a security score and actionable recommendations based on regular scans that compare your configuration to industry standards. It helps you find and fix vulnerabilities and misconfigurations before they can be exploited. Security is managed through security policies and initiatives that you can set and customize across your subscriptions. The continuous assessment means your security posture is evaluated over time, and the scoring system lets you measure your improvements.
Defender for Cloud assists in meeting compliance obligations by providing tools and reports that track your alignment with industry standards like ISO or PCI. It maps security controls to these frameworks and delivers compliance scorecards, helping you understand your current standing and highlight areas that need improvement for audits. Key Azure services work with Defender for Cloud to manage compliance: Azure Policy evaluates resources to ensure they follow business rules and can block non-compliant actions, and Azure RBAC manages user permissions, ensuring only authorized actions are performed.
Defender for Cloud uses advanced analytics and threat intelligence to monitor for suspicious activities across virtual machines, databases, and other resources in real time. When a potential threat is identified, it generates detailed alerts with recommended actions for response. The service integrates with Security Copilot to help summarize threats and prioritize responses based on risk. Defender for Cloud evolves using securely processed data and user feedback, which helps it adapt to new threats, and its design prioritizes privacy and data security.
Defender for Cloud integrates with other Azure services to provide comprehensive security monitoring and management. It works seamlessly with Azure Security Center for unified visibility and with Azure Sentinel for advanced threat detection and automated response, allowing security teams to view, investigate, and respond to incidents from a centralized location. For network and application protection, it integrates with Azure DDoS Protection, Azure Front Door, Azure Private Link, and Azure Bastion to guard against attacks, secure private connectivity, and manage access. By unifying alerts and forwarding logs, these integrations simplify security management and help maintain a strong, end-to-end security posture across your Azure environment.