Azure Fundamentals – Identity and Access

Module 1 – The 5 Types of Identities

Module 2 – Microsoft Entra ID (formerly Azure Active Directory)

Concept

• Microsoft cloud identity service (IAM: Identity and Access Management).
• Tenant: a private space for an organization in Entra ID.
• Each organization has its own tenant (identified by a domain: contoso.onmicrosoft.com).

User Types

B2B Collaboration

External invitation process:
1. Admin sends invitation to user@partnercompany.com
2. A guest user is created in your tenant
3. The partner clicks "Accept" in the email
4. Authenticates with their own credentials (their tenant)
5. Access to shared resources

Module 3 – RBAC (Role-Based Access Control)

Principles

• 120+ built-in roles in Azure.
• Assigned to a security principal (user, group, service principal, MSI).
• Applied to a scope (management group, subscription, resource group, resource).
• Permissions are inherited down to lower scopes.

Scope Hierarchy

Management Group (all subscriptions in the organization)
  └── Subscription
        └── Resource Group
              └── Individual Resource

Assigning Owner at the RG level → the user is Owner of all resources in that RG.

Common Built-in Roles

Create a Role Assignment

Azure Portal → Resource Group → Access control (IAM)
  → Add role assignment
  → Role: Contributor
  → Assign access to: User, group, or service principal
  → Members: [select user or group]
  → Review + assign

Module 4 – Multi-Factor Authentication (MFA)

3 Authentication Factors

MFA = at least 2 different factors.

MFA Methods in Entra ID

• Microsoft Authenticator app (push notification, TOTP code).
• FIDO2 security keys (YubiKey).
• SMS (less secure).
• Voice call.
• Authenticator app on Windows Hello.

Module 5 – Conditional Access

Concept

“IF conditions → THEN action” policy to control access.

Conditions
  ├── User/Group (who?)
  ├── Application (to what?)
  ├── Device platform (from what?)
  ├── Location (from where?)
  └── Sign-in risk (AI-based)
            ↓
Action (Grant / Block)
  ├── Require MFA
  ├── Require compliant device
  ├── Require specific app
  └── Block access

Policy Examples

Summary

Deep Dive – Azure Identity and Access (Enhanced Sections)

Section 6 – Microsoft Entra ID: Architecture and Licensing

6.1 Tenant / Directory / Subscription Relationship

An Entra ID tenant is a dedicated instance of Microsoft’s identity service. It is automatically created when signing up for Microsoft 365 or Azure. Multiple Azure subscriptions can be linked to the same tenant, but a subscription can only belong to one tenant.

graph TD
    T["Entra ID Tenant\n(contoso.onmicrosoft.com)"]
    T --> D["Directory\n(Users, Groups, Apps, Devices)"]
    T --> S1["Azure Subscription #1\n(Production)"]
    T --> S2["Azure Subscription #2\n(Dev/Test)"]
    T --> M365["Microsoft 365 Licenses\n(Exchange, Teams, SharePoint)"]
    S1 --> RG1["Resource Groups\n(VMs, Storage, SQL...)"]
    S2 --> RG2["Resource Groups\n(Test VMs...)"]

Key point: The tenant = the security container. Subscriptions = billing and resource containers. A tenant can exist without an Azure subscription (example: Microsoft 365-only tenant).

6.2 Entra ID License Tiers

Included in: Microsoft 365 E3 → Entra P1 · Microsoft 365 E5 → Entra P2

6.3 Group Types

Dynamic Groups (P1 required)

Members are automatically calculated via a query rule on user or device attributes.

# Dynamic membership rule – Example
(user.department -eq "Finance") and (user.accountEnabled -eq true)

# All Windows 10/11 devices
(device.operatingSystem -eq "Windows") and (device.operatingSystemVersion -startsWith "10")

6.4 Administrative Units

Administrative units allow delegating Entra ID administration to a subset of users or groups, without granting rights over the entire tenant.

