The AWS Learning Roadmap follows a sensible progression: learn cloud fundamentals, identity, networking and compute first; then add storage, databases, containers, serverless and operational services. This Azure roadmap follows the same learning philosophy but expands it into an enterprise-grade programme covering cloud architecture, application delivery, AI engineering, cybersecurity, Responsible AI, regulatory compliance and operating-model design.

Terminology note: Microsoft’s current documentation refers to its unified enterprise AI development platform as Microsoft Foundry. You may still encounter the previous “Azure AI Foundry” name in existing projects, articles and interfaces. Microsoft Foundry brings together models, agents, development tooling and production AI operations as an Azure platform service. (Microsoft Learn)

The condensed Azure Learning Roadmap covers stages from cloud fundamentals through the governed AI capstone. This article is the full implementation guide.

1. How to use this roadmap

Do not try to memorise every Azure service.

For each stage, follow this cycle:

1. Understand the business requirement.
2. Learn the service concepts.
3. Create a small version manually.
4. Deploy it using Azure CLI.
5. Recreate it using Bicep or Terraform.
6. Secure it using identity, networking and encryption.
7. Add monitoring, recovery and cost controls.
8. Document the architectural decisions.
9. Assess it against the Azure Well-Architected Framework.
10. Demonstrate the system to a technical and non-technical audience.

The aim is not to become someone who recognises Azure product names. The aim is to become someone who can turn an ambiguous business requirement into a secure, scalable, governed and commercially viable Azure solution.

2. Complete roadmap at a glance

3. AWS-to-Azure service mapping

This is not a perfect one-to-one mapping, but it provides a practical mental model.

Azure Container Apps provides serverless container hosting and event-driven scaling, while AKS provides managed Kubernetes. Azure Functions provides event-driven serverless compute; Azure API Management provides managed API and AI gateway capabilities; and Azure Monitor provides the central monitoring platform. (Microsoft Learn)

Part One: Azure and Cloud Foundations

4. Understand cloud computing​

Before learning Azure services, understand the delivery models.

Infrastructure as a Service​

You manage:

• Operating systems.
• Applications.
• Runtime configuration.
• Patching of guest systems.
• Network configuration.
• Identity permissions.
• Data.

Azure manages the physical infrastructure.

Examples:

• Azure Virtual Machines.
• Managed Disks.
• Virtual Networks.
• Azure Load Balancer.

Platform as a Service​

Azure manages more of the operating system and platform.

Examples:

• Azure App Service.
• Azure SQL Database.
• Azure Functions.
• Azure Container Apps.
• Microsoft Foundry.

You remain responsible for:

• Application code.
• Identities and permissions.
• Data.
• Configuration.
• Business logic.
• Security decisions.
• Compliance.

Software as a Service​

A complete application is supplied to users.

Examples include Microsoft 365, Dynamics 365 and other hosted business applications.

The shared-responsibility boundary changes according to whether the service is IaaS, PaaS or SaaS, but customers remain responsible for their data, identities, access decisions and the cloud components they configure. (Microsoft Learn)

5. Understand Azure global infrastructure​

Regions​

An Azure Region is a geographic area containing one or more datacentres.

Region selection should consider:

• Customer location.
• Data residency.
• Regulatory requirements.
• Service availability.
• Latency.
• Cost.
• Availability Zone support.
• Disaster-recovery options.
• Model availability for AI workloads.
• Capacity and quota availability.

Availability Zones​

Availability Zones are separated groups of datacentres within a Region. Not every service or Region supports the same zoning model, so availability must be verified before finalising an architecture. (Microsoft Learn)

Region pairs and multi-region architecture​

Some Azure Regions have paired-region relationships, while others do not. Do not assume that a paired Region automatically provides application disaster recovery. You must configure replication, traffic routing, backups and recovery procedures for the services you use. (Microsoft Learn)

Practical exercise​

Create a Region-selection decision record containing:

Part Two: Azure Resource Organisation and Landing Zones

6. Understand the Azure resource hierarchy​

A common Azure hierarchy is:

Tenant​

The Microsoft Entra tenant is the primary identity and directory boundary.

Management group​

Management groups provide a scope above subscriptions. Policies and role assignments applied at a management-group level can be inherited by subscriptions underneath it. (Microsoft Learn)

Subscription​

A subscription provides:

• Billing scope.
• Quota boundary.
• Access-management scope.
• Deployment boundary.
• Policy scope.
• Resource organisation boundary.

Separate subscriptions can be used for:

• Production.
• Development.
• Security.
• Connectivity.
• Shared services.
• AI experimentation.
• Regulated workloads.
• Business units.

Resource group​

A resource group is a logical container for related Azure resources.

A resource group should usually represent a workload or meaningful lifecycle boundary—not simply a random collection of resources.

Resource​

A resource is an individual Azure service instance, such as:

• Virtual network.
• Storage account.
• Key Vault.
• Container App.
• SQL database.
• Foundry resource.

Azure Resource Manager is the management and deployment layer through which Azure resources are created and controlled. (Microsoft Learn)

7. Build an Azure landing zone​

An Azure landing zone is the governed foundation into which workloads are deployed.

Microsoft currently describes an Azure landing-zone environment as one platform landing zone and one or more application landing zones. The platform area commonly provides central identity, connectivity, management and policy capabilities, while application landing zones host individual workloads. (Microsoft Learn)

Landing-zone design areas​

Your landing-zone design should cover:

1. Tenant and management-group organisation.
2. Subscription strategy.
3. Identity and access.
4. Network topology and connectivity.
5. Security.
6. Management and monitoring.
7. Governance.
8. Platform automation.
9. Business continuity.
10. Cost management.

Platform landing zone​

A platform landing zone commonly contains:

• Hub networking.
• Azure Firewall.
• DNS services.
• ExpressRoute or VPN connectivity.
• Log Analytics workspaces.
• Microsoft Sentinel.
• Defender for Cloud configuration.
• Shared Key Vaults.
• Policy assignments.
• Central automation.

Application landing zone​

An application landing zone contains:

• Application resources.
• Workload-specific VNets.
• Data services.
• Application identities.
• Workload monitoring.
• Backup and recovery configuration.
• AI resources where applicable.

Landing-zone practical project​

Create a small organisation containing:

Then apply policies that:

• Restrict deployment Regions.
• Require tags.
• Prevent public storage access.
• Require diagnostic settings.
• Require secure transport.
• Audit resources without private endpoints.
• Restrict unapproved AI models or resource types.
• Deny production resources without named owners.

Azure Policy can enforce organisational standards and assess compliance at scale, including resource consistency, security, regulatory compliance and cost controls. (Microsoft Learn)

Part Three: Identity and Access Management

8. Understand Microsoft Entra ID​

Microsoft Entra ID provides identity capabilities for:

• Human users.
• Groups.
• Applications.
• Service principals.
• Managed identities.
• Devices.
• Workload identities.
• Enterprise applications.

The first security objective is to avoid permanent, excessive and shared access.

9. Separate Entra roles from Azure RBAC​

These are related but different.

Microsoft Entra roles​

Entra roles control directory-level activities such as:

• User management.
• Application registration.
• Conditional Access.
• Identity governance.
• Directory administration.

Azure RBAC​

Azure role-based access control determines what a principal may do against Azure resources.

Examples include:

• Reader.
• Contributor.
• Owner.
• Storage Blob Data Reader.
• Key Vault Secrets User.
• Cognitive Services OpenAI User.
• Custom workload roles.

Use the narrowest role at the narrowest practical scope.

Microsoft Entra RBAC manages access to directory resources, while Azure RBAC manages permissions against Azure resources. Entra Privileged Identity Management can provide time-limited activation for privileged roles. (Microsoft Learn)

10. Managed identities​

A managed identity gives an Azure resource an automatically managed identity in Microsoft Entra ID.

Use managed identities for:

• App Service to Key Vault.
• Container Apps to Azure OpenAI or Foundry.
• Functions to Storage.
• AKS workloads to Cosmos DB.
• Virtual machines to Key Vault.
• API Management to model endpoints.
• AI agents to authorised tools.

This removes the need to embed passwords or API keys in source code. Managed identities obtain Entra-issued tokens for services that support Entra authentication. (Microsoft Learn)

System-assigned identity​

The identity belongs to one Azure resource and is removed with it.

User-assigned identity​

The identity is created independently and can be attached to multiple resources.

Use user-assigned identities where:

• Multiple resources require one controlled identity.
• Identity lifecycle must be separate from compute lifecycle.
• A predictable identity is needed before application deployment.
• Blue-green deployments need consistent permissions.

11. Conditional Access and privileged access​

Conditional Access can evaluate signals such as:

• User.
• Workload identity.
• Application.
• Device state.
• Location.
• Sign-in risk.
• User risk.
• Authentication strength.

Use it to require:

• Multifactor authentication.
• Compliant devices.
• Approved locations.
• Strong authentication for administrators.
• Restrictions on legacy authentication.
• Additional controls for sensitive applications.

Conditional Access acts as a Zero Trust policy engine, while PIM supports just-in-time activation of privileged roles. (Microsoft Learn)

Identity completion project​

Implement:

• Separate administrative accounts.
• MFA.
• Emergency-access accounts.
• PIM for privileged roles.
• Conditional Access.
• Managed identities for workloads.
• No stored cloud credentials in source code.
• Quarterly access review.
• Joiner, mover and leaver process.
• AI-agent identity inventory.
• Separation between model administration and application usage.

Part Four: Azure Networking

12. Understand Azure Virtual Network​

An Azure Virtual Network provides a private networking boundary for Azure resources.

Learn:

• Address spaces.
• CIDR ranges.
• Subnets.
• Network interfaces.
• Private IP addresses.
• Network Security Groups.
• Route tables.
• NAT Gateway.
• Private Link.
• Private endpoints.
• VNet peering.
• DNS.
• VPN Gateway.
• ExpressRoute.
• Azure Firewall.
• DDoS protection.
• Bastion.

Azure VNets use customer-defined address spaces and subnets, while NSGs filter traffic at subnet or network-interface level. (Microsoft Learn)

13. Design the address space​

Example:

10.20.0.0/16       Production VNet

10.20.0.0/24       Azure Firewall
10.20.1.0/24       Application Gateway
10.20.10.0/24      Application services
10.20.20.0/24      Data services
10.20.30.0/24      Private endpoints
10.20.40.0/24      AKS system nodes
10.20.50.0/24      AKS workloads
10.20.60.0/24      AI platform
10.20.70.0/24      Management

Reserve addresses for:

• Growth.
• Private endpoints.
• Container platforms.
• Hybrid connectivity.
• Future Regions.
• Acquisitions.
• Multi-cloud connectivity.

Avoid overlapping address ranges where networks may later be connected through peering, VPN or ExpressRoute. (Microsoft Learn)

14. Network Security Groups​

An NSG contains inbound and outbound traffic rules.

Example structure:

Application Gateway NSG​

Allow:

• Required public HTTPS traffic.
• Azure platform health probes.
• Outbound traffic to application services.

Application NSG​

Allow:

• Traffic only from Application Gateway.
• Database traffic only to the data tier.
• Required monitoring and management traffic.

Data NSG​

Allow:

• Database connections only from approved workloads.
• No direct internet access.
• Backup and monitoring communication.

Use service tags and application security groups where appropriate rather than hard-coding large collections of IP addresses. (Microsoft Learn)

15. Private endpoints and Private Link​

A private endpoint gives a supported platform service a private IP address inside your VNet.

Use private endpoints for:

• Storage.
• Key Vault.
• Azure SQL.
• Cosmos DB.
• Container Registry.
• Microsoft Foundry.
• Azure OpenAI model endpoints.
• Azure AI Search.
• App Service where supported.
• Other sensitive PaaS resources.

A private endpoint does not automatically solve:

• DNS resolution.
• Identity permissions.
• Data-plane authorisation.
• Route configuration.
• Application authentication.
• Exfiltration control.

These must be designed separately.

16. Outbound connectivity​

Use explicit outbound connectivity through:

• Azure NAT Gateway.
• Azure Firewall.
• Network Virtual Appliance.
• Controlled proxy.
• Approved private endpoints.

Azure NAT Gateway provides scalable outbound SNAT using static public IP addresses or prefixes. Current Azure networking guidance increasingly emphasises explicit outbound connectivity rather than relying on default outbound access. (Microsoft Learn)

For AI workloads, outbound access should be restricted to:

• Approved model endpoints.
• Approved package repositories.
• Approved external APIs.
• Security update services.
• Audited tool endpoints.
• Authorised MCP servers.

17. Hub-and-spoke networking​

A common enterprise topology is:

The hub provides central connectivity and security services. Spokes isolate workloads and business domains.

Networking completion project​

Deploy:

• Hub-and-spoke topology.
• Production and non-production spokes.
• Azure Firewall.
• NAT Gateway.
• Private DNS zones.
• Private endpoints for Storage, Key Vault and SQL.
• Network Watcher.
• NSG flow visibility.
• Documented inbound and outbound flows.
• AI-specific egress allowlist.

Part Five: Virtual Machines and Compute

18. Azure Virtual Machines​

Azure Virtual Machines provide IaaS compute for Linux and Windows workloads.

Use VMs when you require:

• Operating-system control.
• Legacy applications.
• Custom agents.
• Specialist drivers.
• Unsupported runtimes.
• Lift-and-shift migration.
• Host-level configuration.
• Special hardware requirements.

Understand:

• VM sizes.
• CPU and memory.
• Temporary disks.
• Managed Disks.
• Availability Zones.
• Availability sets.
• Images.
• Extensions.
• Managed identities.
• Boot diagnostics.
• Update management.
• Backup.
• Azure Bastion.
• Just-in-time access.

Azure recommends VM Scale Sets with flexible orchestration for many high-availability VM scenarios because scale sets support central management, configuration, updates and automatic scaling. (Microsoft Learn)

19. Managed Disks​

Learn the main design dimensions:

• Disk type.
• Capacity.
• IOPS.
• Throughput.
• Caching.
• Encryption.
• Redundancy.
• Snapshots.
• Backup.
• Shared-disk requirements.

Azure offers multiple managed-disk types for different performance and cost requirements. Zone-redundant managed disks can synchronously replicate data across Availability Zones in supported scenarios. (Microsoft Learn)

20. Virtual Machine Scale Sets​

A VM Scale Set manages a group of virtual machines.

Learn:

• Scaling profile.
• Minimum and maximum capacity.
• Metric-based scaling.
• Schedule-based scaling.
• Predictive scaling where appropriate.
• Health probes.
• Upgrade policies.
• Image versioning.
• Zone distribution.
• Rolling replacement.
• Load-balancer integration.

Scale Sets can increase or decrease instance count manually, on a schedule or according to metric-based rules. (Microsoft Learn)

VM project​

Deploy:

Add:

• Private VM instances.
• Managed identity.
• Key Vault integration.
• Autoscaling.
• Log Analytics.
• Application Insights.
• Azure Backup.
• Availability Zone distribution.
• Patch-management process.

Part Six: Azure Application Platforms

21. Azure App Service​

App Service is a managed application platform for:

• Web applications.
• APIs.
• Mobile back ends.
• Windows and Linux workloads.
• Supported language runtimes.
• Custom containers.

App Service manages much of the underlying hosting infrastructure, allowing teams to focus on application delivery. (Microsoft Learn)

Concepts to learn​

• App Service plan.
• Web App.
• Deployment slots.
• Scaling up and scaling out.
• Managed identity.
• VNet integration.
• Private endpoints.
• Access restrictions.
• Custom domains.
• TLS certificates.
• Configuration settings.
• Key Vault references.
• Health checks.
• Backups.
• Application Insights.

Deployment slots​

Use slots for:

• Staging.
• Pre-production verification.
• Blue-green deployment.
• Controlled production swaps.
• Rapid rollback.

App Service project​

Deploy an API with:

• Private back-end connectivity.
• Managed identity.
• Key Vault.
• Azure SQL.
• Deployment slot.
• Application Insights.
• Autoscaling.
• Front Door.
• Web Application Firewall.
• CI/CD pipeline.

Part Seven: Storage

22. Understand Azure Storage​

An Azure Storage account can provide several data services.

Blob Storage​

Use for:

• Documents.
• Images.
• Audio.
• Video.
• Backups.
• Logs.
• Data lakes.
• AI training data.
• RAG documents.
• Model artefacts.

Azure Files​

Use for managed file shares accessed over supported file protocols.

Queue Storage​

Use for basic asynchronous message queues.

Table Storage​

Use for key-value or simple NoSQL workloads where its model fits.

Managed Disks​

Use as block storage for virtual machines.

23. Blob access tiers​

Select tiers according to access frequency, retrieval requirements and retention periods.

Typical categories include:

• Hot.
• Cool.
• Cold where available.
• Archive.

