From Novice to Fluent on the Modern Microsoft Web Stack — 22-Chapter Self-Study Plan

Review and execution boundary

22-chapter study map; .NET 8/C#12 core, .NET9 HybridCache, React18/19, TypeScript5, Vite6 and provider-specific boundaries are called out in chapters.

Reviewed on 7 October 2026 against the official source snapshots linked below. The review is bounded editorial correction, not certification of every dependency, security property or cloud deployment. Historical setup commands and optional exercises were not executed. No cloud resources, third-party packages or external side effects were created. Old screenshots and unavailable private assets remain in the private recovery archive, not prerequisites for this lesson.

From Novice to Fluent on the Modern Microsoft Web Stack

An opinionated 22-chapter self-study plan for building and explaining applications with ASP.NET Core, React and Azure. This is a reference curriculum, not a claim about the implementation of any employer product or a guarantee of professional fluency.

Each chapter is a self-contained deep-dive (~30 minutes reading + a weekend of exercises). This hub is the map.

The whole production system in one picture

Start with a browser request rather than a list of products. Follow the top row from the client through the edge and API host to the data store; then read the lower row as supporting concerns such as identity and telemetry, not as additional serial hops. The chapters unpack these two kinds of responsibility separately.

Client Browser React 19 · TS

Edge Front Door / CDN TLS · cache · WAF

Host App Service Linux · Kestrel

App ASP.NET Core API min APIs · DI

Data Cosmos · Azure SQL primary store

Identity Entra ID tenant · app reg

Secrets Key Vault refs · certs

Auth Easy Auth · MI headers · IMDS

Analytics Kusto / ADX KQL queries

Observability App Insights logs · traces · metrics

Browser → Front Door → App Service → API → DB · KQL · AI

The whole production system, in one picture. Every chapter teaches one slice.

What each chapter delivers

The picture is a destination, not a setup checklist to complete on day one. First learn to explain and implement one request path; then use the exercises and self-checks below to add the platform responsibilities without losing that thread.

Sequenced lessons — Clear learning objectives, ordered to build on each other.

Depth notes — Good-enough-to-ship vs expert — know when to stop digging.

Hands-on exercises — No employer codebase needed — some exercises need a separately configured runtime or account; the conceptual route uses fixtures and design reviews.

Self-check questions — Verbal-mastery checks. If you can't answer them, you don't own it.

High-signal resources — Official docs first, then a book or canonical practitioner blog.

Weekly milestones — Pace yourself; the plan is a menu, not a calendar.

Capstone hooks — How each chapter shows up in the final analytics-dashboard project.

Pick your cadence

name: Sprint mode; tagline: ~4 weeks of weekdays; bullets: 1 chapter per evening — Weekends for exercises — Best if you have momentum

name: Weekend mode; tagline: ~11 weekends; bullets: 2 chapters per Saturday — Exercises on Sunday — Best if weekdays are busy

name: Job-prep mode; tagline: ~2 weeks; bullets: Front-load ch 3, 4, 5, 9, 10, 14, 15, 21 — Skip the rest until needed — Best if you have an design review booked

name: Deep-dive mode; tagline: ~22 weeks; bullets: One chapter per week — Full exercises + self-check — Best for true mastery

The 22 chapters

Phase 1 — Foundations

1. Developer tooling. PowerShell, Git's three trees, VS Code, DevTools, package managers.
2. Web fundamentals. HTTP, headers, cookies, TLS, REST, CORS, JSON.
3. C# language. Type system, LINQ, generics, async, records, pattern matching.
4. .NET runtime + async. CLR, GC, Task/ValueTask, cancellation, NuGet, global.json.
5. ASP.NET Core. Hosting, DI, middleware, routing, configuration, options, ProblemDetails.

Phase 2 — Frontend stack