graph LR
    GA["Global Administrator\n(Entire Tenant)"]
    UA1["User Admin – North Region\n(AU: Quebec)"]
    UA2["User Admin – South Region\n(AU: Ontario)"]
    GA -->|delegates| UA1
    GA -->|delegates| UA2
    UA1 --> U1["QC Users"]
    UA2 --> U2["ON Users"]

Use case: University with multiple campuses, multi-region company, MSP managing multiple clients in a single tenant.

Section 7 – Authentication: Methods and Protocols

7.1 Hybrid Identity Synchronization Models

In most companies, identities already exist in an on-premises Active Directory Domain Services (AD DS). Entra Connect (formerly Azure AD Connect) synchronizes these identities to Entra ID.

flowchart LR
    ADDS["Active Directory\nOn-premises\n(AD DS)"]
    EC["Entra Connect\n(sync tool)"]
    EID["Microsoft Entra ID\n(Cloud)"]
    ADDS -->|sync every 30 min| EC
    EC -->|Password Hash Sync\nor Pass-Through Auth\nor Federation| EID

Hybrid Authentication Methods

7.2 Seamless Single Sign-On (SSO)

Seamless SSO allows users on domain-joined machines to automatically sign in to Entra ID without re-entering credentials, via Kerberos.

Seamless SSO Flow:
1. User opens browser on domain-joined PC
2. Browser automatically sends Kerberos ticket
3. Entra ID validates the ticket via the SSO agent
4. Token issued → access granted without prompt

7.3 Primary Refresh Token (PRT)

The PRT is a special token issued during initial authentication on a device (Windows, iOS, Android). It enables SSO across all apps on the device without re-authentication.

7.4 Authentication Protocols: Modern vs Legacy

Important: Microsoft disabled Basic Authentication for Exchange Online in October 2022. Legacy protocols do not support MFA → major risk. Block them via Conditional Access.

Section 8 – MFA and Advanced Authentication Methods

8.1 Overview of Authentication Methods

mindmap
  root((Authentication\nEntra ID))
    Password
      Hash Sync
      Pass-Through
      Self-Service Reset
    Possession
      Microsoft Authenticator
        Push notification
        6-digit TOTP code
        Passwordless phone sign-in
      FIDO2 Security Keys
        YubiKey
        Feitian
      Smart card
    Biometrics
      Windows Hello for Business
        Facial recognition
        Fingerprint
        Hardware TPM PIN
    Legacy
      SMS OTP
      Voice call
      OATH hardware tokens

8.2 TOTP – Time-based One-Time Password

The Microsoft Authenticator app (and any TOTP-compatible app: Google Authenticator, Authy) generates a 6-digit code valid for 30 seconds, based on:

• A shared secret registered during setup
• The current time (clock synchronization)

TOTP Algorithm (RFC 6238):
TOTP = HOTP(secret, T) where T = floor(unix_time / 30)
The server accepts T-1, T, T+1 (tolerance window)

8.3 FIDO2 and Physical Security Keys

FIDO2 (Fast IDentity Online 2) is an open standard enabling passwordless authentication via a USB/NFC/Bluetooth key.

sequenceDiagram
    participant U as User
    participant B as Browser
    participant EID as Entra ID
    participant K as FIDO2 Key (YubiKey)

    U->>B: Navigate to app
    B->>EID: Request challenge
    EID-->>B: Cryptographic challenge
    B->>K: Sign the challenge (PIN + touch the key)
    K-->>B: Signed response (private key)
    B->>EID: Send response
    EID-->>U: Access granted (public key validated)

FIDO2 Advantages:

• Phishing-resistant (the key only responds to the legitimate domain)
• No shared secret on the server side
• Native passwordless

8.4 Windows Hello for Business (WHfB)

WHfB replaces the password on Windows devices with:

• A PIN tied to the device’s TPM (never travels over the network)
• Biometrics (face / fingerprint) as local PIN unlock

Key difference:
Traditional password → the same secret on all devices
WHfB PIN → unique to the device + stored in the TPM
               → even if someone steals the PIN, it's useless on another device

