AZ-305: Identity, Governance and Monitoring

Table of Contents

• Module 1: Designing Identity for Azure Solutions
  • 1.1 Authentication Using Microsoft Entra ID Identities
  • 1.2 Demo: Creating Identities in Microsoft Entra ID
  • 1.3 Authorization with RBAC
  • 1.4 Demo: Authorization with RBAC
  • 1.5 Demo: Custom RBAC Roles
  • 1.6 Identity Best Practices
  • 1.7 Demo: Identity Best Practice Tools in the Azure Portal
• Module 2: Designing Governance for Azure Solutions
  • 2.1 Governing Azure Workloads
  • 2.2 Demo: Azure Policy — Enforcing Data Residency
  • 2.3 Using Policy Initiatives to Comply with Industry Standards
  • 2.4 Demo: Azure Policy Initiative — PCI-DSS Compliance
  • 2.5 Balancing Compliance and Agility
  • 2.6 Demo: Balancing Compliance and Agility with Scopes and Exemptions
• Module 3: Designing Incident Response and Monitoring for Azure Solutions
  • 3.1 Monitoring Azure Resources
  • 3.2 Monitoring Azure Infrastructure Using Log Analytics Workspace
  • 3.3 Demo: Log Analytics Workspace
  • 3.4 Demo: Monitoring Applications with Application Insights
  • 3.5 Demo: Alerts and Action Groups
  • 3.6 Integrate Governance and Monitoring with Compliance and Incident Response
• Appendix: Custom Role Definition — GloboReader
• Appendix: KQL Queries for Storage Blob Logs
• Reference Links

Module 1: Designing Identity for Azure Solutions

1.1 Authentication Using Microsoft Entra ID Identities

Overview

Microsoft Entra ID is a cloud-based Identity and Access Management (IAM) service. It was formerly called Azure Active Directory (Azure AD). When studying for AZ-305 or working with Azure, keep in mind that Azure Active Directory is now called Microsoft Entra ID — they are the same service.

You can use Microsoft Entra ID identities to authenticate users and workloads.

Authentication vs. Authorization

When a user or workload needs to access an Azure resource, two sequential steps must occur:

1. Authentication — Verifies who a user or workload is (proves identity).
2. Authorization — Determines what the authenticated identity is allowed to do (e.g., read-only vs. read/write access).

sequenceDiagram
    participant User
    participant EntraID as Microsoft Entra ID
    participant Resource as Azure Resource

    User->>EntraID: Provide credentials
    EntraID-->>User: Identity verified (Authentication)
    User->>Resource: Request access
    Resource->>EntraID: Check RBAC assignment
    EntraID-->>Resource: Authorization decision
    Resource-->>User: Access granted or denied

Credential-Based vs. Identity-Based Access Control

Azure resources support two access control options:

Credential-based examples:

• Azure SQL: Username and password combination to access a SQL database.
• Storage Account access key: Grants full access to the storage account.
• Storage Account SAS token: Grants scoped/limited access to a storage data service.
• Cosmos DB access key: Read and write into a Cosmos DB database.
• Azure Event Hubs access key: Send or receive events from Event Hubs.
• Azure IoT Hub Shared Access Policy: Send IoT Hub telemetry to the IoT Hub.

Identity-based examples (using Entra ID):

• Entra ID app registration or enterprise applications.
• User-assigned or system-assigned managed identities.
• Assign an RBAC role to the identity to authorize it to use the Azure resource.

Microsoft’s recommendation: Use identity-based access control whenever possible. This eliminates the need to safekeep storage account keys, database passwords, and tokens — all you need is an identity, which is more secure.

Types of Entra ID Identities

When to use which identity type:

• Granting access to humans: Use Entra ID users and groups.
• Granting access to workloads (e.g., an Azure Function App reading from Cosmos DB): Use service principals — specifically app registrations, enterprise apps, or managed identities.

Managed Identities

Managed identities eliminate the manual overhead of creating and maintaining app registrations. There are two types:

graph TD
    A[Azure App Service] -->|system-assigned identity| B[Entra ID]
    B -->|RBAC: Storage Blob Data Contributor| C[Azure Storage Account]
    D[User-assigned Managed Identity] -->|assigned to multiple resources| E[Azure Function App]
    D -->|assigned to multiple resources| F[Azure VM]
    D -->|RBAC role assignment| C

1.2 Demo: Creating Identities in Microsoft Entra ID

This section walks through creating users, groups, app registrations, and managed identities in the Azure portal.

Creating a User