6. Modern frontend baseline. Semantic HTML, a11y, CSS cascade + Flexbox + Grid, modern JS.
7. TypeScript. Structural typing, narrowing, generics, discriminated unions, utility types.
8. Frontend build tooling. Vite + HMR, bundling, tree-shaking, npm vs pnpm, env vars.
9. React. Components, hooks, rendering, effects, refs, error boundaries.
10. Routing + state in SPAs. React Router, URL-as-state, TanStack Query, Zustand.
11. Highcharts. Options model, series, axes, performance for high-cardinality data.

Phase 3 — Platform layer

12. Kusto / KQL. Pipeline syntax, summarize, joins, time-binning, injection defence.
13. Azure App Service. Plans, slots, app settings, Key Vault refs, networking, scale rules.
14. Identity for cloud apps. Entra ID, OAuth/OIDC, Easy Auth, Managed Identity, OBO flow.
15. Observability. Serilog, App Insights, correlation, OTel, KQL on telemetry.
16. Resilience patterns. Retry, timeout, circuit breaker, bulkhead, fallback, Polly v8 pipelines.
17. Caching. IMemoryCache, IDistributedCache, HybridCache, stampede protection.

Phase 4 — Delivery + cross-cutting

18. CI/CD with Azure DevOps. YAML pipelines, templates, SDL gates, federated identity.
19. IaC + rollout orchestration. Bicep, region rollouts, Ev2 / Argo / Spinnaker.
20. Security baseline. OWASP, secrets, transport, auth hardening, supply chain.
21. Testing. xUnit, WebApplicationFactory, Vitest, RTL, Playwright, contract tests.
22. Cross-cutting professional skills. Reading code, debugging, PRs, docs, on-call.

Capstone — Analytics Dashboard

Once chapter 17 lands, you have the application and platform concepts needed to start the capstone: an analytics dashboard that combines them in one project. Chapters 18–22 then add the delivery, security, testing, and operational work needed to make it production-minded.

Read the numbered cards as responsibilities, not eight sequential network calls. A chart request connects the React UI to the API and analytics data; identity controls access, while telemetry lets you follow that request when something fails.

1 · User Browser

2 · Edge Front Door WAF · TLS

3 · UI React SPA Vite · TS · TanStack

4 · API ASP.NET Core min APIs · Polly · cache

5 · Identity Entra ID OIDC · Easy Auth

6 · Metadata Azure SQL queries metadata

7 · Analytics Kusto cluster KQL · time-series

8 · Ops App Insights traces · logs · metrics

Propagate supported trace context across instrumented request boundaries; verify which dependencies actually emit linked spans. Application Insights operation_Id can represent correlation in its schema, but listing services does not automatically connect their telemetry.

Reference capstone responsibilities, not a deployed resource inventory. Start with one request path and add infrastructure only when a demonstrated requirement needs it.

The key distinction in that design is between metadata in Azure SQL and the time-series analytics queried through Kusto. Keeping those roles separate gives the dashboard a concrete reason to use each store, rather than adding services just to demonstrate them. The remaining ingredients support that same request path:

Stack ingredients (all introduced above):

Frontend — React 19 + TypeScript + Vite + TanStack Query + React Router + Highcharts.

Backend — ASP.NET Core minimal APIs + EF Core + Polly v8 + HybridCache + Serilog.

Auth — choose a coherent boundary: a same-origin server/BFF session through App Service authentication, or an SPA using authorization code with PKCE and an API validating access tokens. Managed identity authenticates backend calls to authorized Azure resources; it is not user authorization.

Data — Azure SQL for metadata, Kusto cluster for analytics queries the dashboard charts.

Ops — App Insights end-to-end correlation; structured logs; p99 latency alerts.

Delivery — Azure DevOps pipeline with templates; Bicep deploys two regions; staging slot + swap.

Security — SDL gates, signed commits, dependency scanning, no secrets in code.

Tests — xUnit + WebApplicationFactory + Vitest + RTL + one Playwright smoke per critical path.