8.5 Passwordless Authentication

Microsoft recommends a passwordless strategy:

8.6 SMS and Voice Call – Legacy Methods

Microsoft recommends not using SMS/Voice as the primary MFA method. Migrate to the Authenticator app or FIDO2.

Section 9 – Conditional Access: Advanced Policies

9.1 Anatomy of a Conditional Access Policy

flowchart TD
    A["Access Request"]
    A --> B{Applicable CA\npolicy?}
    B -->|No| Z["Access authorized\n(baseline)"]
    B -->|Yes| C["Evaluate CONDITIONS"]
    C --> D["Users / Groups"]
    C --> E["Target Applications"]
    C --> F["Platform / Device"]
    C --> G["Location (IP/Country)"]
    C --> H["Sign-in / User Risk"]
    D & E & F & G & H --> I{All conditions\nmatch?}
    I -->|No| Z
    I -->|Yes| J["Apply CONTROLS"]
    J --> K["Grant Controls\n(MFA, Compliant Device,\nHybrid Join, ToU...)"]
    J --> L["Session Controls\n(duration, app restrictions,\nCASB sign-in frequency)"]
    K & L --> M["Final decision:\nAllow / Block"]

9.2 Named Locations

Named locations allow defining trusted (or risky) IP ranges or countries.

// Example: Named Location "Main Office"
{
  "displayName": "Main Office – Montreal",
  "isTrusted": true,
  "ipRanges": [
    { "cidrAddress": "203.0.113.0/24" },
    { "cidrAddress": "198.51.100.0/28" }
  ]
}

Common usage:

• Exempt MFA from office IPs (trusted location)
• Block access from high-risk countries
• Alert on connections from unusual countries

9.3 Device Compliance

Integration with Microsoft Intune to verify device state before granting access.

9.4 Risk Policies

Powered by Entra ID Identity Protection (P2 license), risk policies evaluate risk in real-time.

// Example CA policy based on risk
{
  "displayName": "Block High Risk Sign-ins",
  "conditions": {
    "signInRiskLevels": ["high"],
    "users": { "includeUsers": ["All"] },
    "applications": { "includeApplications": ["All"] }
  },
  "grantControls": {
    "operator": "OR",
    "builtInControls": ["block"]
  }
}

9.5 Report-Only Mode

Before enabling a CA policy in production, use report mode:

Policy state:
  ✅ On         → Applied immediately
  📊 Report-only → Evaluated but not applied (logs only)
  ❌ Off        → Disabled

Allows measuring the impact on users before deployment. View results in Entra ID → Sign-in logs → Conditional Access (“Report-only result” column).

9.6 What-If Tool

The What-If tool (in Entra ID → Conditional Access → Policies → What If) simulates which policies would apply for a given scenario:

Simulation parameters:
  - User: alice@contoso.com
  - Application: Microsoft Exchange Online
  - IP address: 1.2.3.4 (country: Russia)
  - Platform: iOS
  - Sign-in risk: Medium

Result: Policy "Block Risky Countries" → BLOCK
        Policy "MFA for All Users" → GRANT (if MFA satisfied)

9.7 Gaps and Conditional Access Best Practices

Section 10 – Privileged Identity Management (PIM)

10.1 Concept: Just-In-Time (JIT)

Without PIM, administrators have their roles permanently (standing access). PIM introduces the Just-In-Time model: roles are available but not active.

stateDiagram-v2
    [*] --> Eligible : Eligible assignment\n(admin approves)
    Eligible --> Activation_requested : User requests\nactivation
    Activation_requested --> Pending_approval : Approval\nrequired
    Pending_approval --> Active : Approver\nvalidates
    Activation_requested --> Active : No approval\nrequired (auto)
    Active --> Expired : Maximum duration\nreached (e.g. 8h)
    Expired --> Eligible : Back to\neligible state

10.2 PIM Assignment Types

10.3 PIM Activation Flow