1. In the Azure portal, navigate to All services → search for Entra → click Microsoft Entra ID.
2. Under Manage, click Users.
3. Click + New user → fill in the display name (e.g., Peter Smith).
4. Allow Entra ID to auto-generate a password.
5. The account is enabled by default; you can enable or disable it as needed.
6. Click Review + create → Create.

Creating a Group

1. In Entra ID, under Manage, click Groups → All groups.
2. Click + New group.
3. Set Group type to Security (this type allows permission assignment to Azure resources — Microsoft 365 groups are for collaboration like Teams, email, and SharePoint).
4. Enter a group name (e.g., Developers) and optional description.
5. Set an owner and optionally add members.
6. Click Create.

To add a member (e.g., Peter Smith) to the Developers group: Click Developers → Manage → Members → Add member → search for the user → Select.

Creating an App Registration (Service Principal)

1. In Entra ID, under Manage, click App registrations.
2. Click + New registration → enter a name (e.g., PhotoAlbumApp) → click Register.
3. Note the following important values:
   • Application (client) ID
   • Directory (tenant) ID
   • Client secret or certificate
4. To create a client secret: click Certificates & secrets → + New client secret → provide a description → choose an expiry date → Add.

Important: Copy the secret value immediately after creation — it will not be shown again. Choose a short expiry date for production resources to reduce risk.

Enabling Managed Identity for an Azure Resource

App registrations require manual management. The recommended approach is managed identities.

Example: Enable managed identity for an App Service so it can access a Storage Account.

1. In the Azure portal, navigate to your App Service.
2. Under Settings, click Identity.
3. Under the System assigned tab, toggle the status to On → Save.
4. The App Service now has a system-assigned managed identity that can be given RBAC role assignments.

User-assigned managed identity benefit: Create one identity, grant it permissions, then assign it to multiple resources — no need to configure each resource separately.

1.3 Authorization with RBAC

What is RBAC?

Role-Based Access Control (RBAC) is the authorization system in Microsoft Azure. It enables you to grant fine-grained access to Azure resources.

Authorization answers two questions:

1. Which resources does the identity have access to? (e.g., a Blob Storage account or the whole subscription)
2. What actions can the identity perform? (e.g., read, write, delete)

RBAC Examples

RBAC Role Assignment Components

To configure authorization, you create an RBAC role assignment consisting of three elements:

graph LR
    A[Assignee<br/>Who: user, group, managed identity] --> D[Role Assignment]
    B[Role<br/>What: Reader, Contributor, custom role] --> D
    C[Scope<br/>Where: management group, subscription, resource group, resource] --> D

Built-in RBAC Roles

Microsoft provides many built-in roles. Key ones include:

General roles:

Resource-specific roles (examples):

Best practice: Use resource-specific RBAC roles whenever possible rather than general roles.

RBAC Scope Hierarchy

RBAC assignments follow a hierarchy. Permissions granted at a higher scope are inherited by child scopes:

graph TD
    MG[Management Group<br/>broadest scope] --> SUB[Subscription]
    SUB --> RG[Resource Group]
    RG --> R[Individual Resource<br/>narrowest scope]

Best practice: Assign access at the lowest scope possible — this is the principle of least privilege.

Custom RBAC Roles

If built-in roles do not satisfy your requirements, you can create a custom RBAC role. You can clone an existing built-in role and modify the permissions.

A custom role definition contains:

• actions: Management operations the role can perform (e.g., */read).
• notActions: Management operations excluded from the allowed actions.
• dataActions: Data operations within a resource (e.g., reading blob data).
• notDataActions: Data operations excluded from the allowed data actions.
• assignableScopes: Subscriptions or management groups where this role can be assigned.

1.4 Demo: Authorization with RBAC

Assigning a Role to a User (Subscription Scope)

Goal: Give user Peter Smith Reader access to the entire subscription.

1. In the Azure portal, navigate to Subscriptions → click your subscription.
2. Click Access control (IAM) → + Add → Add role assignment.
3. Under the Role tab, select Reader → click Next.
4. Under the Members tab, click + Select members → search for Peter → click Select.
5. Click Review + assign → Assign.
6. Confirm under Role assignments that Peter has the Reader role.

Peter can now log in and view all resources in the subscription.

Assigning a Role to a Group (Resource Scope)

Goal: Give the Developers group Contributor access to a specific App Service (not the whole resource group).

1. Navigate to the App Service → Access control (IAM) → + Add → Add role assignment.
2. Select the Contributor role → click Next.
3. Click + Select members → search for Developers (the group) → click Select.
4. Click Review + assign.

Now all members of the Developers group (including Peter) have Contributor access to that specific web application.

Assigning a Role to a Managed Identity (Workload Authorization)

