Skip to main content

Module Quiz

Complete this quiz after finishing all concept and practice pages.

Current Module Questions​

Question 1: Architecture vs Design Decision​

For each, classify as architecture or design and justify in one sentence:

  • (a) switching the orders service from REST to gRPC for inter-service calls
  • (b) renaming an internal helper function
  • (c) adopting OpenTelemetry across all services

Answer:

  • (a) Architecture. External-facing protocol with blast radius across all callers; high reversal cost.
  • (b) Design. Local to the file; no external impact; trivially reversible.
  • (c) Architecture. Cross-team standardization; externalized constraint (every service must adopt).

Question 2: Reversibility​

Your team is choosing a feature-flag service. Two candidates: a self-hosted open-source option, a SaaS vendor. Classify the decision as one-way or two-way, and explain what to put in the ADR.

Answer: Two-way (typically). Feature flags have well-defined APIs, and most SDKs are swappable in a day or two of engineering. The ADR should state the classification explicitly so the review does not over-weight this decision, and should name the conditions under which reversal becomes expensive (e.g., if the choice propagates to tens of thousands of flag references with vendor-specific semantics).

Question 3: ADR Critique and Rewrite​

Critique this ADR excerpt and rewrite the weakest section.

ADR-0089: Adopt Kafka

Status: Accepted

Context: We need a message broker.

Decision: Use Kafka.

Consequences: Enables event-driven architecture. Industry standard.

Answer: All three sections are thin. Context names no forces or alternatives. Decision is a verb+noun but no how or where. Consequences are cheerleading - no negatives, no risks. Rewrite:

Context: The orders service and three downstream consumers need decoupling; current direct HTTP calls create cascading failures during billing outages. Alternatives considered: RabbitMQ (rejected: no log-based replay), SQS (rejected: throughput caps for our projected volume), in-house queue (rejected: operational cost).

Decision: Adopt Kafka (self-managed on 3 brokers, replication factor 3, 7-day retention). Cutover behind a dual-publish flag.

Consequences:

  • positive: durable, replayable log; decoupled consumers; horizontal scale
  • negative: operational burden of running Kafka; team needs training
  • risk: ops on-call load during Q2; analytics pipeline must adopt Protobuf (blocker if not resolved)
  • classification: one-way door - once consumers are live, migration is a multi-quarter effort

Question 4: Template Choice​

A team is deciding between four CI providers. Which template fits and why?

Answer: MADR. Four live alternatives means the "Considered Options" section does real work. Nygard permits prose that hides the comparison. A Y-statement is useful as a one-line summary but not as the full record.

Question 5: Status Transition​

You wrote ADR-0012 ("use DynamoDB for sessions") two years ago; now you want to switch to Aurora. Which ADR changes, how, and in what order?

Answer:

  1. Draft ADR-0071 (new): context links back to ADR-0012, decision states Aurora with the operational specifics, consequences name migration cost and the superseding.
  2. On acceptance of ADR-0071, update ADR-0012 status to Superseded by ADR-0071 (YYYY-MM-DD). Do not edit ADR-0012's Context, Decision, or Consequences.
  3. Optionally add a one-line top note on ADR-0012: "See ADR-0071 for the current decision."

Question 6: ATAM Vocabulary​

Define sensitivity point and tradeoff point. Give one example of each.

Answer:

  • Sensitivity point: a property of a decision that materially affects one quality attribute. Example: the choice of hash function in a rate limiter is a sensitivity point for throughput.
  • Tradeoff point: a property that affects two or more attributes in opposing directions. Example: running the checkout service and orders service on a shared database helps latency (no network hop) and hurts availability (shared fate).

Question 7: Risk-Driven Review​

Why is "we review every architectural change with the same depth" a failure mode?

Answer: It violates proportionality. Low-risk changes waste review effort that should have been spent on high-risk ones. The result is either review fatigue (teams tune out) or a bottleneck (the review team becomes the limit). Risk-driven review allocates effort by risk; this is how you spend review time without blocking delivery.

Question 8: Lightweight Peer Review​

A team has a culture of "two LGTMs and merge." Why is this a weaker signal than it looks?

Answer: Because neither reviewer is required to engage with the substance. LGTM can be produced without reading Context or Consequences. A healthier protocol requires at least one reviewer to leave a substantive comment on an alternative, a consequence, or a risk - something that could only be written after real engagement.

Question 9: Review Preparation​

A manager sends a meeting invite titled "Architecture decision discussion" with 10 attendees and no pre-read. Predict three things that will go wrong.

Answer: (1) Participants will not share the same understanding of the question the meeting is answering. (2) The conversation will default to rehashing familiar positions from the hallway; no new information surfaces. (3) No durable artifact will result; a follow-up meeting is likely needed. The fix: a one-page pre-read, an explicit participant list with required / optional / cc labels, a 3-5 question agenda, and an expected-output statement.

Question 10: Facilitation​

Your review is 15 minutes in. A senior engineer interjects with: "Look, this is the wrong approach. Kafka is overkill. Why aren't we just using SQS?" How should the facilitator respond?

Answer: Name the phase. "That's a judgment - let's hold it until the judgment round in about 10 minutes. For now, is there anything about the Context or the constraints you'd like to ask about?" This does not silence the engineer; it sequences the contribution. When the judgment round arrives, the question returns with more shared context, and is more productive.

Question 11: Fitness Function Design​

A claim in an ADR reads: "No module may have cyclic dependencies." Propose a fitness function: shape, tooling, where it runs, exemption path.

Answer:

  • Shape: static code analysis.
  • Tooling: ArchUnit (Java), dependency-cruiser (JS/TS), or custom AST script.
  • Where it runs: PR CI. Fails the build on violation. Also runs as a scheduled nightly check on main to catch direct-commit bypasses.
  • Exemption path: per-annotation @SuppressArchRule("cycle", reason, expires) with an expiration date. Active exemptions listed on a dashboard. Unexpired exemptions reviewed each quarter; expired ones re-break the build.

