Skip to content
In this article
View as Markdown

Architecture Exercises and Design Reviews

Ten derivation exercises and eight graded design reviews, with answers

Last reviewed 13 October 2026 · 10 min read

How to use this page

Reading about architecture and doing it are different skills. This page is for the second. It has three parts: a mental model for each domain, ten derivation exercises, and eight design reviews graded from beginner to principal. Every answer is folded away. Write yours down before you open it; the gap between the two is the useful part.

One question per domain

If you remember nothing else from the atlas, remember these. Each is the question that opens up its domain in a review.

DomainThe question
Distributed systemsWhat happens when this component is slow, down, partitioned, duplicated or reordered, and who decides?
TimeWhich decision here depends on a clock, a TTL or a lifetime, and what if it's wrong by five minutes?
NetworkingWho can talk to whom, over what path, resolved by whose DNS, under what policy?
IdentityWho is the caller, who vouched for them, what may they do, for how long, and how is that revoked?
AuthorizationWhere is the decision made, where is it enforced, and how stale may it be?
DataWhere is the source of truth, what is derived, and how does change, including deletion, propagate?
DatabasesWhat must be atomic, what may be stale, and where is the hot key?
Compute and KubernetesWhich control loop reconciles this, and what keeps running if that loop stops?
SecurityIf an attacker holds this identity or this file, what can they reach next?
OperationsHow do we know it's healthy, what changed, and how do we undo it?
AIWhere does information enter, what can the model see, what can it do, under whose authority, and how do we know it was right?
Microsoft 365What permission state does the AI inherit, and which second decision says it may process it?
CostWhat scales with users, with tokens, with bytes, and with idle time?
LifecycleWhat will force this to change, and when?

Derivation exercises

Each asks what a single design decision brings with it. Reason it through, then compare.

D1. A centralised API gateway: what new dependencies?

Show the answer

The gateway's own configuration pipeline, which is now a global configuration blast radius. Its certificates and PKI. The identity provider's JWKS, for validating tokens. Its DNS name. Its rate-limit store, which is state. Its logging pipeline. And its scaling control plane. It becomes Tier-1 or Tier-0, and needs bulkheads, more than one region and a last-known-good configuration.

D2. Multi-region active-active: what new consistency problems?

Show the answer

Concurrent writes and lost updates. Conflict resolution, where last-writer-wins needs clocks, so skew matters. Uniqueness constraints across regions. Read-your-writes across regions. Sagas that span regions. Replication lag as your RPO. Split brain under a partition. And inter-region egress cost.

D3. AI retrieval over SharePoint: what new authorization problems?

Show the answer

Capturing ACLs from broken inheritance and sharing links. Group expansion and nesting. Sync lag, which is your revocation window. Gaps in label coverage for Decision 2. Deleted or moved items lingering in the index. Ranking before authorization. Summaries that mix items with different labels. And the identity that grants permissions becoming Tier-0.

D4. Self-hosting a model: what new operational responsibilities?

Show the answer

GPU capacity and quotas. Patching drivers, CUDA and the runtime. DRA and queue scheduling. KV-cache and batch tuning. Weight provenance and licensing. Safety filters. Evaluation for every version. On-call for Xid errors and out-of-memory. Isolation between tenants, with no shared prefix cache. And GPU capacity in the disaster-recovery region.

D5. Private endpoints everywhere: what networking dependencies?

Show the answer

Private DNS zones, and who owns them. Resolvers and conditional forwarders from on-premises. Limits on zone links. An endpoint per region per service, each billed by the hour. DNS as a single point of failure. Much harder troubleshooting. And exfiltration through other tenants' endpoints unless endpoint policies exist.

D6. Workload identity federation everywhere: what if the identity provider fails?

Show the answer

New token exchanges fail. Workloads holding valid cached tokens carry on until they expire, so token lifetime sets how long they survive. Deployments from CI to the cloud stop. Recovery tooling that uses the same federation fails too. You need break-glass workload credentials stored offline, monitored, and scoped to recovery.

D7. Introducing Kubernetes: what new control planes and failure domains?

Show the answer