Goal: Allow an App Service (with managed identity enabled) to read and write blobs in a Storage Account.

Why not use a storage access key? If someone compromises the access key, they have full access to the storage account. Identity-based access is more secure.

1. Navigate to the Storage Account → Access control (IAM) → + Add → Add role assignment.
2. Search for and select Storage Blob Data Contributor (resource-specific role).
3. Click Next → + Select members → search for the App Service name (it appears because managed identity is enabled) → Select.
4. Click Review + assign.

The App Service now has secure, identity-based access to the Storage Account without using access keys or SAS tokens.

1.5 Demo: Custom RBAC Roles

Scenario: Create a custom role called GloboReader that has Reader permissions across all resources but also has read/write access to Blob Storage data.

Steps to Create a Custom Role

1. Navigate to Subscriptions → your subscription → Access control (IAM) → Roles tab.
2. Find the Reader built-in role → click on it → Clone to start from the Reader definition.
3. Name the new role (e.g., GloboReader).
4. Click Next → Edit to modify the JSON definition.
5. Add the necessary actions and dataActions from the Storage Blob Data Contributor role.
6. Click Save → Review + create → Create.

The new custom role now appears in the roles list and can be assigned to users, groups, or managed identities.

Custom Role JSON Definition Example

The following is the complete JSON definition for a GloboReader custom role — it combines Reader permissions with Blob Storage read/write data access:

{
    "id": "/subscriptions/<subscription-id>/providers/Microsoft.Authorization/roleDefinitions/<role-definition-id>",
    "properties": {
        "roleName": "GloboReader",
        "description": "this role has Reader permissions plus blob read/write data",
        "assignableScopes": [
            "/subscriptions/<subscription-id>"
        ],
        "permissions": [
            {
                "actions": [
                    "*/read",
                    "Microsoft.Storage/storageAccounts/blobServices/containers/delete",
                    "Microsoft.Storage/storageAccounts/blobServices/containers/write",
                    "Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey/action"
                ],
                "notActions": [],
                "dataActions": [
                    "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete",
                    "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read",
                    "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write",
                    "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/move/action",
                    "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action"
                ],
                "notDataActions": []
            }
        ]
    }
}

Key fields explained:

• actions: Management plane permissions. */read grants read access to all Azure resource types.
• notActions: Exclusions from the actions list.
• dataActions: Data plane permissions — grants the ability to read, write, delete, and move blob objects inside containers.
• notDataActions: Exclusions from the dataActions list.
• assignableScopes: Limits where this role definition can be assigned (here: a specific subscription).

1.6 Identity Best Practices

As a Cloud Architect, you are responsible for designing and implementing identity best practices for Azure resources.

Authentication Best Practices

Microsoft Entra Conditional Access

Conditional Access is a premium feature of Microsoft Entra ID (requires a premium license). Policies are enforced after the user has completed the first-factor authentication (e.g., entered their username and password).

Conditional Access policies allow you to allow or block access based on conditions:

flowchart TD
    A[User enters username and password] --> B{First-factor auth successful?}
    B -- No --> Z[Access Denied]
    B -- Yes --> C{Conditional Access Policy Check}
    C -- Compliant --> D[Access Granted]
    C -- Non-compliant --> E{Policy Action}
    E -- Require MFA --> F[MFA Challenge]
    F -- Pass --> D
    F -- Fail --> Z
    E -- Block --> Z

Privileged Identity Management (PIM)

PIM is a premium Entra ID feature that provides just-in-time (JIT) access to RBAC roles. The access is removed after an expiry date.

Example workflow:

1. Reza is configured as eligible for the Contributor role on the subscription.
2. When Reza needs the Contributor role, he requests activation.
3. An administrator reviews and approves Reza’s request.
4. Reza receives the assignment and becomes a Contributor.
5. The role assignment expires after 4 hours (this time is configurable).

Why PIM matters: If someone compromises Reza’s account on a weekend, they cannot use the Contributor permission because the role is not permanently assigned — it must be actively requested and approved.

PIM Capabilities:

sequenceDiagram
    participant User as Reza (Eligible)
    participant PIM as PIM / Entra ID
    participant Admin as Administrator

    User->>PIM: Request role activation (Contributor)
    PIM->>Admin: Approval notification
    Admin->>PIM: Approve request
    PIM-->>User: Role activated (e.g., 4-hour window)
    Note over User,PIM: Role expires automatically after 4 hours

Authorization Best Practices

1.7 Demo: Identity Best Practice Tools in the Azure Portal

Identity Governance Features

In the Azure portal, navigate to Entra ID → Manage → Identity Governance to access:

• Access Reviews: Set up automatic, scheduled access reviews for users with elevated permissions. Example: If Peter is an administrator, schedule a review every 6 months — if the reviewer confirms Peter no longer needs access, it is automatically revoked.
• Privileged Identity Management (PIM): Configure time-limited role assignments with approval workflows.
• Conditional Access: Define security policies to allow or block user access based on compliance with conditions.

Microsoft Entra Admin Center

The Microsoft Entra Admin Center (entra.microsoft.com) provides centralized access to all aspects of Entra ID, including:

• Enterprise apps → Conditional Access policy definitions
• Users and Groups → PIM and access review configuration
• App registrations → Manage service principal identities
• Roles and administrators → Manage role assignments
• Authentication methods → Configure MFA, SMS authentication, Microsoft Authenticator
• Monitoring and health → Sign-in logs, audit logs, and other investigation logs

Licensing note: Conditional Access and PIM are premium Entra ID features. You need Microsoft Entra ID Premium P1 (for Conditional Access) or Premium P2 (for PIM and access reviews) licenses to use these features.

Module 2: Designing Governance for Azure Solutions

2.1 Governing Azure Workloads

Why Governance Matters

Azure governance enables you to control how resources are created and managed. This helps you comply with government, industry, and security standards.

Industry and Government Standards

Azure Well-Architected Framework

Microsoft Azure bundles best practices and recommendations into the Azure Well-Architected Framework, which has 5 pillars:

graph TD
    WAF[Azure Well-Architected Framework] --> R[Reliability<br/>Ensure solution is accessible and reliable]
    WAF --> S[Security<br/>Ensure solution is secure]
    WAF --> CO[Cost Optimization<br/>Optimize spending]
    WAF --> OE[Operational Excellence<br/>Follow operational best practices]
    WAF --> PE[Performance Efficiency<br/>Scale efficiently to meet demand]

Azure Policy

Azure Policy is the enforcement tool for Azure governance. At scale — with tens, hundreds, or thousands of resources — you can govern all resources with a few clicks.

Azure Policy Definition Examples:

Policy Components

graph LR
    D[Policy Definition<br/>What rule to enforce] --> PA[Policy Assignment]
    S[Scope<br/>Where to enforce] --> PA
    P[Parameters<br/>Configuration values] --> PA
    E[Effect<br/>What action to take] --> PA

Policy Definition: The rule itself. Microsoft provides hundreds of built-in definitions. You can also create custom ones.

Scope: The resources the policy governs:

• Management group (governs all child subscriptions and their resources)
• Subscription (governs all child resource groups and resources)
• Resource group
• You can create exclusions/exemptions for a subset of resources within a scope.

Policy Effects:

Not all effects are supported by every policy — check each policy definition for its supported effects.

Important: A policy assignment only affects deployments made after the policy is assigned. Existing non-compliant resources continue to exist but will reduce your overall compliance score.

2.2 Demo: Azure Policy — Enforcing Data Residency

Scenario: Globomantics company needs all Azure resources deployed within Canada (Canada Central and Canada East). Resources outside Canada are not allowed.

Steps

1. In the Azure portal, navigate to Policy (search “policy” in All services).
2. Click Authoring → Definitions to browse available built-in and custom policies.
3. Search for “location” → select Allowed locations.
4. Click Assign.
5. Set the Scope to the entire subscription (or limit to a resource group if needed).
6. Click Next → Under Parameters, select the allowed locations: Canada Central and Canada East.
7. Click Next → Review + create → Create.

Testing the Policy

1. Navigate to Storage accounts → + Create.
2. Select a region outside Canada (e.g., Japan East).
3. The portal immediately shows a policy violation: Allowed locations — the resource deployment is blocked.

This works because the Allowed locations policy uses the Deny effect.

Key Takeaway

The policy does not delete resources that were deployed before the policy was assigned. Those resources remain but reduce the overall compliance score. Only new deployments are blocked.

2.3 Using Policy Initiatives to Comply with Industry Standards

What is a Policy Initiative?

A policy initiative (also called a policy set) is a bundle of multiple policy definitions grouped together for easier assignment. Rather than assigning tens or hundreds of individual policies, you assign one initiative.

Pre-Built Initiatives

Microsoft provides pre-built initiatives for common compliance standards:

If no built-in initiative matches your need, you can create a custom initiative.

Initiative Scope

Initiative scopes follow the same hierarchy as policy scopes:

• Management group (recommended for organization-wide standards)
• Subscription
• Resource group

In practice, you typically assign initiatives to a subscription or parent management group to ensure all resources are covered.