sequenceDiagram
    participant A as Alice (User)
    participant PIM as PIM Service
    participant M as Manager (Approver)
    participant AAD as Entra ID

    A->>PIM: "I need the Global Admin role for 2h"
    PIM->>A: Request justification + MFA
    A->>PIM: Justification: "Incident #4521" + MFA validated
    PIM->>M: Notification email + approval request
    M->>PIM: Approve the request
    PIM->>AAD: Activate role for Alice (2h)
    AAD-->>A: Role active – access granted
    Note over A,AAD: After 2h: role automatically expired
    PIM->>A: Email: "Your Global Admin role has expired"

10.4 PIM Configuration – Role Settings

"Global Administrator" role settings in PIM:
├── Maximum activation duration: 4 hours
├── MFA required on activation: ✅ Yes
├── Justification required: ✅ Yes
├── Approval required: ✅ Yes
│   └── Approvers: [security-admins@contoso.com]
├── Activation notifications: ✅ Yes (admin + user)
└── Access review: Every 90 days

10.5 Access Reviews in PIM

Access Reviews allow periodically certifying that role assignments are still justified.

Best practice: Configure Access Reviews on all privileged roles (Global Admin, Security Admin, Exchange Admin).

10.6 PIM Benefits

Section 11 – Entra ID Governance

11.1 Access Reviews

Access Reviews allow certifying user access to resources periodically and in an automated manner.

flowchart LR
    CR["Create an\nAccess Review"]
    CR --> SC["Scope:\nGroup / App /\nEntra Role / Azure Role"]
    SC --> REV["Reviewers:\nManagers / Members /\nOwners / Guests"]
    REV --> EVAL["Evaluation:\nApprove / Deny /\nDon't know"]
    EVAL --> AUTO["Automatic action\nif no response:\nRemove / Keep"]
    AUTO --> RPT["Full audit\nreport"]

Supported Scopes

11.2 Entitlement Management

Entitlement management automates access workflows for internal users and external partners.

graph TD
    CAT["Catalog\n(resource grouping)"]
    CAT --> AP["Access Package\n(resource bundle)"]
    AP --> GRP["Security Group"]
    AP --> APP["SSO Application"]
    AP --> SP["SharePoint Site"]
    AP --> ROLE["Azure Role"]
    AP --> POL["Access Policy"]
    POL --> WHO["Who can request?\n(internal / external users /\nconnected organizations)"]
    POL --> APPR["Approval required?"]
    POL --> DUR["Access duration\n+ periodic review"]
    POL --> EXP["Automatic expiration"]

Key Components

# Scenario: Onboarding an external partner
1. Admin creates "Partner Project Alpha" Access Package
   → Contains: Teams Group + SharePoint App + Azure Reader Role
2. Partner navigates to myaccess.microsoft.com
3. Requests access with justification
4. Manager approves in the portal (or by email)
5. Access automatically granted for 6 months
6. Access Review at 3 months: manager certifies access
7. Expiration at 6 months: access automatically removed

11.3 Lifecycle Workflows

Lifecycle Workflows automate tasks related to employee lifecycle events.

timeline
    title Employee Lifecycle with Lifecycle Workflows
    section Before arrival (D-7)
        Create Entra ID account
        Assign M365 licenses
        Add to base groups
    section Arrival (D0)
        Send welcome email
        Generate TAP (Temporary Access Pass)
        Notify manager
    section Transfer (D+180)
        Update department
        Update groups
        Revoke old access
    section Departure (D+365)
        Disable account
        Revoke all sessions
        Remove licenses
        Delete after 30 days

Section 12 – Azure RBAC: Deep Dive

12.1 Scope Hierarchy and Inheritance

graph TD
    MG["Management Group"]
    MG --> MG2["Sub-management group"]
    MG2 --> SUB["Subscription"]
    SUB --> RG["Resource Group"]
    RG --> RES["Individual Resource\n(VM, Storage, SQL...)"]

    MG -.->|"Inheritance\n↓"| MG2
    MG2 -.->|"Inheritance\n↓"| SUB
    SUB -.->|"Inheritance\n↓"| RG
    RG -.->|"Inheritance\n↓"| RES