Lifecycle-management rules can transition blobs into lower-cost tiers or delete them at the end of the required retention period. (Microsoft Learn)

Storage security​

Implement:

• Entra authentication.
• RBAC.
• Managed identities.
• Private endpoints.
• Public-access restrictions.
• Secure transfer.
• Encryption.
• Customer-managed keys where justified.
• Versioning.
• Soft delete.
• Immutable storage where required.
• Malware protection where appropriate.
• Data-classification labels.
• Diagnostic logs.

AI-data zones​

For an enterprise AI platform, separate storage into:

Do not let the AI indexing pipeline read every container by default.

Part Eight: Databases and Caching

24. Azure SQL Database​

Use Azure SQL Database when you require:

• Relational modelling.
• SQL.
• Transactions.
• Constraints.
• Joins.
• Strong consistency.
• Established SQL Server compatibility.

Learn:

• Single databases.
• Elastic pools.
• Provisioned and serverless options.
• Backup and point-in-time restore.
• Zone redundancy.
• Geo-replication.
• Failover groups.
• Entra authentication.
• Transparent Data Encryption.
• Auditing.
• Threat detection.
• Private endpoints.
• Row-level security.
• Dynamic data masking.
• Connection pooling.

Azure SQL Database is a managed relational database platform and supports common SQL Server application capabilities. (Microsoft Learn)

25. Cosmos DB​

Cosmos DB is appropriate for workloads requiring combinations of:

• Flexible JSON schemas.
• Horizontal scale.
• Globally distributed data.
• Predictable low latency.
• Automatic indexing.
• Multiple consistency options.
• Vector search.
• High-volume application data.

Cosmos DB scales through logical and physical partitioning, making partition-key design one of the most important architectural decisions. (Microsoft Learn)

Concepts to learn​

• Account.
• Database.
• Container.
• Item.
• Partition key.
• Request units.
• Indexing policy.
• Consistency levels.
• Change feed.
• Time to live.
• Multi-region replication.
• Backup.
• Private endpoints.

AI use cases​

Cosmos DB may store:

• Conversation state.
• Agent state.
• User preferences.
• Workflow checkpoints.
• Evaluation records.
• Feedback.
• Tool-call history.
• Application metadata.

Do not automatically use Cosmos DB as a vector database merely because the application uses AI. Choose it according to access patterns and operational requirements.

26. Azure Managed Redis​

Use managed Redis for:

• Application caching.
• Session state.
• Rate limiting.
• Distributed locks.
• Agent short-term memory.
• Semantic caches.
• Idempotency keys.
• Fast counters.
• Leaderboards.

Azure Cache for Redis has an announced retirement path, so new architecture decisions should evaluate Azure Managed Redis rather than treating the older service as the default. (Microsoft Learn)

AI cache warning​

Never cache model responses without considering:

• User identity.
• Tenant boundary.
• Data sensitivity.
• Prompt parameters.
• Model version.
• Guardrail version.
• Authorisation context.
• Freshness.
• Right-to-erasure obligations.

A cache key that excludes the user or tenant can expose one customer’s generated result to another.

Part Nine: APIs, Events and Integration

27. Azure API Management​

API Management provides a managed gateway for APIs and, increasingly, AI endpoints and MCP servers.

Use it for:

• Authentication.
• Authorisation.
• Rate limiting.
• Quotas.
• Request validation.
• Response transformation.
• Versioning.
• Caching.
• Developer onboarding.
• Analytics.
• Network isolation.
• Central policy enforcement.

API Management can publish and protect APIs hosted in Azure, on premises or elsewhere. Its AI gateway capabilities can use managed identities, moderate prompts through Azure AI Content Safety and manage access to model or MCP endpoints. (Microsoft Learn)

AI gateway policies​

A production AI gateway should control:

• Which models may be called.
• Which applications may call them.
• Per-user and per-application quotas.
• Token limits.
• Input size.
• Prompt injection screening.
• PII handling.
• Content moderation.
• Regional routing.
• Model fallback.
• Logging and correlation.
• Response filtering.
• Cost attribution.
• Abuse detection.

28. Service Bus​

Azure Service Bus is an enterprise message broker supporting queues and publish-subscribe topics.

Use it when you need:

• Reliable business messaging.
• Competing consumers.
• Delivery guarantees.
• Dead-letter queues.
• Scheduled messages.
• Message sessions.
• Transactions.
• Workload decoupling.

Service Bus supports queues and topics and is designed for reliable transfer of business data and decoupled application processing. (Microsoft Learn)

AI use cases​

• Long-running document processing.
• Batch embedding creation.
• Human-review queues.
• Asynchronous agent jobs.
• Evaluation processing.
• Notifications.
• Retry and dead-letter handling.

29. Event Grid​

Event Grid is designed for event distribution and reactive architectures.

Use it when:

• A blob is uploaded.
• A resource changes.
• A model deployment completes.
• An evaluation is published.
• A business event should be routed.
• Multiple subscribers need notifications.

Event Grid is a managed publish-subscribe event distribution service. (Microsoft Learn)

30. Event Hubs​

Use Event Hubs for high-throughput streaming and telemetry scenarios.

Typical use cases include:

• Device events.
• Application telemetry.
• Clickstreams.
• Security events.
• Model interaction streams.
• Large-scale audit event ingestion.

A practical distinction is:

Microsoft’s messaging guidance distinguishes the services according to transactional messaging, reactive event routing and high-throughput streaming. (Microsoft Learn)

Part Ten: Containers

31. Azure Container Registry​

Azure Container Registry stores and manages:

• Container images.
• OCI artefacts.
• Helm-related artefacts.
• Versioned application packages.

Learn:

• Registries.
• Repositories.
• Tags.
• Digests.
• Immutable image references.
• Retention.
• Geo-replication.
• Private Link.
• Managed identity authentication.
• Image scanning.
• Signing and provenance.
• Base-image updates.

ACR is a private registry for storing and distributing container images and OCI artefacts. (Microsoft Learn)

Secure image workflow​

32. Azure Container Apps​

Container Apps provides serverless container hosting without requiring teams to manage Kubernetes infrastructure.

It supports:

• HTTP applications.
• APIs.
• Background workers.
• Scheduled jobs.
• Event-driven workloads.
• Microservices.
• Multiple revisions.
• Traffic splitting.
• KEDA-based scaling.
• Scale to zero for applicable workloads.
• Internal ingress.
• Dapr integration.
• Managed identities.

Container Apps is often a strong choice for teams that need containers and autoscaling but do not need full Kubernetes control. (Microsoft Learn)

AI uses​

• RAG API.
• PII-redaction service.
• Agent orchestrator.
• Evaluation worker.
• Embedding pipeline.
• Guardrail service.
• Tool gateway.
• Model proxy.
• Document-ingestion worker.

33. Azure Kubernetes Service​

AKS is a managed Kubernetes platform.

Current AKS offerings include:

• AKS Automatic: More infrastructure, scaling, security and upgrade management handled by Azure.
• AKS Standard: Greater control over cluster and node-pool configuration.

Microsoft currently recommends AKS Automatic for many teams and workloads seeking a production-ready Kubernetes experience with reduced operational overhead. (Microsoft Learn)

Learn before adopting AKS​

You should understand:

• Pods.
• Deployments.
• StatefulSets.
• Services.
• Ingress.
• Gateway API.
• ConfigMaps.
• Secrets.
• Namespaces.
• Kubernetes RBAC.
• Network policies.
• Persistent volumes.
• Resource requests and limits.
• Horizontal Pod Autoscaling.
• Node autoscaling.
• Workload identity.
• Pod security.
• Admission policies.
• Service mesh.
• Cluster upgrades.
• Backup and recovery.

Choose AKS when​

• Kubernetes portability is required.
• Multiple complex services share a platform.
• Kubernetes-native tooling is required.
• Advanced network or workload scheduling is needed.
• Platform engineers can operate Kubernetes safely.
• GPU or specialised node pools are required.
• The organisation has a justified Kubernetes strategy.

Do not choose AKS merely because it appears more advanced.

Part Eleven: Serverless

34. Azure Functions​

Azure Functions runs event-driven code without requiring you to provision traditional servers.

Typical triggers include:

• HTTP.
• Timer.
• Service Bus.
• Event Grid.
• Event Hubs.
• Storage.
• Database events.
• Custom integrations.

Azure Functions supports event-driven application patterns, scheduled compute, automatic scaling and integration with Azure services. (Microsoft Learn)