The API server and etcd, with its quorum. Admission webhooks, which are write-path dependencies. Controllers and operators, whose reconciliation bugs act on the whole cluster. The CNI and CoreDNS, which are a network plane. The registry, on the pull path. Cloud integration controllers for load balancers and volumes. And upgrade skew. Each cluster is a failure domain.

D8. Going multi-cloud: what gets duplicated?

Show the answer

IAM models and policies. Network constructs. KMS and key policies. Logging and SIEM pipelines. IaC providers. Landing zones. Guardrails. Cost data, which FOCUS helps with. Skills and runbooks. And incident processes.

D9. Asynchronous events: what consistency problems?

Show the answer

Windows of eventual consistency. Duplicates. Reordering across partitions. Late data. Poison messages, which need a dead-letter queue and replay tooling. Schema evolution. Dual writes without an outbox. Sagas that need compensations. And users who don't see their own write.

D10. Caching authorization results: what security problem?

Show the answer

Revocation delay, which is the revocation window. Cache-key errors, such as caching by user but not by resource or context. Cross-tenant cache poisoning. Stale group membership. And failing open by serving stale entries during an outage, unless that is bounded. The mitigations: event-driven invalidation, a short TTL scaled to sensitivity, and never caching an allow for an irreversible action.

Design reviews

Each describes a design with something wrong with it. Find what's wrong before you read the answer.

R1 (Beginner)

A web application runs in two zones behind a load balancer. The database is a single primary with nightly snapshots to the same account. Identify the flaws.

Show the review
  • The single database primary is a single point of failure.
  • Snapshots in the same account and key domain aren't backups.
  • No RPO or RTO is stated, which is a missing requirement.
  • Two zones need double capacity to be statically stable.
  • The dependency on the regional control plane hasn't been examined.
  • Fix: a synchronous standby in the second zone, immutable cross-account backups under separate keys, and restore drills.

R2 (Beginner)

A team stores an Azure Blob SAS token, valid for one year, inside a mobile app, so the app can upload files. What's wrong?

Show the review
  • A year-long SAS is a bearer credential embedded in a binary anyone can download, and it can't be revoked without rotating the account key.
  • It bypasses identity entirely.
  • Fix: a short-lived user-delegation SAS, minted by a backend after the user has signed in, scoped to a single blob path, with minimal permissions and a short expiry.

R3 (Intermediate)

A RAG platform indexes every SharePoint site using an application identity holding Sites.Read.All, and filters results in the app by the user's email domain. Find the gaps in the requirements and the flaws in the design.

Show the review
  • Application-level Sites.Read.All gives the indexer tenant-wide access, which makes the index a Tier-0 data store.
  • Filtering by email domain isn't authorization. It ignores ACLs, broken inheritance, groups and labels.
  • There's no revocation window, no deletion propagation and no Decision 2.
  • Fix: Sites.Selected or delegated retrieval, ACL capture with late verification, label-aware processing, and storage classification set to the maximum of the sources.

R4 (Intermediate)

A Kubernetes platform enforces image signing with a validating webhook (failurePolicy: Fail) that runs inside the same cluster, with two replicas on one node pool. What's the failure mode?

Show the review
  • If the webhook's pods fail, for instance in a node-pool outage, all pod creation is blocked, including the webhook's own replacement pods. That's recovery coupling.
  • Fix: exempt the webhook's namespace, spread replicas across pools and zones, consider an out-of-cluster or managed policy service, and alert on webhook latency.

R5 (Advanced)

A multi-region active-active payments API uses last-writer-wins on account balances. Region clocks are synchronised with default NTP. Retries happen at the client, the gateway and the service, three each. Analyse it.

Show the review
  • Last-writer-wins on balances loses updates. Money needs single-writer ownership or consensus.
  • Last-writer-wins depends on clocks, and default NTP skew can reorder writes.
  • Three layers of three retries amplify load up to 64 times, and without idempotency they produce duplicate debits.
  • Fix: partition ownership by account, use idempotency keys, retry at one layer with a budget, and either design conflict-free or accept a globally consistent store and its commit latency.

R6 (Advanced)