Rule: A role assigned at a parent scope is automatically inherited by all child scopes. The reverse is not true.

12.2 Common Built-in Roles

12.3 Custom Roles

When no built-in role matches exactly, create a custom role.

{
  "Name": "VM Restart Operator",
  "Description": "Can start/stop/restart VMs only",
  "Actions": [
    "Microsoft.Compute/virtualMachines/start/action",
    "Microsoft.Compute/virtualMachines/restart/action",
    "Microsoft.Compute/virtualMachines/deallocate/action",
    "Microsoft.Compute/virtualMachines/read"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
  ]
}

# Create the custom role via Azure CLI
az role definition create --role-definition vm-restart-operator.json

# Assign the role to a user
az role assignment create \
  --assignee alice@contoso.com \
  --role "VM Restart Operator" \
  --scope /subscriptions/xxxxxxxx/resourceGroups/rg-production

12.4 Deny Assignments

Deny assignments block specific actions even if a role allows them. Created automatically by:

• Azure Blueprints (when locking resources)
• Azure Managed Applications
• Not manually creatable by users

RBAC resolution priority:
  1. Deny assignment (ALWAYS highest priority)
  2. Role assignment Allow
  3. Access denied by default (implicit deny)

12.5 Role Conditions (ABAC)

Entra ID supports conditions on certain roles (Attribute-Based Access Control) to fine-tune permissions.

// Example: Storage Blob Data Reader only on blobs tagged "project=Alpha"
{
  "condition": "@Resource[Microsoft.Storage/storageAccounts/blobServices/containers/blobs:tags:project<$key_case_sensitive$>] StringEquals 'Alpha'",
  "conditionVersion": "2.0"
}

Section 13 – Managed Identities

13.1 Problem Solved by Managed Identities

Without Managed Identity, an application accessing Key Vault must store its own credentials → risk of leakage.

graph LR
    subgraph "Before (credentials in code)"
        APP1["App Service"] -->|"client_id + client_secret\nstored in config"| KV1["Key Vault"]
    end
    subgraph "After (Managed Identity)"
        APP2["App Service\n(Managed Identity enabled)"] -->|"Automatic token\n(no secret)"| KV2["Key Vault"]
        AAD["Entra ID\n(Azure Managed)"] -->|"issues token"| APP2
    end

13.2 System-Assigned vs User-Assigned

13.3 Enable a Managed Identity

# System-Assigned – Enable on a VM
az vm identity assign \
  --name myVM \
  --resource-group rg-production

# User-Assigned – Create and attach to a VM
az identity create \
  --name my-managed-identity \
  --resource-group rg-production

az vm identity assign \
  --name myVM \
  --resource-group rg-production \
  --identities /subscriptions/.../my-managed-identity

# Assign an RBAC role to the Managed Identity
az role assignment create \
  --assignee-object-id <principal-id-of-identity> \
  --assignee-principal-type ServicePrincipal \
  --role "Key Vault Secrets User" \
  --scope /subscriptions/.../vaults/my-key-vault

13.4 Usage in Code (Without Credentials)

# Python – Access Key Vault with Managed Identity
from azure.identity import ManagedIdentityCredential
from azure.keyvault.secrets import SecretClient

# No client_id, client_secret, tenant_id in the code!
credential = ManagedIdentityCredential()
client = SecretClient(
    vault_url="https://my-keyvault.vault.azure.net/",
    credential=credential
)
secret = client.get_secret("db-password")
print(f"Value: {secret.value}")

// C# – Access Azure Storage with Managed Identity
using Azure.Identity;
using Azure.Storage.Blobs;

// DefaultAzureCredential automatically tries:
// 1. Managed Identity, 2. VS Code, 3. Azure CLI, 4. etc.
var credential = new DefaultAzureCredential();
var blobClient = new BlobServiceClient(
    new Uri("https://mystorage.blob.core.windows.net/"),
    credential
);