Concepts to learn​

• Function App.
• Functions.
• Triggers.
• Input and output bindings.
• Hosting plans.
• Managed identity.
• VNet integration.
• Durable Functions.
• Retry policy.
• Idempotency.
• Dead-letter handling.
• Concurrency.
• Cold starts.
• Application Insights.

AI serverless patterns​

Functions are useful for short, event-driven units of work. Long-running, complex workflows may require Durable Functions, Container Apps jobs or another orchestration model.

Part Twelve: Front-End Delivery and Traffic Management

35. Azure Front Door​

Azure Front Door is a global edge and content-delivery service for static and dynamic web applications.

It supports:

• Global routing.
• Content delivery.
• Edge caching.
• Origin health checking.
• TLS termination.
• Web Application Firewall.
• Rate limiting.
• Bot protection.
• Multi-region failover.

Front Door is designed to improve global performance, scalability, availability and security for internet-facing applications. (Microsoft Learn)

36. Application Gateway​

Application Gateway provides regional Layer 7 web traffic management.

Use it for:

• HTTP and HTTPS routing.
• Path-based routing.
• Host-based routing.
• TLS termination.
• Web Application Firewall.
• Regional application ingress.
• Integration with private back ends.

Application Gateway is a regional web traffic load balancer, whereas Front Door provides global edge routing. (Microsoft Learn)

Typical enterprise architecture​

Part Thirteen: Monitoring and Observability

37. Azure Monitor​

Azure Monitor is the central monitoring platform for Azure and connected workloads.

Its main components include:

• Metrics.
• Logs.
• Alerts.
• Workbooks.
• Dashboards.
• Application Insights.
• Log Analytics.
• Activity Logs.
• Data collection rules.
• Azure Monitor Agent.

A Log Analytics workspace stores log data from Azure and non-Azure resources and integrates with services such as Sentinel and Defender for Cloud. (Microsoft Learn)

38. Application Insights​

Application Insights provides application performance monitoring.

Track:

• Requests.
• Dependencies.
• Exceptions.
• Response time.
• Availability.
• User journeys.
• Distributed traces.
• Application maps.
• Custom events.
• Business metrics.

Application Map can visualise dependencies and highlight bottlenecks and failures across components. (Microsoft Learn)

AI-specific observability​

For each AI request, record a correlation identifier covering:

Avoid storing complete prompts and responses indiscriminately. Logging policy must consider:

• Personal data.
• Confidential information.
• Credentials.
• Legal privilege.
• Retention.
• Data residency.
• Access restrictions.
• Right-to-erasure requirements.

AI metrics​

Monitor:

Part Fourteen: Reliability and Business Continuity

39. Azure Well-Architected Framework​

The Azure Well-Architected Framework currently has five pillars:

1. Reliability.
2. Security.
3. Cost optimisation.
4. Operational excellence.
5. Performance efficiency.

It provides architectural principles, decision guidance and review tools for Azure workloads. (Microsoft Learn)

Reliability questions​

• What happens when one instance fails?
• What happens when one zone fails?
• What happens when a Region fails?
• What happens when a model endpoint reaches quota?
• What happens when the vector store is unavailable?
• What happens when the guardrail service fails?
• Can the system fail closed?
• Can users recover their work?
• What is the RPO?
• What is the RTO?

40. Backup and disaster recovery​

Azure Backup provides managed backup services for Azure and on-premises workloads. Azure Site Recovery supports replication and disaster-recovery scenarios. Azure Business Continuity Center is now the recommended central experience for broader backup and disaster-recovery management at scale. (Microsoft Learn)

Protect more than the application​

Back up or reproduce:

• Databases.
• Blob containers.
• Key configuration.
• Infrastructure code.
• Container images.
• Prompt templates.
• Evaluation datasets.
• Search indexes or source data needed to rebuild them.
• Model deployment configuration.
• Policy definitions.
• Agent tool definitions.
• Governance evidence.

AI recovery planning​

A complete AI recovery procedure should explain:

1. How model endpoints are restored or recreated.
2. How search indexes are rebuilt.
3. How embeddings are reproduced.
4. Which model version is the approved fallback.
5. What happens if a model is withdrawn.
6. How prompt versions are recovered.
7. How agent memory is restored safely.
8. How governance approval is preserved after restoration.

Part Fifteen: Infrastructure as Code

41. Learn Bicep​

Bicep is Azure’s declarative infrastructure-as-code language. It compiles into Azure Resource Manager templates and supports reusable modules and consistent deployment. (Microsoft Learn)

Example:

param location string = resourceGroup().location
param environment string

resource storage 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: 'st${environment}${uniqueString(resourceGroup().id)}'
  location: location
  sku: {
    name: 'Standard_ZRS'
  }
  kind: 'StorageV2'
  properties: {
    allowBlobPublicAccess: false
    supportsHttpsTrafficOnly: true
    minimumTlsVersion: 'TLS1_2'
    publicNetworkAccess: 'Disabled'
  }
}

Infrastructure-as-code requirements​

Your platform code should support:

• Repeatable deployment.
• Environment separation.
• Modular components.
• Parameter validation.
• Policy testing.
• Drift detection.
• Deployment previews.
• Rollback.
• Secrets separation.
• Automated documentation.
• Versioned modules.

Recommended repository​

Part Sixteen: DevSecOps

42. Build a secure delivery pipeline​

A production pipeline should resemble:

Azure Pipelines supports continuous integration, testing and delivery for applications deployed to Azure and other environments. (Microsoft Learn)

Use workload federation​

Avoid storing long-lived cloud credentials in GitHub or pipeline tools.

Prefer:

• Federated credentials.
• Managed identities.
• Short-lived tokens.
• Environment approvals.
• Limited deployment scopes.
• Separate production identity.
• Protected branches.
• Signed release artefacts.

AI pipeline additions​

Add:

• Prompt regression testing.
• Model evaluation.
• Groundedness testing.
• Safety evaluation.
• Prompt-injection testing.
• Bias and cohort testing.
• Data-leakage testing.
• Tool-authorisation testing.
• Token and cost thresholds.
• Human approval for high-risk changes.
• Model and prompt version registration.

Part Seventeen: Core Azure Security

43. Apply Zero Trust​

Use three principles:

1. Verify explicitly.
2. Use least privilege.
3. Assume breach.

Apply them across:

• Human identities.
• Workload identities.
• AI-agent identities.
• Devices.
• Networks.
• Data.
• Applications.
• Model endpoints.
• Tools.
• Third-party integrations.

44. Azure Key Vault​

Key Vault manages:

• Secrets.
• Cryptographic keys.
• Certificates.

Managed HSM provides a dedicated managed hardware-security-module capability for higher-assurance key requirements. (Microsoft Learn)

Key Vault controls​

Implement:

• Entra authentication.
• Azure RBAC.
• Managed identities.
• Private endpoints.
• Soft delete.
• Purge protection.
• Rotation.
• Audit logging.
• Separate administration and secret usage.
• No secret values in pipelines or prompts.

Microsoft recommends managed identities for application access to Key Vault so applications do not require hard-coded credentials. (Microsoft Learn)

45. Defender for Cloud​

Microsoft Defender for Cloud provides:

• Cloud security posture management.
• Secure-score recommendations.
• Regulatory-compliance views.
• Workload threat protection.
• Attack-path analysis.
• DevOps security integration.
• Multi-cloud visibility.
• AI workload visibility and protection.

Its Cloud Security Posture Management capabilities continuously assess cloud resources and provide recommendations based on security standards such as the Microsoft Cloud Security Benchmark. (Microsoft Learn)

46. Microsoft Sentinel​

Use Sentinel as the security information and event management and security orchestration layer.

Ingest:

• Entra logs.
• Azure Activity Logs.
• Firewall logs.
• WAF logs.
• Key Vault logs.
• API Management logs.
• AI gateway events.
• Foundry events.
• Defender alerts.
• Application security events.
• Agent tool-call alerts.

Develop:

• Detection rules.
• Workbooks.
• Incident playbooks.
• Automated enrichment.
• Containment actions.
• Threat-hunting queries.

Part Eighteen: AI Foundations

47. Learn the AI system layers​

An enterprise AI application is more than a model.

Think in the following layers:

You should understand each layer before designing the architecture.

48. AI categories​

Predictive machine learning​

Use cases:

• Fraud detection.
• Churn prediction.
• Demand forecasting.
• Credit risk.
• Classification.
• Anomaly detection.

Generative AI​

Use cases:

• Content generation.
• Summarisation.
• Question answering.
• Code generation.
• Document analysis.
• Conversational applications.

Retrieval-augmented generation​

RAG combines a model with controlled enterprise knowledge retrieval.

AI agents​

An agent may:

• Interpret an objective.
• Build a plan.
• Retrieve information.
• Call tools.
• Update state.
• Ask for human approval.
• Execute actions.
• Observe results.

The more authority an agent receives, the more important deterministic policy enforcement becomes.

Part Nineteen: Microsoft Foundry and Azure AI Engineering

49. Microsoft Foundry​

Microsoft Foundry provides capabilities for:

• Model discovery and deployment.
• Enterprise AI application development.
• Evaluation.
• Agent development.
• Model operations.
• Guardrails.
• Connections to enterprise data.
• Production hosting.

Foundry Agent Service is a managed platform for building, deploying and scaling AI agents using supported models and frameworks. (Microsoft Learn)

Core areas to learn​

1. Foundry resources and projects.
2. Model catalogue.
3. Model deployment types.
4. Azure OpenAI models.
5. Open and third-party models.
6. Agent Service.
7. Evaluations.
8. Connections.
9. Networking.
10. Identity and RBAC.
11. Monitoring.
12. Guardrails.
13. Quotas.
14. Cost management.
15. Lifecycle and retirement.

Current workflow warning​

Prompt flow remains present in some existing environments, but Microsoft documentation states that Prompt flow in Foundry and Azure Machine Learning is scheduled for retirement on 20 April 2027 and is no longer recommended for new development. New architectures should verify Microsoft’s recommended Agent Framework path rather than creating a long-term dependency on Prompt flow. (Microsoft Learn)

50. Model-selection framework​

Evaluate models across:

Do not select a model using a public benchmark alone. Test it on representative business tasks, user groups, languages, failure cases and security scenarios.

51. Enterprise RAG architecture​

RAG components​

• Source-system connectors.
• Document extraction.
• Malware scanning.
• PII classification.
• Access-control extraction.
• Chunking.
• Metadata.
• Embeddings.
• Indexing.
• Hybrid search.
• Semantic ranking.
• Retrieval filtering.
• Reranking.
• Prompt construction.
• Model call.
• Citation generation.
• Evaluation.
• Feedback.
• Re-indexing.

RAG security​

Every retrieved item should be filtered by:

• Tenant.
• User.
• Role.
• Data classification.
• Legal boundary.
• Geographic boundary.
• Document status.
• Retention state.

Do not rely on the model to enforce access control. Retrieval authorisation must happen in deterministic application and data layers.

52. Agent architecture​

Agent tool classes​

The model should propose actions. Deterministic software should decide whether the action is allowed.

Part Twenty: AI Security

53. AI security is broader than prompt filtering​

AI security covers:

1. Governance and asset discovery.
2. Identity and access.
3. Infrastructure.
4. Networks.
5. Data.
6. Model supply chain.
7. Training and fine-tuning.
8. Prompts.
9. RAG.
10. Agents and tools.
11. Application security.
12. APIs.
13. Runtime monitoring.
14. Human behaviour.
15. Third-party risk.
16. Incident response.
17. Business continuity.
18. Cost and resource abuse.

Microsoft’s AI shared-responsibility guidance emphasises that responsibilities change according to the AI service model, but customers still own major responsibilities for data, identities, application configuration, access and safe use. (Microsoft Learn)

54. AI threat taxonomy​

Data threats​

• Sensitive-data disclosure.
• Unauthorised training data.
• Excessive data collection.
• Data poisoning.
• Embedding poisoning.
• RAG source manipulation.
• Membership inference.
• Model inversion.
• Cross-tenant exposure.
• Improper retention.
• PII in logs.
• Unauthorised secondary use.

Model threats​

• Model theft.
• Model extraction.
• Backdoored models.
• Malicious model files.
• Adversarial examples.
• Unsafe fine-tuning.
• Unverified model provenance.
• Model drift.
• Hidden behaviour changes.
• Dependency compromise.

Prompt and application threats​

• Direct prompt injection.
• Indirect prompt injection.
• Jailbreaking.
• System-prompt leakage.
• Improper output handling.
• Insecure structured output.
• Hallucination.
• Overreliance.
• Denial of wallet.
• Resource exhaustion.
• Context-window attacks.

Agent threats​

• Excessive agency.
• Tool misuse.
• Privilege escalation.
• Confused deputy attacks.
• Memory poisoning.
• Malicious tool descriptions.
• MCP server compromise.
• Cross-agent trust failure.
• Unauthorised transactions.
• Infinite loops.
• Social engineering by retrieved content.

The OWASP Top 10 for LLM Applications includes risks such as prompt injection, sensitive-information disclosure, supply-chain weaknesses, data and model poisoning, improper output handling, excessive agency and system-prompt leakage. MITRE ATLAS provides a living knowledge base of adversarial tactics and techniques targeting AI systems. (OWASP Gen AI Security Project)

55. Secure the AI platform​

Implement:

• Separate development and production projects.
• Entra authentication.
• Managed identities.
• Least-privilege RBAC.
• Private endpoints.
• Public network disabled where practical.
• Controlled outbound access.
• Key Vault.
• Approved model catalogue.
• Deployment quotas.
• Diagnostic settings.
• Central logs.
• Defender for Cloud.
• Policy enforcement.
• Separate administrative and inference roles.
• Tested recovery procedures.

Microsoft’s Azure AI security guidance recommends network isolation, managed virtual networks or private connectivity, strong access control, model governance and visibility of AI workloads. (Microsoft Learn)

56. Secure prompts​

A system prompt is not a security boundary.

Do not include:

• Passwords.
• API keys.
• Database credentials.
• Internal IP addresses.
• Sensitive permission mappings.
• Confidential control logic.
• Unnecessary personal data.

OWASP recommends separating sensitive information from prompts and not relying on system prompts as the sole means of enforcing strict security behaviour. (OWASP Gen AI Security Project)

Prompt controls​

• Store prompts in version control.
• Assign owners.
• Review changes.
• Test regressions.
• Separate policy instructions from secrets.
• Define trusted and untrusted content.
• Mark retrieved content as data, not instructions.
• Test multilingual attacks.
• Test encoded and obfuscated instructions.
• Limit context.
• Record prompt version in traces.

57. Prompt injection defence​

There is no single perfect prompt-injection detector.

Use defence in depth:

Azure AI Content Safety can evaluate harmful text and images, while Prompt Shields is intended to help detect direct and indirect prompt attacks. (Microsoft Learn)

For indirect prompt injection​

Treat all external content as untrusted:

• Documents.
• Web pages.
• Emails.
• Images.
• PDFs.
• Search results.
• Tool responses.
• MCP metadata.
• Database content.
• User-generated files.

Do not permit retrieved text to alter:

• System authority.
• Tool permissions.
• Identity.
• Authorisation.
• Payment limits.
• Data-access scope.
• Audit logging.

58. Secure model outputs​

Model output must be treated as untrusted input.

Before using output in another system:

• Parse using a strict schema.
• Validate data types.
• Validate allowed values.
• Escape content.
• Scan URLs.
• Disallow executable code where unnecessary.
• Enforce database parameterisation.
• Enforce recipient and amount limits.
• Apply business rules.
• Require approval for sensitive actions.

Never directly place unrestricted model output into:

• SQL.
• Shell commands.
• HTML.
• Infrastructure templates.
• Email recipients.
• Payment APIs.
• Privileged tool arguments.

Improper output handling is a major LLM application risk because unsafe output may be passed into downstream systems without adequate validation or sanitisation. (OWASP Gen AI Security Project)

59. PII and sensitive-data protection​

Use a layered process:

Presidio​

Microsoft Presidio is an open-source framework for detecting and de-identifying personal information across text, images and structured data. It supports custom recognisers and multiple anonymisation operators. Its documentation also warns that automated detection cannot guarantee that every sensitive item will be found. (Microsoft GitHub)

Therefore:

• Benchmark Presidio on your domain.
• Add custom recognisers.
• Test names and addresses from relevant countries.
• Measure precision and recall.
• Combine patterns and NLP.
• Use human review for high-risk datasets.
• Never describe automated redaction as infallible.
• Test logs as well as prompts.
• Maintain reversible pseudonymisation only where necessary and securely controlled.

Azure AI Language also provides PII detection and redaction capabilities for text, and newer document-oriented capabilities can operate on supported document formats. (Microsoft Learn)