The Compliance Requirement

Critical point: Assigning an initiative is not enough to claim compliance. After assigning the initiative:

1. Wait for Azure Policy to evaluate all resources (typically up to 24 hours).
2. Navigate to the compliance dashboard.
3. You must achieve a 100% compliance score before claiming compliance to that standard.

flowchart LR
    A[Assign Initiative] --> B[Wait for Policy Evaluation]
    B --> C{Compliance Score?}
    C -- Less than 100% --> D[Fix non-compliant resources]
    D --> B
    C -- 100% --> E[Compliance Claimed]
    E --> F[Present to Auditors for Certification]

2.4 Demo: Azure Policy Initiative — PCI-DSS Compliance

Scenario: Globomantics is handling customer financial information (credit card numbers, bank account information) and must become PCI DSS compliant.

Steps

1. In the Azure portal, navigate to Policy → Authoring → Definitions.
2. Search for “PCI” — three options appear: PCI DSS v4, v4.0.1, and v3.2.
3. Select PCI DSS v4.0.1 → click Assign.
4. Set the Scope to the subscription.
5. Click Next → Review and fill in required parameters (varies by initiative type).
6. Optionally set a custom non-compliance message.
7. Click Create.

Reviewing Compliance

1. Navigate to Policy → Compliance.
2. Find PCI DSS v4 in the list.
3. The compliance score shows the percentage of compliant resources.
4. Click the initiative to see:
   • Which resources are non-compliant.
   • The reason for non-compliance.
   • Remediation suggestions.

Example: The PCI DSS v4.0.1 initiative consists of 213 individual policies covering resources such as Cosmos DB, Azure AI Services, Storage Accounts, and more. If a service is not present in the subscription, that policy is skipped.

Disclaimer: A 100% compliance score on the initiative does not automatically mean you are PCI certified. You still need to engage auditors, present the initiative and compliance score, and go through the official certification process.

2.5 Balancing Compliance and Agility

As a Cloud Architect, you must find the right balance between compliance and development agility.

The Trade-off

graph LR
    A[Strong Enforcement<br/>More policies, stricter rules] -->|Results in| B[Higher Compliance Score]
    A -->|Results in| C[Lower Development Agility<br/>More guardrails for developers]
    D[Weak Enforcement<br/>Fewer policies, loose rules] -->|Results in| E[Lower Compliance Score]
    D -->|Results in| F[Higher Development Agility<br/>Developers move faster]

Recommendations for Balancing Compliance and Agility

1. Create separate subscriptions or resource groups for each environment (dev, test, pre-prod, prod). This lets you assign different policies per environment.
2. Minimize restrictive policies in early development phases so the team can quickly set up the project.
3. Use policy exemptions to ease guardrails for development environments or edge cases — but ensure exemptions have expiry dates where applicable.

2.6 Demo: Balancing Compliance and Agility with Scopes and Exemptions

Scenario: A policy requiring a createdBy tag on all resources is assigned to the subscription. The dev resource group is exempted so developers can work freely without tagging every resource.

Assigning a Tag Policy

1. Navigate to Policy → Authoring → Definitions.
2. Search for “Require a tag on resources” → select it (effect: Deny).
3. Click Assign → set Scope to the subscription.
4. Under Parameters, enter the tag name: createdBy.
5. Click Review + create → Create.

Creating a Policy Exemption for the Dev Resource Group

1. Navigate to Policy → Assignments → find the tag policy assignment.
2. Click Create exemption.
3. Under Exemption scope, select the dev resource group → click Select.
4. Enter a descriptive name (e.g., Do not require a tag on dev resources).
5. Set the Exemption category:
   • Waiver: Accepting the risk.
   • Mitigated: You have already addressed the risk through other means.
6. Optionally set an expiration date for the exemption.
7. Click Create.

Result

• Production resource group: Creating a storage account without a createdBy tag is blocked by the policy.
• Dev resource group: Creating a storage account without a createdBy tag is allowed — the exemption bypasses the policy effect.

Architect’s note: The decision on which policies to exempt in which environments is yours to make based on your project, organization, and jurisdiction. The goal is to enable development speed while protecting production data.

Module 3: Designing Incident Response and Monitoring for Azure Solutions

3.1 Monitoring Azure Resources

Why Monitor?

Effective monitoring of Azure resources provides:

• Early detection of anomalies and issues, often before end users notice them.
• Faster issue resolution thanks to detailed, high-quality logs.
• Proactive optimization by detecting misconfigurations before they become problems.
• Visibility into system performance, security posture, and cost.

Azure Monitor Overview