13.5 Managed Identities on AKS

In Azure Kubernetes Service, pods can use Managed Identities via Workload Identity (successor of Pod Identity).

# Annotation on the Kubernetes ServiceAccount
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa
  namespace: default
  annotations:
    azure.workload.identity/client-id: "<user-assigned-identity-client-id>"
---
# Pod using this ServiceAccount
apiVersion: v1
kind: Pod
metadata:
  name: my-app
  labels:
    azure.workload.identity/use: "true"
spec:
  serviceAccountName: my-app-sa
  containers:
  - name: app
    image: myapp:latest
    # No env variables with secrets!

Section 14 – External Identities

14.1 B2B Collaboration – Details

sequenceDiagram
    participant A as Contoso Admin
    participant EID as Contoso Entra ID
    participant EMAIL as Email Service
    participant P as Partner (bob@fabrikam.com)
    participant FEID as Fabrikam Entra ID

    A->>EID: Invite bob@fabrikam.com
    EID->>EMAIL: Send invitation email
    EMAIL->>P: "You have been invited to access Contoso"
    P->>EID: Click "Accept invitation"
    EID->>FEID: Redirect for authentication
    FEID-->>EID: Identity token (bob is authenticated at Fabrikam)
    EID-->>P: Guest user created in Contoso tenant
    Note over P,EID: Bob authenticates with his Fabrikam credentials\nbut accesses Contoso resources

Cross-Tenant Access Settings

14.2 Entra External ID – B2C (Customer Identity)

Entra External ID for Customers (formerly Azure AD B2C) is a CIAM (Customer Identity and Access Management) solution for consumer applications.

graph LR
    C1["Customer\n(Google)"]
    C2["Customer\n(Facebook)"]
    C3["Customer\n(Local Email)"]
    C4["Customer\n(Apple)"]
    B2C["Entra External ID\n(Dedicated B2C Tenant)"]
    APP["Your Application\n(e-commerce site,\nmobile app...)"]

    C1 -->|OAuth2| B2C
    C2 -->|OAuth2| B2C
    C3 -->|Email+Password| B2C
    C4 -->|OAuth2| B2C
    B2C -->|JWT Token| APP

B2C Components

B2B vs B2C Difference

Section 15 – Zero Trust

15.1 Fundamental Principles

The Zero Trust model abandons the traditional network perimeter (“castle and moat”) in favor of a continuous verification approach.

graph TD
    subgraph "Traditional model (perimeter)"
        FW["Firewall"] --> INT["Internal Network\n🏰 Fully trusted"]
    end
    subgraph "Zero Trust"
        ZT1["Verify Explicitly"]
        ZT2["Least Privilege"]
        ZT3["Assume Breach"]
        ZT1 <--> ZT2
        ZT2 <--> ZT3
        ZT3 <--> ZT1
    end

15.2 Zero Trust Pillars

mindmap
  root((Zero Trust))
    Identities
      Mandatory MFA
      Conditional Access
      PIM / JIT
      Identity Protection
    Devices
      Intune Compliance
      Defender for Endpoint
      Windows Hello for Business
    Applications
      Conditional Access Apps
      MCAS / Defender for Cloud Apps
      App Governance
    Data
      Information Protection
      DLP Policies
      Purview
    Infrastructure
      Azure Security Center
      Defender for Servers
      Least-privilege RBAC
    Network
      Micro-segmentation
      Azure Firewall
      Private Endpoints

15.3 Zero Trust Implementation with Entra ID – Roadmap

Level 1 – Foundations (Entra ID Free)
  ✅ MFA enabled for all users
  ✅ Security Defaults enabled
  ✅ Block legacy authentication

Level 2 – Advanced (Entra ID P1)
  ✅ Conditional Access policies
  ✅ Named Locations configured
  ✅ Device Compliance (Intune)
  ✅ Hybrid Join or Entra Join
  ✅ Dynamic groups