Use the staged assessment below to bring together the repo layout, infrastructure design, delivery policy and chapter patterns. The task is a reference design that can first be assessed with local fixtures; it does not claim a supplied or deployed production application.

How to use this hub

Recommended reading flow

1. Skim every chapter title above so you know what's coming.
2. Open chapter 1 and read top-to-bottom.
3. Do at least 3 of the hands-on exercises before moving on.
4. Answer the self-check questions out loud (or to a friend). If you can't, re-read the chapter.
5. Repeat for chapter 2 onward.

The chapters build on each other — skipping ahead is fine if you already know the material (use the self-check questions to verify), but don't skip on the assumption that "I'll come back".

Start here

➡️ Chapter 1 — Developer tooling

Or jump to any chapter:

• Foundations: 1 · 2 · 3 · 4 · 5 (chapter reference; not linked while its review is pending)
• Frontend: 6 (chapter reference; not linked while its review is pending) · 7 (chapter reference; not linked while its review is pending) · 8 (chapter reference; not linked while its review is pending) · 9 (chapter reference; not linked while its review is pending) · 10 (chapter reference; not linked while its review is pending) · 11 (chapter reference; not linked while its review is pending)
• Platform: 12 (chapter reference; not linked while its review is pending) · 13 (chapter reference; not linked while its review is pending) · 14 (chapter reference; not linked while its review is pending) · 15 (chapter reference; not linked while its review is pending) · 16 (chapter reference; not linked while its review is pending) · 17 (chapter reference; not linked while its review is pending)
• Delivery: 18 (chapter reference; not linked while its review is pending) · 19 (chapter reference; not linked while its review is pending) · 20 · 21 (chapter reference; not linked while its review is pending) · 22 (chapter reference; not linked while its review is pending)
• Capstone: Analytics Dashboard — follow the assessment below; cloud execution is optional and reported separately.

Corrected contracts and failure analysis

The track retains tooling, HTTP, C#, runtime, ASP.NET Core, HTML/CSS/JS, TypeScript, build tools, React, routing/state, charts, KQL, hosting, identity, observability, resilience, caching, CI/CD, IaC, security, tests and engineering practice. Chapter 12 has a full KQL chapter plus the separately preserved exact windowing lab. Completion means you can explain a boundary, work an example and pass its negative cases, not simply visit every page.

The capstone is an analytics dashboard with a declared request/tenant model. Progress in slices: a typed local fixture; authenticated API with resource authorization; chart with correct denominators and missingness; resilient/cached queries; immutable build artifact; staged rollout and rollback exercise. Each slice adds a test rather than assuming later chapters supply safety magically. Actual cloud work is optional for the conceptual route and requires separately authorized resources, budget and access.

Boundary exercise with solution

A dashboard loads and looks correct. Which capstone questions remain before calling it a verified application?

Solution and reasoning

Can a wrong tenant access data? Does a timed-out write duplicate effects? Are p95 windows and sampling denominators correct? Does cache isolation include authorization? Do tests exercise failure paths? Is the promoted artifact identical to the tested one, and can rollback tolerate persisted schema changes? A passing homepage answers none of these.

Source-backed review notes

• Asynchronous programming scenarios - C# | Microsoft Learn — accessed 2026-10-07. Exact supporting passage: “CPU-bound code starts an operation on a background thread with the Task.Run method.”
• Access tokens in the Microsoft identity platform - Microsoft identity platform | Microsoft Learn — accessed 2026-10-07. Exact supporting passage: “An access token request involves two parties: the client, who requests the token, and the resource (Web API) that accepts the token. The resource that the token is intended for (its audience) is defined in the aud claim in a token. Clients use the token but shouldn't understand or attempt to parse it. Resources accept the token.”
• Pipeline deployment approvals - Azure Pipelines | Microsoft Learn — accessed 2026-10-07. Exact supporting passage: “Approvals and other checks aren't defined in the yaml file. Users modifying the pipeline yaml file can't modify the checks performed before start of a stage. Administrators of resources manage checks using the web interface of Azure Pipelines.”
• OWASP Application Security Verification Standard (ASVS) | OWASP Foundation — accessed 2026-10-07. Exact supporting passage: “The OWASP Application Security Verification Standard (ASVS) Project provides a basis for testing web application technical security controls and also provides developers with a list of requirements for secure development.”