Azure Monitor is a comprehensive group of services for collecting monitoring data from Azure and on-premises environments. Using Azure Monitor services, you can collect:

• Metrics — Numerical time-series data (e.g., CPU percentage, request count)
• Logs — Structured records of events
• Diagnostics — Detailed resource diagnostic information
• Activity logs — Who did what, when, on which Azure resource
• Telemetry — Application-level data from applications and operating systems

graph TD
    R1[Azure Resources] --> AM[Azure Monitor]
    R2[Applications] --> AM
    R3[Operating Systems] --> AM
    R4[On-premises Resources] --> AM

    AM --> LAW[Log Analytics Workspace<br/>Query and analyze]
    AM --> SA[Storage Account<br/>Long-term retention / archival]
    AM --> EH[Event Hubs<br/>Real-time event processing]

Log Destinations

You configure where logs are sent using Diagnostic Settings — a per-resource configuration that defines what logs and metrics are sent to which destination(s).

A single resource can be configured to send logs to multiple destinations simultaneously.

3.2 Monitoring Azure Infrastructure Using Log Analytics Workspace

What is Log Analytics Workspace?

Azure Log Analytics Workspace is the most common destination for Azure Monitor logs. Think of it as a database for logs. Multiple Azure resources across a subscription can send their logs to a single workspace.

graph TD
    WA[Web Application] -->|Diagnostic Settings| LAW[Log Analytics Workspace]
    VM[Virtual Machine] -->|Diagnostic Settings| LAW
    SA[Storage Account] -->|Diagnostic Settings| LAW
    CDB[Cosmos DB] -->|Diagnostic Settings| LAW

    LAW --> T1[Table: AppTraces]
    LAW --> T2[Table: StorageBlobLogs]
    LAW --> T3[Table: AzureMetrics]
    LAW --> T4[Table: AzureActivity]

Key points:

• Multiple resources can send logs to a single Log Analytics Workspace.
• Logs from different resources may go into the same or different tables within the workspace.
• Consult resource documentation to find which tables contain the logs you need.

Architecture Best Practices for Log Analytics

Cost Considerations

Log Analytics Workspace is not free. Costs are incurred for:

• Data ingestion — the volume of logs ingested per day.
• Data retention — how long logs are stored.

Cost optimization strategies:

• Set a daily cap for non-production workspaces (e.g., 1 GB/day).
• Adjust retention periods — default is 30 days; logs are auto-deleted afterward.
• Export logs to Azure Storage Account (cool/cold/archive tiers) for long-term, cheaper storage.
• Configure retention at the table level for granular control.

3.3 Demo: Log Analytics Workspace

Creating a Log Analytics Workspace

1. In the Azure portal, navigate to All services → search for “log analytics” → click Log Analytics Workspace.
2. Click + Create.
3. Select a resource group, enter a name, choose a region.
4. Click Review + create → Create.

Configuring Diagnostic Settings on a Storage Account

1. Navigate to Storage accounts → select a storage account.
2. Under Monitoring, click Diagnostic settings.
3. Click on the blob service diagnostic settings.
4. Click + Add diagnostic setting.
5. Select the logs you want to send (e.g., StorageLogs, Transaction logs).
6. Check Send to Log Analytics workspace → select your workspace.
7. Click Save.

You can create multiple diagnostic settings on a single resource to send different logs to different destinations (e.g., one to Log Analytics for querying, another to a storage account for archival).

Querying Logs with KQL

Navigate to your Log Analytics Workspace → Logs to run KQL queries.

Query 1: List distinct operations performed on the Storage Account

StorageBlobLogs
| distinct OperationName

Sample results: ListContainers, ListBlobs, PutBlob, GetBlob

Query 2: List all new blob uploads in the last 24 hours

StorageBlobLogs
| where OperationName == 'PutBlob'

Query 3: Get details for blob uploads (IP, file name, auth type)

StorageBlobLogs
| project CallerIpAddress, ObjectKey, AuthenticationType, Category, _ResourceId, OperationName
| where OperationName == 'PutBlob'

Query 4: Find the most common errors in the last 3 days

// Most common errors
// List 10 most common errors over the last 3 days.
StorageBlobLogs
| where TimeGenerated > ago(3d) and StatusText !contains "Success"
| summarize count() by StatusText
| top 10 by count_ desc

Workspace scope vs. resource scope: Running a query directly from a storage account shows logs only for that resource. Running the same query from the Log Analytics Workspace shows logs from all resources sending data to that workspace.

Managing Costs in Log Analytics