Level 3 – Optimal (Entra ID P2)
  ✅ Identity Protection (risk-based policies)
  ✅ Privileged Identity Management (PIM)
  ✅ Regular Access Reviews
  ✅ Entitlement Management
  ✅ Lifecycle Workflows
  ✅ Passwordless authentication (FIDO2 / WHfB)

Section 16 – Review Questions

Quiz – 12 Questions

Q1. A user from the Fabrikam organization is invited to collaborate on resources in the Contoso tenant. What is this type of user called in the Contoso tenant?

A. External member
B. Internal guest
C. External guest ✅
D. Service principal

Explanation: A user invited from an external organization is an External Guest in the hosting tenant. Their account is managed by their home organization.

Q2. Which hybrid authentication method stores an AD password hash in Entra ID and allows authentication even when on-premises servers are unavailable?

A. Pass-Through Authentication
B. Password Hash Sync ✅
C. Federation (ADFS)
D. Seamless SSO

Explanation: PHS synchronizes a secure hash of the password to Entra ID, enabling cloud-only authentication in case of on-premises outage.

Q3. Which Entra ID license is required to use dynamic membership groups?

A. Entra ID Free
B. Entra ID P1 ✅
C. Entra ID P2
D. Entra ID Governance

Explanation: Dynamic groups require a minimum Entra ID P1 license. PIM and Identity Protection require P2.

Q4. A developer wants their App Service to access Azure Key Vault without storing any secrets in code or configuration. Which feature should they use?

A. Service Principal with certificate
B. Storing secrets in environment variables
C. Managed Identity ✅
D. B2B Collaboration

Explanation: Managed Identities allow Azure services to authenticate against other services without managing credentials.

Q5. In PIM, what is the difference between an “Eligible” and an “Active” assignment?

A. There is no difference
B. Eligible means the role is permanently active
C. Eligible means the user can activate the role on demand; Active means the role is permanently active ✅
D. Active requires approval, Eligible does not

Explanation: An Eligible assignment requires manual activation (possibly with MFA + justification + approval). An Active assignment grants access immediately and permanently.

Q6. Which Conditional Access tool allows simulating which policies would apply to a given user without creating a real sign-in event?

A. Report-Only Mode
B. Identity Protection
C. What-If tool ✅
D. Access Reviews

Explanation: The What-If tool allows testing hypothetical sign-in scenarios and seeing which CA policies would be evaluated.

Q7. You want a Conditional Access policy to be evaluated and its results logged, without actually blocking users. What state should you configure?

A. Off
B. On
C. Report-only ✅
D. Audit

Explanation: Report-only mode evaluates the policy and logs the result in sign-in logs without applying it, ideal for measuring impact before deployment.

Q8. A company wants to offer its customers (general public) login via their Google or Facebook account in its mobile application. Which Azure solution should it use?

A. Entra ID B2B Collaboration
B. Entra External ID for Customers (B2C) ✅
C. Entra ID Free
D. Privileged Identity Management

Explanation: Entra External ID for Customers (B2C) is specifically designed for customer identities with support for social identity providers (Google, Facebook, Apple…).

Q9. An Azure administrator wants to assign permissions only on Storage blobs whose tag attribute “project” equals “Alpha”. Which access control mechanism should they use?

A. Classic RBAC
B. Conditional Access
C. ABAC (Attribute-Based Access Control via role conditions) ✅
D. Managed Identity

Explanation: RBAC role conditions (ABAC) allow refining permissions by adding conditions based on resource attributes.

Q10. Which Zero Trust principle requires segmenting the network, encrypting communications and monitoring all activities, assuming a breach has already occurred?

A. Verify explicitly
B. Least privilege
C. Assume Breach ✅
D. Defense in depth

Explanation: Assume Breach pushes you to minimize the blast radius of an attack by assuming the attacker is already inside the system.

Q11. In Entra ID Governance, which feature allows grouping resources (groups, apps, Azure roles) into “packages” requestable by internal or external users via a self-service portal?

A. Access Reviews
B. Lifecycle Workflows
C. Entitlement Management (Access Packages) ✅
D. Privileged Identity Management