60. Secure AI agents​

Apply the following controls:

Least privilege​

Every tool should receive the minimum permission required.

Per-user authorisation​

The agent must not inherit broad platform permissions that exceed the user’s authority.

Tool allowlisting​

Only approved tools may be invoked.

Argument validation​

Validate:

• User ID.
• Account ID.
• Amount.
• Recipient.
• Date range.
• File path.
• Query scope.
• Allowed operation.

Human approval​

Require confirmation for:

• Payments.
• Deletion.
• External communication.
• HR decisions.
• Changes to customer records.
• Regulatory submissions.
• Infrastructure changes.
• Privileged operations.

Transaction limits​

Enforce:

• Monetary thresholds.
• Rate limits.
• Allowed recipients.
• Allowed time windows.
• Approval chains.

Memory controls​

• Separate memory by user and tenant.
• Do not store secrets.
• Expire temporary state.
• Validate memory before reuse.
• Protect against malicious memory insertion.
• Provide deletion mechanisms.

Excessive agency occurs when an AI system is granted powers that allow harmful actions to be performed after unexpected or manipulated model behaviour. (OWASP Gen AI Security Project)

61. AI supply-chain security​

Track:

• Model provider.
• Model version.
• Model licence.
• Model hash.
• Dataset source.
• Dataset licence.
• Container images.
• Python packages.
• Prompt libraries.
• Embedding models.
• Evaluation tools.
• Orchestration frameworks.
• MCP servers.
• Plugins.
• Fine-tuning jobs.
• Deployment configuration.

Produce:

• Software Bill of Materials.
• AI Bill of Materials.
• Model card.
• Dataset documentation.
• Provenance record.
• Vulnerability report.
• Supplier assessment.
• Approval record.

Defender for Cloud can discover AI workloads and provide an AI Bill of Materials view, posture recommendations and attack-path analysis. It can also identify risks in AI libraries and artefacts before deployment. (Microsoft Learn)

62. AI runtime protection​

Monitor for:

• Jailbreak attempts.
• Prompt injection.
• Data leakage.
• Unusual model use.
• Credential theft.
• Abnormal tool invocation.
• Sudden cost increases.
• High-volume requests.
• Suspicious source addresses.
• Unexpected model changes.
• Unsafe response patterns.
• Cross-tenant anomalies.
• Data poisoning indicators.

Microsoft Defender for Cloud’s AI threat protection is designed to detect threats such as data leakage, poisoning, jailbreak attempts and credential theft, with integration into Defender XDR for investigation. (Microsoft Learn)

Part Twenty-One: AI Governance

63. Governance is not a final approval gate​

AI governance should operate throughout the lifecycle.

A practical lifecycle is:

64. AI governance operating model​

Board or executive committee​

Owns:

• AI risk appetite.
• Strategic priorities.
• Funding.
• High-risk exceptions.
• Accountability.

AI governance council​

Owns:

• Policies.
• Standards.
• Risk classification.
• Portfolio oversight.
• Escalation.
• Cross-functional decisions.

Responsible AI committee​

Reviews:

• Fairness.
• Transparency.
• Human impact.
• Safety.
• Inclusiveness.
• High-impact use cases.

Information security​

Owns:

• Threat modelling.
• Security requirements.
• Testing.
• Monitoring.
• Incident response.

Data protection and legal​

Owns:

• Lawful basis.
• DPIA.
• Privacy notices.
• Data-subject rights.
• Contracts.
• Regulatory interpretation.

Data governance​

Owns:

• Data classification.
• Quality.
• Lineage.
• Ownership.
• Retention.
• Access.

Platform engineering​

Owns:

• Landing zone.
• Shared AI platform.
• Guardrails.
• Deployment patterns.
• Observability.
• Resilience.

Product owner​

Owns:

• Business outcome.
• User experience.
• Benefits.
• User communications.
• Operational adoption.

Model owner​

Owns:

• Model performance.
• Evaluation.
• Model limitations.
• Change management.
• Retirement.

Internal audit​

Provides independent assurance that controls operate as designed.

65. AI use-case intake​

Every AI initiative should begin with an intake form containing:

• Use-case name.
• Business owner.
• Technical owner.
• Users.
• People affected.
• Decision or action supported.
• Data used.
• Model type.
• Deployment Region.
• Third parties.
• Expected benefit.
• Failure impact.
• Human oversight.
• Automated actions.
• Regulatory scope.
• Reversibility.
• Risk classification.

Disqualifying or escalation questions​

• Does the use case manipulate vulnerable users?
• Does it make or materially influence employment decisions?
• Does it influence credit, insurance or essential services?
• Does it use biometric data?
• Does it perform emotion inference?
• Does it make decisions about children?
• Does it process special-category data?
• Can it execute financial transactions?
• Can it change infrastructure?
• Can it communicate externally?
• Can it cause physical or safety harm?

66. Risk classification​

A practical internal model can use four levels.

Tier 1: Low​

Examples:

• Internal text summarisation.
• Draft generation.
• Non-sensitive knowledge search.

Controls:

• Standard security.
• Basic evaluation.
• User notice.
• Monitoring.

Tier 2: Moderate​

Examples:

• Customer-service assistant.
• Employee productivity agent.
• Marketing-content generation.

Controls:

• Formal owner.
• Data review.
• Security testing.
• Human escalation.
• Quality and safety metrics.

Tier 3: High​

Examples:

• Fraud recommendations.
• Credit support.
• Medical assistance.
• Recruitment screening.
• Significant financial workflows.

Controls:

• AI impact assessment.
• DPIA where required.
• Independent validation.
• Human oversight.
• Extensive testing.
• Formal deployment approval.
• Continuous monitoring.

Tier 4: Prohibited or unacceptable​

Systems that violate applicable law, policy or organisational values must not proceed.

67. Governance artefacts​

Maintain:

68. Model and prompt change control​

Changes requiring re-evaluation may include:

• Model provider change.
• Model version change.
• Deployment type change.
• System-prompt change.
• Retrieval-source change.
• Chunking change.
• Embedding-model change.
• New tool.
• Expanded agent permissions.
• New user group.
• New country.
• New personal-data category.
• New automated action.
• New fine-tuning dataset.
• New content-safety threshold.

Create a change matrix that determines:

• Whether regression tests are sufficient.
• Whether security review is required.
• Whether DPIA review is required.
• Whether full governance approval is required.
• Whether users must be notified.

Part Twenty-Two: Governance Frameworks and Regulation

69. NIST AI Risk Management Framework​

NIST AI RMF is organised into four functions:

1. Govern
2. Map
3. Measure
4. Manage

The Generative AI Profile extends the framework for risks associated with generative AI. (NIST)

Govern​

Establish:

• Accountability.
• Policies.
• Roles.
• Risk appetite.
• Training.
• Third-party governance.
• Documentation.
• Culture.

Map​

Understand:

• Context.
• Users.
• People affected.
• Data.
• Intended use.
• Misuse.
• Dependencies.
• Failure impact.

Measure​

Assess:

• Accuracy.
• Reliability.
• Fairness.
• Privacy.
• Security.
• Explainability.
• Safety.
• Robustness.
• Human factors.

Manage​

Prioritise and respond through:

• Mitigation.
• Monitoring.
• Acceptance.
• Transfer.
• Avoidance.
• Incident response.
• Retirement.

70. ISO/IEC 42001​

ISO/IEC 42001 defines requirements for establishing, implementing, maintaining and continually improving an AI management system.

It covers areas such as:

• Organisational context.
• Leadership.
• AI policy.
• Planning.
• Support.
• Operational controls.
• Performance evaluation.
• Internal audit.
• Management review.
• Continual improvement.

ISO describes the AI management system as the organisational policies, objectives and processes used to manage responsible development, provision and use of AI systems. (ISO)

Practical implementation​

71. EU AI Act​

The EU AI Act follows a risk-based regulatory model covering prohibited practices, high-risk systems, transparency obligations and general-purpose AI models.

Most provisions are scheduled to apply from 2 August 2026, while some provisions—including prohibited practices, definitions and AI-literacy obligations—began earlier. GPAI and governance-related provisions also entered application in stages. (EUR-Lex)

Internal classification​

Assess whether the organisation is acting as:

• Provider.
• Deployer.
• Importer.
• Distributor.
• Authorised representative.
• General-purpose AI model provider.

High-risk control areas​

Prepare for:

• Risk-management system.
• Data governance.
• Technical documentation.
• Record keeping.
• Instructions for use.
• Human oversight.
• Accuracy.
• Robustness.
• Cybersecurity.
• Post-market monitoring.
• Incident reporting.
• Quality-management system.

Do not assume that using a third-party model transfers all legal responsibility to the model provider.

72. GDPR and UK data protection​

AI processing involving personal data must consider:

• Lawfulness.
• Fairness.
• Transparency.
• Purpose limitation.
• Data minimisation.
• Accuracy.
• Storage limitation.
• Security.
• Accountability.
• Data-subject rights.
• Automated decision-making.
• Profiling.
• International transfers.

The ICO’s AI guidance explains how data-protection law applies when personal data is used to train, test or operate AI systems and provides a toolkit for assessing risks to individuals’ rights and freedoms. (ICO)

DPIA triggers to examine​

A DPIA may be particularly important when:

• Processing is large scale.
• Special-category data is used.
• Vulnerable people are affected.
• Automated decisions have significant effects.
• Novel technology creates uncertain risks.
• Data from multiple sources is combined.
• Behaviour is monitored.
• Biometric data is used.

73. Microsoft Responsible AI principles​

Microsoft identifies six Responsible AI principles:

1. Fairness.
2. Reliability and safety.
3. Privacy and security.
4. Inclusiveness.
5. Transparency.
6. Accountability. (Microsoft)

Use these as engineering questions rather than slogans.

Fairness​

• Which groups may experience lower performance?
• What is the acceptable disparity?
• Which data imbalances exist?
• Can users challenge the result?

Reliability and safety​

• How does the system fail?
• What fallback exists?
• How is unsafe behaviour detected?
• Can actions be reversed?

Privacy and security​

• Is all collected data necessary?
• Where is it stored?
• Who can access it?
• How can it be deleted?

Inclusiveness​

• Is the system accessible?
• Does it work across languages and abilities?
• Are vulnerable users considered?

Transparency​

• Do users know they are interacting with AI?
• Are limitations communicated?
• Can decisions be explained appropriately?

Accountability​

• Who approves the system?
• Who monitors it?
• Who responds when harm occurs?
• Who can stop it?

Part Twenty-Three: Microsoft AI Governance and Security Services

74. Microsoft Purview​

Microsoft Purview provides data-governance, data-security and compliance capabilities.

Relevant areas include:

• Data Map.
• Unified Catalog.
• Data lineage.
• Classification.
• Sensitivity labels.
• Data Loss Prevention.
• Insider Risk.
• Audit.
• Records management.
• Data Security Posture Management for AI.

Purview is positioned as a portfolio for governing, protecting and managing data across enterprise and AI environments. (Microsoft Learn)

Purview for AI​

Use it to:

• Discover sensitive information.
• Apply classifications.
• Trace data lineage.
• Identify overshared content.
• Monitor AI data use.
• Apply DLP controls.
• Govern Copilots and other AI applications.
• Support evidence for regulatory reviews.

Purview DSPM for AI provides a central location for understanding and reducing data risks associated with AI applications, Copilots and agents. (Microsoft Learn)

75. Defender for Cloud AI posture management​

Defender for Cloud can support:

• AI workload discovery.
• AI Bill of Materials.
• Security recommendations.
• Internet-exposure identification.
• Attack-path analysis.
• Vulnerability detection in AI artefacts.
• Pre-deployment risk analysis.
• Runtime threat protection.

Its Data and AI security dashboard provides a central view of AI and data resources, sensitive-data insights, critical risks and protection status. (Microsoft Learn)

76. Azure AI Content Safety​

Azure AI Content Safety can analyse harmful content in text and images.

Use it for:

• Input moderation.
• Output moderation.
• Harm-category evaluation.
• Prompt Shields.
• Custom blocklists.
• Safety testing.
• Abuse reduction.

It should not replace:

• Business-policy enforcement.
• Access control.
• Prompt-injection threat modelling.
• Human oversight.
• Regulatory review.
• Secure output handling.

Content filtering is one defence layer, not the entire AI-security architecture. (Microsoft Learn)

77. Azure Machine Learning Responsible AI dashboard​

For traditional machine-learning models, the Responsible AI dashboard can support:

• Error analysis.
• Model interpretability.
• Fairness analysis.
• Data exploration.
• Causal analysis.
• Counterfactual analysis.

The dashboard and related scorecards help technical teams analyse model behaviour and communicate model and data insights to stakeholders. (Microsoft Learn)

Tooling does not replace governance judgement. A dashboard can reveal disparities, but the organisation must decide:

• Which cohorts matter.
• Which thresholds are acceptable.
• What remediation is required.
• Who approves residual risk.
• Whether the use case should proceed.

Part Twenty-Four: Secure Enterprise AI Reference Architecture

78. Architecture​

Security decisions​

• No public model endpoint unless explicitly justified.
• Managed identities instead of keys.
• Private endpoints for sensitive PaaS services.
• Tenant-aware retrieval.
• PII controls before model invocation.
• Content marked as trusted or untrusted.
• Tool allowlists.
• Deterministic authorisation.
• Human approval for consequential actions.
• Full correlation without uncontrolled sensitive logging.
• Prompt, model and policy versioning.
• Central security alerts.
• Auditable evidence.

Part Twenty-Five: AI Testing and Evaluation

79. Evaluation categories​

Functional​

• Task success.
• Correct format.
• Instruction following.
• Tool selection.
• Retrieval success.

Quality​

• Relevance.
• Completeness.
• Groundedness.
• Factuality.
• Coherence.
• Citation correctness.

Safety​

• Harmful content.
• Self-harm content.
• Sexual content.
• Violence.
• Hate.
• Illegal instructions.
• Unsafe professional advice.

Security​

• Direct injection.
• Indirect injection.
• Prompt extraction.
• Secret extraction.
• Data exfiltration.
• Tool abuse.
• Privilege escalation.
• Cross-tenant leakage.
• Malicious file handling.

Responsible AI​

• Fairness.
• Language performance.
• Accessibility.
• Explainability.
• Human oversight.
• User transparency.

Operational​

• Latency.
• Throughput.
• Availability.
• Retry behaviour.
• Fallback behaviour.
• Cost.
• Token usage.

Agentic​

• Plan correctness.
• Tool-call validity.
• Authorisation.
• Action reversibility.
• Approval compliance.
• Loop prevention.
• Memory isolation.

80. Release gates​

A system should not enter production until:

• An accountable owner exists.
• The use case is registered.
• Risk classification is complete.
• Architecture is approved.
• Data is approved.
• Threat modelling is complete.
• Privacy assessment is complete.
• Quality thresholds pass.
• Safety thresholds pass.
• Security tests pass.
• Human-oversight procedures are tested.
• Monitoring is configured.
• Incident runbooks exist.
• Rollback is tested.
• Cost limits exist.
• Support teams are trained.
• User disclosures are ready.
• Retirement conditions are defined.

Part Twenty-Six: AI Incident Response

81. AI incident categories​

Create specific categories for:

• Sensitive-data disclosure.
• Prompt injection.
• Unauthorised tool execution.
• Harmful output.
• Discriminatory outcome.
• Hallucination causing material impact.
• Model compromise.
• Data poisoning.
• Supplier incident.
• Copyright complaint.
• Excessive cost.
• Model outage.
• Cross-tenant leakage.
• Unauthorised shadow AI.
• Agent identity compromise.

Incident response process​

Containment actions​

• Disable model deployment.
• Revoke managed identity.
• Disable a tool.
• Block a user or application.
• Rotate secrets.
• Remove affected documents from retrieval.
• Roll back prompt version.
• Switch to fallback model.
• Disable external communication.
• Reduce agent permissions.
• Route all requests to human review.

Part Twenty-Seven: FinOps for Azure and AI

82. Azure cost management​

Microsoft Cost Management provides tools for analysing, monitoring and optimising cloud spending, including budgets and alerts. (Microsoft Learn)

Track:

• Subscription cost.
• Resource-group cost.
• Application cost.
• Environment cost.
• Team cost.
• Region cost.
• Unit cost.
• Idle cost.

Tagging standard​

Application       = finance-assistant
Environment       = production
BusinessOwner     = finance-transformation
TechnicalOwner    = ai-platform
CostCentre        = CC-401
DataClassification = confidential
RiskTier         = high
ManagedBy         = bicep

83. AI FinOps​

Track:

• Input tokens.
• Output tokens.
• Embedding tokens.
• Model choice.
• Requests per user.
• Cost per task.
• Cost per customer.
• Retrieval cost.
• Search cost.
• Vector-storage cost.
• Cache hit rate.
• Evaluation cost.
• Guardrail cost.
• Agent tool cost.
• Failed-request cost.

