Deliverables

The curriculum covers what an architect should know. This covers what an architect actually hands over: 55 artifacts, each with a worked example, a note on when it is worth producing, who reads it, and the ways it usually goes wrong. Filter by the artifact's type, the kind of engagement that calls for it, the stack or industry it is drawn against, or the audience it is written for.

Identify the deliverable → 42 diagrams, shown one at a time with the answer withheld. Nothing to submit.

5 of 55 deliverables shown.

sequenceDiagram
  autonumber
  participant B as Browser
  participant A as App / BFF
  participant I as Identity Provider
  participant R as Resource API

  B->>A: GET /protected
  A-->>B: 302 to IdP (PKCE challenge, state, nonce)
  B->>I: authorise request
  I->>B: authenticate + MFA
  I-->>B: 302 back with authorisation code
  B->>A: code + state
  Note over A,I: back channel — browser never sees these
  A->>I: exchange code + PKCE verifier + client secret
  I-->>A: access token (10 min), refresh token, id token
  A->>A: store tokens server-side<br/>set HttpOnly SameSite cookie
  A-->>B: session cookie only
  B->>A: subsequent request + cookie
  A->>R: call with access token (Bearer)
  R->>I: fetch/refresh signing keys (JWKS, cached)
  R->>R: verify signature, issuer, audience,<br/>expiry, scope
  R-->>A: 200
  A-->>B: rendered response
  Note over A,I: on expiry the BFF refreshes<br/>with rotating refresh token

Security View

Authentication Flow Diagram

The exact token exchange between browser, application, authorisation server and API — including what is short-lived, what is bound and what never touches the browser.

Secure API Design Design

flowchart LR
  subgraph t4["Restricted"]
    direction TB
    a1["Card PAN · health records<br/>government ID images"]
    a2["<i>controls:</i> tokenise at edge<br/>field encryption · CMK<br/>no non-prod copies<br/>access JIT + approved<br/>full audit"]
  end
  subgraph t3["Confidential"]
    direction TB
    b1["Personal data · salary<br/>contracts · pricing"]
    b2["<i>controls:</i> encrypt at rest + transit<br/>masked in non-prod<br/>RBAC + quarterly review<br/>DLP on egress"]
  end
  subgraph t2["Internal"]
    direction TB
    c1["Operational metrics<br/>internal docs"]
    c2["<i>controls:</i> authenticated access<br/>standard retention"]
  end
  subgraph t1["Public"]
    direction TB
    d1["Published pricing<br/>marketing content"]
    d2["<i>controls:</i> integrity only"]
  end

  t4 --> s1[("Core DB · EU · Restricted")]
  t3 --> s1
  t3 --> s2[("Warehouse · EU · Confidential")]
  t2 --> s2
  t2 --> s3[("Object store · Internal")]
  t1 --> s3

Security View

Data Classification Map

Which data sits in which sensitivity tier, where it lives, and the specific controls each tier obliges — so protection follows the label automatically.

Data Classification Design

flowchart TB
  hsm[("HSM / Key Service<br/><i>root of trust · FIPS 140-2 L3</i>")]
  cmk["Customer Master Key<br/><i>per environment · rotate 1y</i>"]
  dek["Data Encryption Keys<br/><i>per dataset · rotate 90d</i>"]

  hsm --> cmk -->|"wraps"| dek

  subgraph vault["Secret Store"]
    direction TB
    v1["Static secrets<br/><i>rotate 90d</i>"]
    v2["Dynamic credentials<br/><i>DB · TTL 1h</i>"]
    v3["PKI issuer<br/><i>mTLS certs · TTL 24h</i>"]
  end
  cmk -->|"encrypts vault at rest"| vault

  subgraph wl["Workloads"]
    direction TB
    w1["Service A<br/><i>workload identity</i>"]
    w2["Pipeline<br/><i>OIDC federation</i>"]
  end

  w1 -->|"attests identity — no stored secret"| vault
  w2 -->|"short-lived token — no stored secret"| vault
  vault -->|"lease · auto-renew · revocable"| w1
  dek -->|"envelope decrypt"| w1
  audit[("Audit log<br/><i>every issue and revoke</i>")]
  vault --> audit

Security View

Key & Secret Management Diagram

Where keys and secrets live, what wraps what, how workloads get them without a stored credential, and how rotation actually happens.

Secrets Management Design

flowchart LR
  user(["Customer<br/><i>untrusted</i>"])
  admin(["Admin<br/><i>privileged</i>"])

  subgraph edge["Boundary 1 — public edge"]
    cdn["CDN / WAF"]
  end

  subgraph app["Boundary 2 — application tier"]
    direction TB
    api["Order API"]
    auth["Auth Service"]
  end

  subgraph datab["Boundary 3 — data tier"]
    direction TB
    db[("Order Store<br/><i>PII + card token</i>")]
    kms[("Key Vault")]
  end

  ext["Payment Provider<br/><i>third party</i>"]

  user -->|"F1 HTTPS"| cdn
  cdn -->|"F2 HTTPS + mTLS"| api
  admin -->|"F3 admin console"| api
  api -->|"F4 token introspection"| auth
  api -->|"F5 TLS + parameterised"| db
  api -->|"F6 fetch DEK"| kms
  api -->|"F7 HTTPS outbound"| ext
  ext -->|"F8 webhook — signed"| cdn

Security View

Threat Model Data Flow Diagram

Processes, stores and flows with trust boundaries drawn across them, so that every boundary crossing can be enumerated for threats.

Threat Modelling Design

flowchart LR
  u1(["Employee<br/><i>managed laptop</i>"])
  u2(["Contractor<br/><i>unmanaged device</i>"])
  u3["Workload<br/><i>service identity</i>"]

  subgraph pep["Policy Enforcement"]
    direction TB
    px["Proxy / Gateway<br/><i>terminates every session</i>"]
  end

  subgraph pdp["Policy Decision"]
    direction TB
    eng{"Policy engine"}
    sig1["Identity + MFA"]
    sig2["Device posture"]
    sig3["Risk + location"]
    sig4["Resource sensitivity"]
    sig1 --> eng
    sig2 --> eng
    sig3 --> eng
    sig4 --> eng
  end

  subgraph res["Resources"]
    direction TB
    r1["Internal app"]
    r2[("Database")]
    r3["SaaS"]
  end

  u1 --> px
  u2 --> px
  u3 --> px
  px <-->|"authorise this request"| eng
  px -->|"allow · scoped · time-bound"| r1
  px -->|"allow · read-only"| r2
  px -->|"deny · posture fail"| r3
  log[("Decision log<br/><i>every allow and deny</i>")]
  eng --> log

Security View

Zero Trust Architecture Diagram

Access decided per request from identity, device and context rather than from network position, with the policy decision point drawn explicitly.

Network Security Design