Explanation: Entitlement Management enables creating Access Packages — access bundles requestable via the myaccess.microsoft.com portal with approval workflows and automatic expiration.

Q12. Which open passwordless authentication standard uses asymmetric cryptographic key pairs and is phishing-resistant because the private key never leaves the device?

A. TOTP (RFC 6238)
B. SAML 2.0
C. OAuth 2.0
D. FIDO2 ✅

Explanation: FIDO2 uses public/private key cryptography. The private key stays on the device (or physical key), the public key is registered on the server. Phishing-resistant because the key only responds to the domain it was registered for.

Final Summary – Reference Table

Advanced Section – Review Questions and Glossary

Review Questions – Azure Identity and Access

Question 1 What is the difference between authentication (AuthN) and authorization (AuthZ)?

• A) Authentication = who you are; Authorization = what you can do
• B) Authentication = what you can do; Authorization = who you are
• C) They are two terms for the same concept
• D) Authentication applies to humans; Authorization to applications

Answer: A — Authentication (AuthN): proving your identity (who you are). Authorization (AuthZ): determining what you can do with your permissions. Example: authenticate with MFA (AuthN), then access only certain files (AuthZ).

Question 2 Your organization wants users to access Azure resources only from company-managed devices (Intune-compliant) and only from approved countries. Which Entra ID feature allows configuring these conditions?

• A) PIM (Privileged Identity Management)
• B) Conditional Access Policies (Entra ID P1)
• C) Identity Protection (Entra ID P2)
• D) Access Reviews

Answer: B — Conditional Access Policies (requires Entra ID P1) allow defining conditions (location, device type, user risk, target application) and controls (MFA required, access blocked, compliant device required).

Question 3 A developer wants an Azure Function to access Azure Key Vault with no secrets or credentials in the code. Which Entra ID feature enables this?

• A) Service Principal with client secret
• B) Managed Identity (System-assigned)
• C) B2B Guest User
• D) Application Registration with certificate

Answer: B — The Managed Identity (System-assigned) automatically creates an identity in Entra ID for the Function App. Azure manages the credentials lifecycle. The Function authenticates against Key Vault with no secrets in the code.

Question 4 What is the difference between Azure AD B2B and Azure AD B2C?

• A) B2B is for partners and external contractors (guests in your tenant); B2C is for your end customers (identities managed outside your tenant)
• B) B2B is for customers; B2C is for partners
• C) B2B and B2C are the same thing
• D) B2B is free; B2C requires a Premium license

Answer: A — B2B: invite partners/contractors with their own identities (Microsoft, Google, etc.) into your tenant as Guest Users. B2C (External ID): create an identity platform for your end customers (sign-up, login via social networks, CIAM).

Question 5 Your IT admin needs to temporarily grant “Global Administrator” rights to an engineer for a 2-hour emergency task, with CISO notification and audit trail. Which service should be used?

• A) Permanently assign the Global Administrator role
• B) Use PIM (Privileged Identity Management) with JIT activation and required approval
• C) Create a custom time-limited role
• D) Use Identity Protection to grant access based on risk

Answer: B — PIM (Privileged Identity Management) enables JIT activation of privileged roles with: configurable duration (2h), approval workflow (CISO notification), MFA required, and full audit trail of all activations.

Question 6 What is the principle of “least privilege” in the context of Azure RBAC?

• A) Grant all rights by default, then reduce as needed
• B) Grant only the minimum permissions necessary to perform the specific task, at the narrowest possible scope
• C) Only grant rights to administrators
• D) Use only built-in roles, never custom roles

Answer: B — The principle of least privilege means: grant ONLY the strictly necessary permissions for the task, and ONLY at the minimal required scope (specific resource rather than entire subscription).

Glossary – Azure Identity and Access

Search Terms

azure · fundamentals · identity · access · core · infrastructure · microsoft · authentication · entra · methods · pim · identities · conditional · managed · questions · types · b2b · b2c · concept · mfa · role · roles · trust · zero