1. In your Log Analytics Workspace, click Usage and estimated costs.
2. Set a daily cap: Click Daily cap → configure a maximum ingestion limit (e.g., 1 GB/day). Logs beyond the cap for that day will not be ingested. Do not use this for production workspaces.
3. Change retention period: Click Data Retention → modify the global retention (default: 30 days).
4. Table-level retention: Under Tables, configure retention independently per table.

3.4 Demo: Monitoring Applications with Application Insights

What is Application Insights?

Application Insights is a member of the Azure Monitor Insights family. It uses Azure Monitor Logs plus custom telemetry from your application to monitor the availability, performance, and usage of cloud or on-premises applications.

Other members of the Azure Monitor Insights family:

• Azure VM Insights
• Azure Container Insights
• Network Insights
• Storage Insights
• Cosmos DB Insights
• Key Vault Insights
• Data Explorer Insights

graph TD
    AM[Azure Monitor] --> Insights[Azure Monitor Insights]
    Insights --> AI[Application Insights<br/>App availability, perf, usage]
    Insights --> VMI[VM Insights<br/>VM performance and health]
    Insights --> CI[Container Insights<br/>AKS and containers]
    Insights --> NI[Network Insights<br/>Network performance]
    Insights --> SI[Storage Insights]
    Insights --> KVI[Key Vault Insights]

Application Insights Capabilities

Supported frameworks and platforms:

• .NET / ASP.NET Core
• Java
• Python
• Node.js
• Azure Kubernetes Service (AKS)
• API Management

Cost Optimization for Application Insights

Similar to Log Analytics Workspace, Application Insights charges for data ingestion and storage. Strategies to reduce cost:

• Enable data sampling: Reduces the volume of telemetry sent from the Application Insights SDK to the service (statistically representative subset rather than all events).
• Set data volume caps: Limit ingestion for non-production environments.

Using Application Insights in the Azure Portal

1. Navigate to your App Service → under Monitoring, click Application Insights.
2. Enable the integration — this creates a new Application Insights resource linked to the web app.
3. Click the Application Insights resource to access the dashboard.

Dashboard overview:

• Failed requests — count of HTTP 5xx/4xx errors.
• Server response time — average latency.
• Server requests — total request volume.
• Application availability — uptime percentage from availability tests.

Investigation features:

3.5 Demo: Alerts and Action Groups

What are Azure Monitor Alerts?

Alerts are triggered when something goes wrong with your Azure resources or hosted applications. Alerts enable you to detect and respond to issues proactively.

You can create alert rules for:

• Metrics — e.g., if average CPU on an App Service in the last 5 minutes exceeds 65%.
• Logs — e.g., if a KQL query returns at least one row (indicating an anomaly).

Action Groups

When an alert triggers, you can respond using an Action Group — a collection of actions to perform. Common action types:

Example automated response: If a CPU high alert fires for your cluster, a Logic App can automatically add a new instance to scale out.

Alert fatigue warning: Receiving tens or hundreds of alerts per day causes operators to ignore them. Tune your alert rules carefully to reduce noise and focus on meaningful events.

flowchart TD
    R[Azure Resource / Application] -->|Metric or Log event| AR[Alert Rule]
    AR -->|Condition met| A[Alert Triggered]
    A --> AG[Action Group]
    AG --> E[Email/SMS to Admin]
    AG --> WH[Webhook call]
    AG --> FA[Azure Function<br/>Custom automation]
    AG --> LA[Logic App<br/>Orchestrated workflow]
    AG --> RB[Automation Runbook]
    AG --> IT[ITSM Ticket]

Creating an Alert Rule for HTTP Server Errors

Goal: Receive an email whenever an App Service reports an HTTP 500 server error.

1. Navigate to your App Service → under Monitoring, click Metrics.
2. Select the metric HTTP Server Errors.
3. Click New alert rule.
4. Configure the condition:
   • Aggregation type: Total
   • Operator: Greater than or equal to
   • Threshold value: 1
   • Check every: 5 minutes
   • Lookback period: 5 minutes
5. Click Actions → + Create action group.
6. Enter the action group name (e.g., email-admin) and select the resource group.
7. Under Notifications tab: select Email/SMS message/Push/Voice → enter the administrator’s email address.
8. Optionally configure Actions (Azure Function, Runbook, ITSM ticket, etc.).
9. Click Create for the action group.
10. Back in the alert rule, set the Severity (e.g., Error = Sev 2).
11. Click Review + create → Create.

From this point on, every time the App Service throws an HTTP 500 error, the administrator receives an email alert within ~5 minutes.

3.6 Integrate Governance and Monitoring with Compliance and Incident Response

Monitoring Best Practices

Microsoft Sentinel

