Lab 01 — Platform Capstone: the Admission Gate

Phase: 15 — Principal Architecture, FinOps & Capstone | Difficulty: ⭐⭐⭐⭐☆ | Time: 4–6 hours

Every prior phase built one engine in isolation — the JWT validator (P03), the RBAC deny-wins evaluator (P04), the Azure Policy effect engine (P04), the SLA and cost arithmetic (P00/P14). This lab is the synthesis: compose them into one decision. A deploy request arrives, and before a single resource is created the platform must answer — in order — is the caller authenticated? authorized? does the resource comply? — and only then score it and emit the ADR. The gates fail closed (deny by default, the security posture the whole track defends); the scorecard is advice. A principal review is exactly this function run by a human; the lab makes the human's checklist executable.

What you build

  • Deployment / AvailabilityLink / CostLine — the validated request the platform admits or rejects, bundling identity claims, the RBAC ask, the resource's policy properties, the security-posture flags, the availability chain, and the bill.
  • check_identity(token, *, expected_iss, expected_aud, now) — a compact JWT-claims check (P03): iss / aud / exp / nbf with clock skew. Signature verification is assumed done upstream — the documented simplification.
  • check_authorization(principal, action, scope, assignments, role_defs, deny_assignments) — compact RBAC with deny wins and segment-aware scope containment (P04).
  • check_policy(resource, policies) — returns the list of policy violations (deny: and audit:) from a condition tree (P04); has_deny_violation is the reject test.
  • check_security_posture(deployment) — a 0..100 score that rewards Managed Identity, no stored secret, private networking, Key Vault, and CMK; penalizes public exposure + stored secrets (P12).
  • composite_sla(chain) / monthly_cost(resources) / downtime_minutes_per_month — the reliability and FinOps arithmetic (P00/P14): serial multiplies, redundant combines, the bill has a shape.
  • well_architected_score(deployment) — the five pillars 0..100 + overall, each derived from the engines above so the score is explainable (P15).
  • admit(deployment, platform_config) — the GATE. Reject on invalid token (401-like), unauthorized (403-like), or any policy deny (403-like); else admit with a Well-Architected scorecard and a generated one-paragraph ADR.

Key concepts

ConceptWhat to understand
Gates vs adviceidentity/authz/policy are hard rejects; the scorecard is reviewer advice
Fail closedevery gate denies by default — a malformed or missing claim is a no, not a maybe
Gate orderingauthentication (401) before authorization (403) before policy (403)
Deny winsa deny assignment overrides any role grant (P04) — the system's last word
Confused deputywrong aud is a reject — a token for service B must not work at service A
The review is a functionthe WAF review is repeatable: score each pillar from the evidence, write the ADR
The ADR is the artifactthe gate's output is a durable, auditable paragraph — not a vibe

Files

FilePurpose
lab.pyskeleton with # TODO markers and full signatures/docstrings
solution.pycomplete reference; python solution.py runs the worked example
test_lab.pythe proof — run it red, make it green
requirements.txtpytest only (pure stdlib otherwise)

Run

pip install -r requirements.txt
pytest test_lab.py -v                      # against your lab.py
LAB_MODULE=solution pytest test_lab.py -v  # against the reference
python solution.py                         # the worked example (admit + 3 rejects)

Success criteria

  • All tests pass against your implementation and the reference (LAB_MODULE=solution).
  • You can explain why test_admit_gate_order_identity_before_authorization expects 401, not 403 — authentication is checked before authorization (you can't be "unauthorized" if we don't yet know who you are).
  • You can explain why the secure deployment's weakest pillar in the ADR is reliability despite a 100/100 security score — a 99.89% serial SLA is only ~3 nines, and each extra nine is a different architecture, not a config flag.
  • You can take the worked-example admit() output and read its ADR aloud as a design review verdict: the decision, the numbers, and the pillar to revisit.

How this maps to real Azure

This lab is a faithful miniature of a real platform-engineering admission control, composed from the production mechanisms each phase taught:

  • check_identity is the claim half of what Microsoft Entra ID + APIM do on every call: validate iss/aud/exp/scp. Real validation also verifies the RS256 signature against the tenant's JWKS (by kid) first — we assume that's done at the edge and document it.
  • check_authorization is Azure RBAC evaluation: in-scope role assignments, Actions − NotActions with wildcards, and deny assignments win — the same algorithm ARM runs before any control-plane PUT.
  • check_policy is Azure Policy at create/update: the policyRule condition tree → effect (deny blocks the write; audit flags it). The "no public PaaS for PII" and "require HTTPS" denies are straight out of a real landing-zone baseline.
  • composite_sla / monthly_cost are the Well-Architected Reliability and Cost arithmetic you do before the review — serial ∏Aᵢ, redundant 1−∏(1−Aᵢ), the first-order bill.
  • admit is the shape of an Azure Policy deny + RBAC + Conditional Access pipeline, or a deployment-stack / gate in CI/CD (P08) that refuses a non-compliant plan — and, run by a human, it is the Well-Architected review.

The az/Terraform equivalents the miniature stands in for: az policy assignment create (the deny baseline), az role assignment create / az role definition (RBAC), Entra app registration + aud/scp (identity), and an Azure Policy deny-effect initiative assigned at the management-group scope (P05) so every subscription inherits the gate. The limit a real system adds that we don't: Policy evaluation is eventually-consistent on existing resources (a compliance scan), even though it's synchronous at write time.

Extensions

  • Add a well_architected_review(deployment, weights) that returns the deciding pillar (reuse P00's resolve_tradeoff idea) so the ADR can say "admitted, but cost-weighted reviewers should note…".
  • Add a DR dimension: an active_active: bool flag that doubles the redundant links and the egress cost line, then show the SLA gain vs the bill — quantify the active-passive ↔ active-active tradeoff (WARMUP Ch. 4).
  • Add required_scopes to check_identity and a per-action scope requirement, so the gate also enforces delegated-scope authorization (P09) — not just RBAC.
  • Make admit return a 409-style "needs remediation" soft-reject for audit violations above a threshold, distinct from the hard deny reject.

Resume / interview bullet

Built an end-to-end Azure platform admission gate that composes JWT claim validation, RBAC deny-wins authorization, Azure Policy deny-effect evaluation, SLA composition, and first-order cost modeling into a single fail-closed decision, emitting a Well-Architected five-pillar scorecard and a generated Architecture Decision Record — the executable form of a principal design review.