The brief, and the architecture it maps to
A capstone is not a bigger lab; it is the thing you put on the table when an interviewer says "walk me through something you built." The brief reads the way a real one does: "Stand up a production-shaped web application — a public web tier, a private database, secrets in a vault, telemetry flowing, and a deploy that a stranger could trust. Not a demo. Something you would run." Every noun in that sentence is a class you have sat and a Build you have shipped; this Plate composes them into one repository with your name on the commits.
What makes it a capstone rather than a fifth Build is that it is measured against a published standard. Microsoft maintains a baseline reference architecture for exactly this workload — a network-secured, zone-redundant App Service web application — and this Plate is a deliberately scoped version of it.1 You are not inventing a shape; you are building the industry's shape at a size one person can finish and defend.
Microsoft Azure Architecture Center — Baseline highly available zone-redundant App Service web application. Read it before you start and keep it open: it is the production version of what you are building, and naming it in an interview signals you know where the real bar sits.
learn.microsoft.com/azure/architecture/web-apps/app-service/architectures/baseline-zone-redundant
- Deliverable
- One public GitHub repository: the infrastructure as code, the pipeline, and a README that walks a reviewer from the public URL to the private database and explains every layer between — with the reference architecture named as its north star and the scope honestly drawn.
Requirements — the ledger you build against
Each row is a component of the baseline architecture, the classes and Builds that taught it, and the evidence a reviewer will demand. Build in dependency order; the front door goes on last.
| # | Requirement | Taught in | Evidence |
|---|---|---|---|
| R1 | A VNet with dedicated subnets for the gateway, the app integration, and private endpoints — everything as Bicep, deployed by pipeline | Classes 10, 20 · Build III | The Bicep; the subnet plan and NSG rules in the README |
| R2 | The app on App Service, VNet-integrated, with deployment slots and a health-check endpoint; public network access disabled | Classes 11, 14 | A slot swap in the pipeline logs; the health endpoint returning real dependency status |
| R3 | A private data tier: Azure SQL Database reached over a private endpoint with public access disabled, and transparent data encryption on | Classes 12, 14, 38 | An nslookup from inside the VNet to the private IP; the app connecting keylessly |
| R4 | Application Gateway with WAF as the single public entry point — TLS terminated, prevention mode, Microsoft-managed ruleset, routing to App Service over a private endpoint | Class 13 | A blocked injection request in the WAF logs; end-to-end HTTPS proven |
| R5 | Key Vault holding the TLS certificate and app secrets, surfaced through Key Vault references and reached by managed identity — no stored credential | Classes 9, 31 | App settings showing vault references, not values; the identity's role assignment |
| R6 | Application Insights + a Log Analytics workspace, a diagnostic setting on every resource, and at least one meaningful alert with an owner | Classes 28–30 · Build IV | The application map; one alert that has fired; the workspace collecting all tiers |
| R7 | The pipeline: plan on pull request, deploy through slots on merge, an approval gate before production, authenticating by OIDC with no stored secret | Classes 22–24 · Build III | A run showing the gate and a keyless deploy; gh secret list empty |
| R8 | The README: the architecture diagram, the north-star link, the scope honestly drawn, and the walk from public URL to private row | Classes 18, 37 | The repository — the artifact an interviewer actually opens |
Build the industry's shape, at a size you can finish.
Two boundaries keep the Plate honest. Scope down deliberately, and say so: the enterprise baseline adds DDoS protection, three-plus gateway instances across zones, ZRS storage, self-hosted deployment agents in the VNet, and Azure Policy governance — each a paragraph in your README under "what the production version adds and why." Naming the gap is the senior move; pretending there is none is the junior tell. But do not scope out the load-bearing walls: the private data tier, the WAF, the keyless identity, and the gated pipeline are the architecture. Drop any of them and you have built a tutorial, not a platform.
The rubric — graded on the five pillars
Architects do not grade "does it work." They grade against the Azure Well-Architected Framework — five pillars, the same five Microsoft organises its own reference architecture under. Mark yourself on each; a capstone that scores evenly across all five reads as designed, not assembled.
- ReliabilityWAF pillar
- The app survives an instance failure — two or more App Service instances, a health check that reroutes, a database tier that can lose a component without losing data. Can you kill an instance and stay up?
- SecurityWAF pillar
- Defence in depth: WAF at the edge, private endpoints beneath, a keyless identity, a vault for secrets, and the data tier unreachable from the internet. The blast radius of any single failure is bounded, and you can name the bound.
- Cost optimisationWAF pillar
- You chose tiers on purpose and can defend the bill line by line — no oversized plan "to be safe," a tear-down story, and a README note on what the production version would cost and why.
- Operational excellenceWAF pillar
- Everything is code, shipped by a reviewed pipeline with a gate; nothing was clicked into production; the README lets a new hire deploy it. This is where Phase Three earns its keep.
- Performance efficiencyWAF pillar
- The app scales to demand — autoscale rules you set and can explain — rather than a fixed fleet sized by fear. Class Two's elasticity, made real and measured.
The single capping deduction, in this Plate's spirit: a stored secret anywhere — a connection string in config, a client secret in the pipeline, a storage key in a setting — fails the Security pillar outright, and a capstone that fails a pillar is not yet a capstone. The whole point of the résumé line is that it survives the scrutiny of someone who grades this for a living.
What an interviewer will ask
This Plate provokes architect-level questions, not trivia. Rehearse the answers aloud against your own diagram — the capstone is only finished when you can narrate it under mild pressure.
- "Draw me the request path."
- User to Application Gateway, WAF evaluates the rules, TLS terminates, the request routes over a private endpoint to an App Service instance, which reaches SQL and Key Vault over their own private endpoints resolved by private DNS. If you can draw it from memory, you have already out-performed most candidates.
- "Where does a secret live, and who can read it?"
- In Key Vault, surfaced as a reference, read by the app's managed identity through an RBAC role — nothing in config, nothing in the pipeline. The follow-up is the TLS cert: it lives in the vault too, and the gateway reads it by identity, not an access policy.
- "What in this is not production-ready, and what would you add?"
- Your scope note, out loud: DDoS protection, more gateway instances across zones, ZRS storage, self-hosted agents, Policy governance. Naming your own gaps unprompted is the highest-credibility move in the room.
- "An availability zone goes dark. What happens?"
- The Reliability answer: instances in the surviving zones keep serving, the gateway's remaining instances route around it, the zone-redundant database rides it out. If you tested this — even by scaling to a single instance and killing it — say so.
- "Why Application Gateway and not Front Door here?"
- Class Thirteen's grid: this is a regional workload, so a regional Layer-7 gateway with a WAF, inside the VNet, is the honest fit; Front Door earns its place when you go global. Answering by decision rule, not preference, is the architect tell.
The storefront, rebuilt as the thing you show
Campux's storefront has been assembled across the whole course — App Service in Class Eleven, private storage in Class Fourteen, the pipeline in Phase Three, the watch in Phase Four. This Plate is where a graduate rebuilds it as their own repository, from empty subscription to running platform, and writes the README that walks an interviewer from the public URL to a private database row. The four Builds were the rehearsals; this is the performance.2 When the Class Thirty-Seven interviewer asks "walk me through something you built," this is the tab you open — and because it is scoped to Microsoft's own baseline and graded on the five pillars, the walk survives every follow-up. Two servers in a closet, in Class One, became this. That arc is the résumé.
- The reference architecture and its component list, pillar organisation, and network flows are drawn from Microsoft's Azure Architecture Center, "Baseline highly available zone-redundant App Service web application," which ships with a working reference implementation on GitHub (Azure-Samples/app-service-baseline-implementation). Read the implementation after you build yours and compare — the gaps between them are your next study list. ↩
- "Twenty to thirty-five hours" assumes you built the four Builds first; the Plate is composition, not fresh learning, and most of the time goes into the pipeline wiring and the README, not the resources. If a component is taking days, you are learning it here that you should have learned in its class — go back to the class, then return. ↩