Optimisation techniques​

• Select the smallest model that meets quality requirements.
• Route simple and complex requests differently.
• Limit context size.
• Improve retrieval precision.
• Summarise long histories.
• Cache only safe and appropriate results.
• Batch embeddings.
• Remove duplicate documents.
• Apply user quotas.
• Stop infinite agent loops.
• Use asynchronous processing.
• Define model fallback.
• Set budget alerts.
• Attribute consumption to business units.

An AI solution is not commercially successful merely because it works technically. It must demonstrate acceptable unit economics.

Part Twenty-Eight: Enterprise Capstone Project

84. Scenario: governed financial-services AI assistant​

Build an internal finance assistant that can:

• Answer questions from approved policies.
• Analyse invoices.
• Summarise financial documents.
• Draft reports.
• Retrieve authorised customer information.
• Create case-management drafts.
• Escalate uncertain answers.
• Generate evidence-backed responses.
• Never transfer money autonomously.

Functional requirements​

• Entra authentication.
• Role-based document access.
• Source citations.
• PII redaction.
• Human escalation.
• Conversation history.
• Feedback.
• Administrative dashboard.

Non-functional requirements​

• UK GDPR alignment.
• AI risk assessment.
• Private networking.
• Zone resilience.
• Central monitoring.
• Full traceability.
• Defined RTO and RPO.
• Cost limits.
• Secure CI/CD.
• Model portability.

85. Capstone architecture​

Supporting services:

• Key Vault.
• Managed identities.
• Private endpoints.
• Purview.
• Defender for Cloud.
• Azure Monitor.
• Application Insights.
• Sentinel.
• Service Bus.
• Event Grid.
• Azure Policy.
• Azure Cost Management.
• Bicep.
• Azure DevOps or GitHub Actions.

86. Capstone delivery phases​

Phase 1: Discovery​

Produce:

• Problem statement.
• Stakeholder map.
• Current-state process.
• Expected benefits.
• Baseline metrics.
• Risk classification.

Phase 2: Governance​

Produce:

• AI use-case record.
• DPIA screening.
• AI impact assessment.
• Regulatory assessment.
• Responsible AI plan.

Phase 3: Architecture​

Produce:

• Context diagram.
• Container diagram.
• Data-flow diagram.
• Trust-boundary diagram.
• Identity model.
• Network model.
• Threat model.

Phase 4: Prototype​

Test:

• Model quality.
• Retrieval.
• Citations.
• PII controls.
• User experience.
• Cost assumptions.

Phase 5: Production engineering​

Implement:

• Private endpoints.
• Managed identities.
• API gateway.
• Monitoring.
• Scaling.
• Backup.
• CI/CD.
• Infrastructure as code.

Phase 6: Validation​

Run:

• Functional evaluation.
• Safety evaluation.
• Red teaming.
• Penetration testing.
• Privacy testing.
• Performance testing.
• Recovery testing.
• User acceptance.

Phase 7: Deployment​

Complete:

• Approval.
• Runbook.
• Support model.
• User training.
• Communications.
• Production release.
• Hypercare.

Phase 8: Operation​

Monitor:

• Quality.
• Safety.
• Security.
• Performance.
• Adoption.
• Costs.
• Risk indicators.
• User feedback.

Part Twenty-Nine: 24-Week Learning Plan

Weeks 1–2: Cloud and Azure fundamentals​

Learn:

• Cloud service models.
• Azure Regions and zones.
• Shared responsibility.
• Azure Resource Manager.
• Well-Architected Framework.

Deliver:

• Region decision record.
• Shared-responsibility matrix.
• Simple workload architecture.

Weeks 3–4: Resource governance​

Learn:

• Tenants.
• Management groups.
• Subscriptions.
• Resource groups.
• Azure Policy.
• Tags.
• Landing zones.

Deliver:

• Small management-group hierarchy.
• Policy initiative.
• Subscription design.

Weeks 5–6: Identity​

Learn:

• Entra ID.
• Azure RBAC.
• Managed identities.
• Conditional Access.
• PIM.

Deliver:

• Identity matrix.
• Managed-identity application.
• Privileged-access process.

Weeks 7–8: Networking​

Learn:

• VNets.
• Subnets.
• NSGs.
• Private endpoints.
• Firewall.
• NAT Gateway.
• Hub and spoke.

Deliver:

• Private application network.
• Network-flow diagram.
• DNS design.

Weeks 9–10: Compute and application platforms​

Learn:

• Virtual Machines.
• Scale Sets.
• App Service.
• Front Door.
• Application Gateway.

Deliver:

• Load-balanced web application.
• Autoscaling.
• Private data connection.

Weeks 11–12: Storage and data​

Learn:

• Blob Storage.
• Lifecycle policies.
• Azure SQL.
• Cosmos DB.
• Managed Redis.

Deliver:

• Secure document platform.
• Relational and NoSQL comparison.
• Backup test.

Weeks 13–14: Containers and serverless​

Learn:

• ACR.
• Container Apps.
• AKS.
• Functions.

Deliver:

• Containerised API.
• Event-driven worker.
• Container-platform decision record.

Weeks 15–16: Integration and observability​

Learn:

• API Management.
• Service Bus.
• Event Grid.
• Azure Monitor.
• Application Insights.

Deliver:

• Asynchronous workflow.
• Operational dashboard.
• Alerts and runbooks.

Weeks 17–18: Cloud security​

Learn:

• Defender for Cloud.
• Sentinel.
• Key Vault.
• Purview.
• Zero Trust.
• Azure Policy.

Deliver:

• Security baseline.
• Threat model.
• Sentinel detections.
• Private-service architecture.

Weeks 19–20: AI engineering​

Learn:

• Microsoft Foundry.
• Models.
• RAG.
• Agents.
• Search.
• Evaluation.

Deliver:

• Enterprise RAG prototype.
• Model-selection report.
• Evaluation dataset.

Weeks 21–22: AI security​

Learn:

• OWASP LLM risks.
• MITRE ATLAS.
• Prompt injection.
• PII.
• Agent security.
• AI runtime monitoring.

Deliver:

• AI threat model.
• Red-team tests.
• PII benchmark.
• Agent permission matrix.

Weeks 23–24: AI governance​

Learn:

• NIST AI RMF.
• ISO 42001.
• EU AI Act.
• GDPR.
• Responsible AI.

Deliver:

• AI governance framework.
• AI inventory.
• Risk-tier model.
• Lifecycle gates.
• Final capstone presentation.

Final Completion Checklist

You have completed the roadmap when you can confidently answer the following.

Azure architecture​

• Why did you choose VMs, App Service, Container Apps, AKS or Functions?
• What is the subscription and landing-zone model?
• Which services are zone redundant?
• What happens during regional failure?
• How is infrastructure recreated?

Identity​

• How do users authenticate?
• How do applications authenticate?
• How do agents authenticate?
• Where are privileged roles controlled?
• Are permanent credentials stored anywhere?

Networking​

• Which endpoints are public?
• Which are private?
• How is outbound traffic controlled?
• How is DNS configured?
• Can AI workloads access arbitrary external systems?

Data​

• What data is used?
• Why is it necessary?
• Who owns it?
• How is access controlled?
• How is it classified?
• How is it deleted?
• Is it used for training?

AI quality​

• Which evaluation dataset is used?
• What are the acceptance thresholds?
• How does performance vary across groups?
• How are hallucinations detected?
• How is user feedback incorporated?

AI security​

• How is prompt injection addressed?
• How are outputs validated?
• What permissions do agents hold?
• How is PII handled?
• How is the model supply chain verified?
• What happens during data leakage?

Governance​

• Who is accountable?
• What is the risk tier?
• Which approvals are required?
• Which regulations apply?
• Which evidence is retained?
• What changes trigger reassessment?

Operations​

• Which metrics indicate customer impact?
• Who responds to alerts?
• How can the model be disabled?
• What is the fallback?
• How is recovery tested?
• How is the system retired?

Commercial value​

• What business outcome is achieved?
• What is the baseline?
• What is the unit cost?
• What happens to cost when usage doubles?
• Which adoption and benefit metrics are tracked?
• Does the solution create measurable value after risk and operating cost are considered?

The result should be more than an Azure deployment. It should be a governed operating system for delivering AI: technically feasible, commercially valuable, secure by design, compliant, observable, recoverable and accountable.