Microsoft Sentinel is an Azure-native SIEM (Security Information and Event Management) and SOAR (Security Orchestration, Automation, and Response) solution. It uses AI to provide threat detection, investigation, and automated response.

Microsoft has integrated Microsoft Sentinel with Microsoft Defender XDR. Sentinel features are accessible through the Microsoft Defender portal.

graph TD
    subgraph DataSources [Data Sources]
        M365[Microsoft 365]
        EID[Entra ID]
        ASC[Azure Security Center]
        MDF[Microsoft Defender]
        SAAS[SaaS Apps: SAP, Okta, ServiceNow]
        WL[Windows / Linux Machines]
        FW[Firewalls: Palo Alto, Cisco, Fortinet, CheckPoint]
        AWS[AWS / Google Cloud]
        API[Custom: REST APIs, syslog]
    end

    LAW[Log Analytics Workspace] --> Sentinel[Microsoft Sentinel]
    DataSources --> Sentinel

    Sentinel --> SIEM[SIEM: Centralized log analytics<br/>Threat detection]
    Sentinel --> SOAR[SOAR: Automated threat response]
    Sentinel --> Hunt[Threat Hunting:<br/>KQL, Workbooks, Jupyter Notebooks]
    Sentinel --> AI[AI-Powered Threat Intelligence:<br/>Anomaly detection, advanced threats]

Microsoft Sentinel Capabilities:

Sentinel Data Sources:

Architecture note: Microsoft Sentinel sits on top of Log Analytics Workspace to access Azure platform logs, and extends ingestion further through data connectors for non-Azure sources.

graph TD
    AzureResources[Azure Resources] -->|Diagnostic Settings| LAW[Log Analytics Workspace]
    ExternalSources[External Sources<br/>M365, Firewalls, SaaS, AWS] -->|Data Connectors| Sentinel[Microsoft Sentinel]
    LAW -->|Foundation| Sentinel
    Sentinel -->|Threat Detected| Playbook[Automated Playbook / SOAR]
    Playbook --> Block[Block IP / Disable Account]
    Playbook --> Notify[Notify Security Team]
    Playbook --> Ticket[Create Incident Ticket]

Appendix: Custom Role Definition — GloboReader

The following is the complete custom RBAC role JSON definition used in the demos. This role grants Reader access across all resources plus read/write/delete access to Azure Blob Storage data:

{
    "id": "/subscriptions/<subscription-id>/providers/Microsoft.Authorization/roleDefinitions/<role-definition-id>",
    "properties": {
        "roleName": "GloboReader",
        "description": "this role has Reader permissions plus blob read/write data",
        "assignableScopes": [
            "/subscriptions/<subscription-id>"
        ],
        "permissions": [
            {
                "actions": [
                    "*/read",
                    "Microsoft.Storage/storageAccounts/blobServices/containers/delete",
                    "Microsoft.Storage/storageAccounts/blobServices/containers/write",
                    "Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey/action"
                ],
                "notActions": [],
                "dataActions": [
                    "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete",
                    "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read",
                    "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write",
                    "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/move/action",
                    "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action"
                ],
                "notDataActions": []
            }
        ]
    }
}

How to apply this role definition using Azure CLI:

az role definition create --role-definition @GloboReader.json

How to assign this custom role to a user:

az role assignment create \
  --role "GloboReader" \
  --assignee "peter@yourtenant.onmicrosoft.com" \
  --scope "/subscriptions/<subscription-id>"

Appendix: KQL Queries for Storage Blob Logs

The following KQL (Kusto Query Language) queries can be used in Log Analytics Workspace to investigate Azure Blob Storage activity.

List all distinct operation names on the storage account:

StorageBlobLogs
| distinct OperationName

List all blob upload (PutBlob) operations:

StorageBlobLogs
| where OperationName == 'PutBlob'

Get details for blob uploads (IP address, file name, authentication type):

StorageBlobLogs
| project CallerIpAddress, ObjectKey, AuthenticationType, Category, _ResourceId, OperationName
| where OperationName == 'PutBlob'

Find the 10 most common errors in the last 3 days:

// Most common errors
// List 10 most common errors over the last 3 days.
StorageBlobLogs
| where TimeGenerated > ago(3d) and StatusText !contains "Success"
| summarize count() by StatusText
| top 10 by count_ desc

Reference Links

Identity and Access Management

Governance

Monitoring and Incident Response

Search Terms

az-305 · identity · governance · monitoring · azure · architect · microsoft · policy · rbac · compliance · log · role · analytics · application · authorization · custom · entra · insights · assigning · identities · scope · workspace · access · agility