Question 12: Drift Audit​

Your team finds a service calling another team's database directly, despite an ADR forbidding it. What type of drift is this, and what should you do?

Answer: Implementation drift. The ADR is still correct; the code has diverged from it. The response is:

  1. File a drift ticket; do not edit the ADR.
  2. Remediate the code to align with the decision.
  3. Write (or improve) a fitness function that would catch the same bypass in CI.
  4. Optionally, add a dated addendum to the ADR's Consequences describing the bypass history, if it is instructive.

Question 13: ADR Critique and Rewrite​

Critique and rewrite the Consequences section of this ADR.

ADR-0045: Adopt Feature Flags

Consequences: We will be able to ship faster. Developers will be happy. This is best practice.

Answer: Classic "decisions without consequences": all positive, no negatives, no risks. Rewrite:

Consequences:

  • positive: decouples deploy from release; enables A/B testing; faster rollback
  • positive: reduces the cost of trunk-based development
  • negative: codebase complexity increases (dead branches behind flags); flag cleanup becomes a new responsibility
  • negative: observability must distinguish flag state in logs and traces
  • risk: flag-based bugs are reproducible only if the flag state at failure time is captured; incident runbooks need updating
  • risk: vendor outage affects flag evaluation - need a fallback default
  • classification: two-way door, but only if flag count is disciplined; otherwise it calcifies into a one-way door over a few quarters

Question 14: ADR Bureaucracy Risk​

An organization mandates ADRs for every PR above 100 lines. Predict the failure modes.

Answer:

  • Noise. ADRs for trivial changes dilute the record; readers stop trusting that "there is an ADR" means "there is a real decision."
  • Template fatigue. Authors copy-paste stub ADRs to satisfy the rule, producing documents with no load-bearing content.
  • Avoidance. Authors split PRs below the line threshold to avoid the overhead.
  • Inversion. Architects review low-risk 100-line changes and miss a multi-hundred-line architectural change because it slipped under the threshold (e.g., a new service stub introduced as a package).

The fix is not "fewer rules" but better rules - tied to blast radius and reversal cost, not to line count.

Question 15: Community of Practice Failure​

A company appoints an "Architecture Review Board" that must approve all architecture decisions. Predict the failure modes.

Answer: Bottlenecking (teams wait for scarce approver time); ivory-tower drift (board loses touch with actual implementation); routing-around (teams redefine decisions as "design" to escape review); ossification (decisions take weeks, so teams stop proposing them). The alternative is a guild with no approval authority but strong support (rotating peer reviewers, shared templates, drift audits), leaving decision authority with individual teams.

Interleaved Review Questions​

Prior Module Question 1 (S7 Module 1: Architecture Fundamentals & Quality)​

What is a quality attribute, and why is it the right unit for a scenario in an ATAM utility tree?

Answer: A quality attribute is a non-functional property of the system (availability, performance, modifiability, security, etc.). It is the right unit for scenarios because it can be measured, whereas vague claims like "good performance" cannot be tested or traded off. ATAM scenarios always take the form "under stimulus X, the system exhibits measurable response Y."

Prior Module Question 2 (S7 Module 2: Patterns & Modular Architecture)​

Give one example where the choice of architecture pattern (layered, event-driven, microkernel, etc.) is a tradeoff point between two quality attributes.

Answer: Event-driven architecture: gains availability (consumers can be down without blocking producers) and throughput; loses debuggability (hard to follow a request across async hops) and transactional consistency (no cross-service transactions). Naming this as a tradeoff point during an ADR prevents the later surprise that "we can't do a single-hop query anymore."

Prior Module Question 3 (S7 Module 3: DDD & Bounded Contexts)​

How does a bounded context relate to an architecture decision about service boundaries?

Answer: A bounded context defines where a particular domain model and its ubiquitous language hold. An architectural decision about service boundaries should generally align with bounded context boundaries; failing to do so couples services whose domain models disagree, producing translation headaches on every call. An ADR proposing a service that spans bounded contexts is a red flag and should be challenged during review.

Prior Module Question 4 (S7 Module 4: API Design & Contract Evolution)​

Why is a public API shape typically a one-way door?

Answer: Once external consumers integrate, breaking changes require either coordinated multi-party migrations (expensive) or indefinite backwards compatibility (drag). Both are multi-quarter commitments. An ADR for a new public API should state the one-way classification explicitly and invest in the review accordingly.

Prior Module Question 5 (S1 / S5: Testing & CI)​

Why is a fitness function closer to a property test or integration test than a unit test, even when the code looks similar?

Answer: A unit test checks behavior for specific inputs. A fitness function checks an architectural property that holds across the system: "no cyclic deps," "no cross-service SQL," "p99 latency under budget." The similarity is superficial (both run in CI); the difference is that fitness functions target invariants over the whole architecture, not local correctness of one function.

Self-Assessment and Remediation​

Mastery Level (90-100% correct):

  • Ready to apply this in your current role. Focus next on running one drift audit per quarter.

Proficient Level (75-89% correct):

  • Review the missed concept pages. Prioritize any gaps in ADR mechanics (Cluster 2) or facilitation (Cluster 4).

Developing Level (60-74% correct):

  • Rework Practice 1 (ADR Writing Workshop) and Practice 2 (Mock Architecture Review). Expect Cluster 2 and Cluster 4 to be the main gap.

Insufficient Level (<60% correct):

  • Return to the concept sequence. Most likely issue: you are still treating ADRs as documentation instead of as governance. Restart with Cluster 1 and produce 5 ADR critiques before attempting the rest.