AZ-DEV-300: Capstone I — Build a Cloud-Native SaaS Application
About This Course
The DevTrack capstone: build TaskForge a production-grade multi-tenant SaaS application end to end. Compose everything you learned across AZ-DEV-100 through AZ-DEV-200 into one cloud-native system: Blazor Server on App Service, Azure Functions for background work, Azure SQL with Row-Level Security for tenant metadata, Cosmos DB with hierarchical partition keys for task documents, Service Bus for async commands, Entra External ID for tenant users, APIM for the public API, App Insights + OpenTelemetry for observability, and Bicep + GitHub Actions with OIDC for delivery. By the end you have deployed a real multi-tenant SaaS to Azure and can defend every architectural decision on cost, latency, security, and operations.
Course Curriculum
20 Lessons
AZ-DEV-300 M1L1 - Solution architecture for multi-tenant SaaS - service selection, tenancy patterns, and cost modeling
Requirements gathering for a cloud-native SaaS, C4 diagrams (Context / Container / Component), service selection based on constraints (latency, scale, cost, isolation), multi-tenant patterns (silo / pool / hybrid), and building a realistic cost model. Grounds the whole capstone in why-before-how.
AZ-DEV-300 M1L2 - Produce the TaskForge architecture doc, service map, cost estimate, and risk log - Lab Exercises
Note: This lab pre-provisions Azure resources at start — allow up to 15 minutes for the environment to become ready before beginning the exercises.
Produce a real deliverable: TaskForge's C4 diagrams (Context / Container / Component), a per-service selection matrix with justification, a cost estimate at 10k tenants, and a risk log. Peer-review with a printable checklist. Output is committed markdown + Mermaid + Azure Pricing Calculator screenshot references.
AZ-DEV-300 M2L3 - Landing zone design for a single workload - Bicep modules, deployment stacks, and environment topology
Landing-zone concepts scoped to a single SaaS workload. Baseline resources (resource groups, VNet + subnets, Key Vault, App Configuration, App Insights, Log Analytics), private-registry Bicep modules, deployment-stack per-environment lifecycle, naming + tagging strategy that survives audits.
AZ-DEV-300 M2L4 - Deploy the TaskForge landing zone to dev, test, and prod via Bicep modules and deployment stacks - Lab Exercises
Note: This lab pre-provisions Azure resources at start — allow up to 15 minutes for the environment to become ready before beginning the exercises.
Publish Bicep modules to a private ACR registry, wire the TaskForge orchestrator template that references them, and deploy the landing zone to dev, test, and prod using deployment stacks. Verify with az stack sub list and az deployment stack show. Prove drift detection catches out-of-band changes.
AZ-DEV-300 M3L5 - Data layer design - Azure SQL with RLS for tenant metadata, Cosmos DB hierarchical partition keys for task documents
Multi-tenant data modeling. Azure SQL with Row-Level Security for shared-DB tenant isolation on structured metadata. Cosmos DB NoSQL with hierarchical partition keys (/tenantId/projectId) for scalable document storage. When to embed vs reference. Cross-store consistency.
AZ-DEV-300 M3L6 - Build the SQL schema with EF Core 9 migrations and RLS, and Cosmos containers with hierarchical partition keys - Lab Exercises
Note: This lab pre-provisions Azure resources at start — allow up to 15 minutes for the environment to become ready before beginning the exercises.
Build TaskForge's SQL schema with EF Core 9 migrations, add SESSION_CONTEXT-driven RLS predicates, create Cosmos containers with /tenantId/projectId hierarchical partition keys, seed three test tenants (contoso-store, apex-fitness, riverside-clinic), and verify RLS blocks cross-tenant reads and Cosmos partition routing pins queries to a single physical partition.
AZ-DEV-300 M4L7 - Two-identity authentication - Entra External ID for tenant users, Entra ID for admin employees
The two-identity story every SaaS needs. Entra External ID for tenant users with self-serve sign-up + social IdPs. Entra ID (workforce) for admin employees behind a distinct app registration + app role. Multi-tenant JWT validation with tid claim mapping. Session management and token lifetimes.
AZ-DEV-300 M4L8 - Wire Entra External ID sign-up and Entra ID admin sign-in with role gating - Lab Exercises
Note: This lab pre-provisions Azure resources at start — allow up to 15 minutes for the environment to become ready before beginning the exercises.
Provision an Entra External ID tenant, configure a sign-up + sign-in user flow with Anchorline branding, wire the Blazor Server TaskForge front-end to it. Add a separate admin portal (Razor Pages) protected by Entra ID with a required TaskForge.Admin app role. Verify tenants can sign up and sign in, admins can sign into the portal, and tenants cannot.
AZ-DEV-300 M5L9 - Blazor Server on App Service with deployment slots, SignalR scale-out, and warm-up
Blazor Server as the SaaS front-end. App Service deployment slots for zero-downtime deploys with slot-specific configuration and slot warm-up. SignalR back-plane scale-out via Azure SignalR Service for real-time UI updates. Slot-swap rollback patterns.
AZ-DEV-300 M5L10 - Ship TaskForge Blazor Server to App Service with staging swap and rollback - Lab Exercises
Note: This lab pre-provisions Azure resources at start — allow up to 15 minutes for the environment to become ready before beginning the exercises.
Build the TaskForge Blazor Server UI (tenant dashboard, project list, kanban task board, task detail). Deploy to App Service with staging + prod slots. Wire the warm-up path. Ship v1 to staging, run smoke tests, swap to prod. Ship a v2 with a deliberate bug, detect via smoke tests, roll back via reverse swap. Verify zero requests dropped.
AZ-DEV-300 M6L11 - Command patterns with Service Bus and Azure Functions - queues, Durable Functions, correlation, and idempotency
Command-and-query separation via Service Bus queues + Azure Functions handlers. Durable Functions for long-running orchestrations (fan-out / fan-in, monitor, human-interaction). Correlation IDs across the front-end → SB → Function → UI-signal loop. Idempotency for at-least-once delivery.
AZ-DEV-300 M6L12 - Wire the SB command bus, Function handlers, Durable orchestration, and SignalR feedback - Lab Exercises
Note: This lab pre-provisions Azure resources at start — allow up to 15 minutes for the environment to become ready before beginning the exercises.
Every state-changing operation in the TaskForge UI publishes a Service Bus command. Function handlers process each command, update stores, and push results back via SignalR. Add a Durable Functions fan-out/fan-in orchestration for the weekly per-tenant report. Verify with a burst of 1000 concurrent operations — no dupes, no lost updates.
AZ-DEV-300 M7L13 - Public API tier with APIM v2 - JWT tenant isolation, subscription tiers, developer portal
The public API tier for TaskForge: minimal-API ASP.NET Core 10 behind APIM v2 (Standard v2). Versioning strategy, OpenAPI-driven import, JWT validation with External ID issuer + tenant claim, three subscription tiers (Free / Standard / Premium) with distinct rate limits + quotas, branded developer portal for tenant developers.
AZ-DEV-300 M7L14 - Publish the TaskForge public API through APIM with tenant JWT and tiered subscriptions - Lab Exercises
⚠️ Provisioning note: This lab pre-deploys Azure API Management, which may take 45 minutes or more before the lab is ready to use. Please be patient during startup — the lab will move to Ready as soon as the APIM instance is fully provisioned. This is Azure-side provisioning time and cannot be reduced.
Note: This lab pre-provisions Azure resources at start — allow up to 15 minutes for the environment to become ready before beginning the exercises.
Build the TaskForge public API (minimal-API .NET 10). Import into APIM v2. Configure validate-jwt matching the External ID issuer with tid claim required. Add three product tiers with distinct rate limits + monthly quotas. Customize the developer portal with Anchorline branding. Verify a new tenant developer can sign up, subscribe to Free, and make their first API call in under 5 minutes.
AZ-DEV-300 M8L15 - End-to-end observability - OpenTelemetry across services, SLOs, burn-rate alerts, service-health workbooks
End-to-end distributed tracing with OpenTelemetry across Blazor Server, Functions, SQL, Cosmos, Service Bus, APIM. SLO definition (99.5% availability, p95 < 500ms), SLO burn-rate alerts (fast + slow burn windows), team workbooks that answer "is TaskForge healthy right now?" in under 30 seconds.
AZ-DEV-300 M8L16 - Instrument TaskForge end-to-end with OpenTelemetry, define SLOs, and prove a 5-minute MTTR - Lab Exercises
Note: This lab pre-provisions Azure resources at start — allow up to 15 minutes for the environment to become ready before beginning the exercises.
Instrument the entire TaskForge stack with OpenTelemetry + Azure Monitor exporter. Define three SLOs (availability, latency, error rate). Configure fast + slow burn-rate alerts. Build a service-health workbook. Trigger a simulated incident (chaos-monkey style) and prove the workbook + trace view lets you root-cause in under 5 minutes.
AZ-DEV-300 M9L17 - Multi-environment CI/CD - GitHub Actions with OIDC, staged rollout, and rollback workflows
The full delivery pipeline. PR → build → test → dev deploy → integration tests → staged rollout to test → manual approval gate → prod. GitHub Actions with OIDC federated credentials. PSRule + Pester policy checks. Bicep what-if drift diffing. Post-deploy smoke tests. Rollback workflow.
AZ-DEV-300 M9L18 - Wire the full CI/CD pipeline with OIDC, gates, and rollback workflow - Lab Exercises
Note: This lab pre-provisions Azure resources at start — allow up to 20 minutes for the environment to become ready before beginning the exercises.
Wire GitHub Actions to Azure via OIDC federated credentials. Build the pipeline: unit tests → integration tests against dev → Bicep what-if against test → PSRule + Pester checks → staged rollout to test with smoke tests → manual approval gate → prod. Add a one-click rollback workflow. Ship a feature change end-to-end and demonstrate the rollback path.
AZ-DEV-300 M10L19 - Production readiness review - DR runbook, backup validation, cost model, security review (STRIDE-lite)
The pre-production gate. DR + backup + cost + security review checklist. Region-failure runbook. Backup validation (PITR test for SQL, Cosmos backup verify). Cost projection at 10k tenants across services. STRIDE-lite security review. Chaos-engineering basics. Runbook essentials for the on-call team.
AZ-DEV-300 M10L20 - Perform the TaskForge production readiness review and remediation plan - Lab Exercises
Note: This lab pre-provisions Azure resources at start — allow up to 20 minutes for the environment to become ready before beginning the exercises.
Execute a full production readiness review of TaskForge: run the DR failover runbook against a paired region, verify PITR restore for SQL and continuous backup restore for Cosmos, project cost at 10k tenants across App Service + SQL + Cosmos + SB + APIM + observability, complete a STRIDE-lite security review (no secrets in code, MI everywhere, least-privilege RBAC, Key Vault soft-delete + purge protection). Present the findings + remediation plan for stakeholder sign-off.