Capstone assessment: from fixture to release decision

The fixture has two tenants and three observations: tenant A has request durations 100 and 900 ms; tenant B has 50 ms. A signed-in A user asks for a time range. Design the API contract, authorization decision, aggregate and chart before selecting Azure services.

Slice 1 — correct data and UI state

Use a typed response with explicit units, UTC timestamps and missing-value semantics. For the A fixture, count is 2 and arithmetic mean is 500 ms, not the all-tenant mean of 350 ms. Add empty, loading, success and failure states. A second request finishing before the first must not be overwritten by the stale first response. A keyboard user can select the range and read an equivalent data table without interacting with a chart.

Acceptance evidence: deterministic fixture expectations; a stale-response test; accessible name/focus checks; a screenshot is supplementary, not a substitute for assertions.

Slice 2 — identity and resource authorization

Separate proof of identity from permission to read A's rows. Validate the token for the API audience/issuer and check the tenant/resource policy before querying or returning cached data. A backend managed identity answers which workload is calling storage, not which human may see each row. Test missing credentials, wrong audience, wrong tenant, permitted reader and revoked access.

Acceptance evidence: a small decision table containing expected 401, refused access (403 or deliberately concealed 404), and authorized 200 outcomes. Never use a user-supplied tenant parameter as the source of authority.

Slice 3 — retries, caching and overload

Use a cache key containing authorization-relevant partition, query version, filters and time range; specify the stale-data budget. A timeout does not prove a write failed before committing. For saved-query writes, require atomic idempotency ownership and a stored result, or reconcile ambiguous results before retrying. Bound simultaneous query work and total retry time.

Acceptance evidence: cross-tenant cache isolation, concurrent duplicate-write and lost-response scenarios; overload fails in a defined way rather than growing an unbounded queue. A local fake can assess the protocol; it does not reproduce Azure service failover.

Slice 4 — promotion and rollback

Produce one immutable artifact digest, test that artifact, then promote the same bytes. Put environment approval outside editable application YAML when using Azure Pipelines resource checks. A backwards-incompatible database migration can make binary rollback unsafe: use expand/contract changes or a rehearsed recovery path. Record who decides rollback, which signal triggers it, and which persisted data the old binary can still read.

Worked decision: the new UI passes, but tenant B data appears in A's warmed cache. Reject promotion regardless of performance. If only optional chart rendering fails while the authorized table remains correct, assess the documented accessibility/availability criteria rather than silently redefining success.

Completion rubric: every slice has an explicit expected result and a negative case; every external-service claim has a matching official reference and version; every execution claim names what actually ran. A conceptual assessment and a cloud deployment assessment are separate deliverables, neither inferred from time spent studying.

Recovery source checks

• Access tokens in the Microsoft identity platform - Microsoft identity platform | Microsoft Learn: An access token request involves two parties: the client, who requests the token, and the resource (Web API) that accepts the token. The resource that the token is intended for (its audience) is defined in the aud claim in a token. Clients use the token but shouldn't understand or attempt to parse it. Resources accept the token.
• Pipeline deployment approvals - Azure Pipelines | Microsoft Learn: Approvals and other checks aren't defined in the yaml file. Users modifying the pipeline yaml file can't modify the checks performed before start of a stage. Administrators of resources manage checks using the web interface of Azure Pipelines.
• OWASP Application Security Verification Standard (ASVS) | OWASP Foundation: The OWASP Application Security Verification Standard (ASVS) Project provides a basis for testing web application technical security controls and also provides developers with a list of requirements for secure development.