An agent platform uses a single Entra agent identity blueprint, with a client secret, for every agent: HR, finance and IT. The MCP servers are stateless. The payment tool has no idempotency key. Analyse it.

Show the review
  • A single blueprint secret is one credential that can mint tokens for every agent in every domain.
  • Microsoft's guidance is not to use secrets in production.
  • The blast radius spans HR, finance and IT.
  • Stateless MCP plus re-issue on a broken stream makes duplicate payments likely.
  • Fix: a blueprint per agent type and data domain, each with a managed identity's federated credential; an idempotent payment tool; fail-to-manual approvals; and anomaly detection on token issuance.

R7 (Principal)

A bank's "sovereign" AI design uses an EU model region and an EU index, with a US-hosted SaaS observability backend that captures full prompts. Failover routes to the nearest healthy region anywhere in the world. The identity provider is a global SaaS. Identify every residency and dependency violation, and the principles for a redesign.

Show the review
  • Prompts in US telemetry are derived data that violate residency.
  • Failing over to the nearest region globally violates residency, so failover has to be constrained to the EU, or degrade.
  • The global SaaS identity provider is a dependency outside the sovereign boundary. Decide whether to accept it with documented terms for support access, or add a fail-static path.
  • Also check where the KMS keys live, who has support access, where evaluation datasets are kept, and where backups go.
  • Principle: residency binds every hop, including telemetry, fallback, backups and administrators.

R8 (Principal)

After an acquisition, the enterprise plans a tenant-to-tenant Microsoft 365 migration while also rolling out Copilot. The acquired tenant uses Restricted SharePoint Search. List the technical risks and the order the work has to happen in.

Show the review
  • Remapping object IDs breaks ACLs, Graph grants, agent identities and labels.
  • RSS settings don't migrate, and RSS is retiring, so the acquired tenant's restrictions may simply vanish.
  • Copilot over the merged tenant exposes the acquired tenant's permission debt.
  • Coexistence spans two identity providers (cross-tenant access, B2B), and the two DLP estates have to be reconciled.
  • Order: permission remediation and labelling, then RCD and DLP in the target tenant, then identity and content migration, then index rebuild, then Copilot enablement. Measure the revocation window throughout the coexistence period.

The architect's question framework

The full set of questions, grouped. Use it as a checklist for a design review.

  • State and truth. What is the source of truth? What is derived? How does change, including deletion, propagate? What is stateful, and where is the state kept?
  • Identity. Who is the caller? Who vouched for them? Which audience? For how long? How is it revoked, and what is the revocation window? What if an attacker holds this credential? Who can grant permissions?
  • Authorization. Where is the PDP, and where is the PEP? Before or after ranking? Which policy version decided? What is the fail mode?
  • Failure. What is the failure-domain vector? What is shared? What if it's slow rather than down? What happens on retry or replay? What is the idempotency key? What fences a stale leader?
  • Control and data plane. What keeps working if I can't change anything? Does serving call a control-plane API?
  • Configuration. What if this configuration reaches every region in seconds? Who produces it, including indirect producers? How is it validated: schema, size, the real consumer? How is it rolled back, and what is the last known good?
  • Network and DNS. Who owns this DNS zone? What is the TTL, and what ignores it? Is routing symmetric? Does egress have an allow-list?
  • Time. Which clocks, TTLs, leases and lifetimes matter? What if skew is five minutes?
  • Observability. How do I see it from outside? Can I page someone if the platform is down? Do logs leave the jurisdiction?
  • Recovery. What is the restore order? Are credentials and keys separate? When was it last tested? Is there capacity in the DR region?
  • Change over time. What is the lifecycle state? Which deprecations are scheduled? What changes if residency becomes mandatory, latency gets ten times worse, traffic grows a hundredfold, or the provider disappears?
  • Cost. What scales with users, tokens, bytes or idle time? What is the unit metric?

Should you have any questions regarding this page, please contact us at solutions@alesanalytics.com.

Next steps

Diagrams use the official Microsoft Azure, Microsoft Entra, AWS and Google Cloud architecture icons, as each vendor permits for documentation, and the Kubernetes icon set by the Kubernetes Authors under CC-BY-4.0. Product names are trademarks of their owners.