Skip to main content

Module Quiz

Complete this quiz after finishing all concept and practice pages.

Current Module Questions​

Question 1: Platform Choice​

Why is "pick the biggest cloud because it looks best on a portfolio" a poor decision rule for a capstone?

Answer: Platform fit is evaluated on whether you can deploy, debug, and defend the system alone within your budget. A half-configured EKS cluster is weaker evidence than a well-used Fly.io or Cloud Run deploy with real OIDC, real IaC, and a demonstrated rollback.

Question 2: Topology Sizing​

Your capstone is a Go API + Postgres + static frontend. What is the smallest topology that still teaches you production deployment?

Answer: A three-tier topology with a single API service, a managed database, and a static-hosted frontend -- deployed on a PaaS or container platform. No Kubernetes, no message bus, no microservices unless the domain demands them.

Question 3: Environment Strategy​

Why can it be legitimate to run only prod plus a preview-per-PR environment for a capstone, and drop a dedicated staging?

Answer: A stale staging catches almost no real bugs. A preview environment per pull request is always built from the same commit the reviewer sees, and is destroyed when the PR closes -- so it catches more bugs at lower cost than a continuously-running staging that nobody updates.

Question 4: Terraform State​

What does Terraform state contain, and why is a locking remote backend not optional?

Answer: State maps the resources Terraform manages to their real cloud IDs and attributes. Without locking, two concurrent apply runs can corrupt state, after which Terraform's view of reality is wrong and the next apply may recreate or destroy real resources.

Question 5: Module Extraction​

State the rule for when to extract a local Terraform module for a solo capstone.

Answer: Keep resources inline. Split into local modules only at blast-radius boundaries (network, data, compute) when the root file exceeds ~150 lines. Extract further only when the third copy of a block appears and the duplication is actively painful.

Question 6: Secrets Strategy​

Where should secret values live and what must never appear in the repo?

Answer: In exactly one secret store per environment, read by the deploy role over OIDC and mounted as env vars at runtime. The repo may contain secret names (e.g., DATABASE_URL) and the schema that validates them, but never values -- not even placeholders that happen to be real.

Question 7: Pipeline Minimum​

Name the three jobs the capstone pipeline must have and the trigger for each.

Answer: build-test on every push and PR to main; deploy gated on needs: build-test and on push to main; optionally a preview-up/down pair on pull_request events. Anything more is bonus.

Question 8: OIDC Benefit​

Why is OIDC preferred over a long-lived access key for cloud authentication from CI?

Answer: OIDC issues short-lived credentials bound to a specific repo, workflow, and branch via a trust condition. A leaked repo or stolen workflow log cannot be replayed outside that narrow context, and there is no key to rotate.

Question 9: Preview vs Staging​

Give one scenario where a preview environment is strictly better than a staging environment, and one where the opposite holds.

Answer: Preview wins when each PR touches unique code paths and reviewers need a reachable URL -- e.g., UI changes. Staging wins when you need to exercise schema migrations against a production-sized dataset before prod touches it; previews on tiny datasets will not expose migration timeouts.

Question 10: Rollback Trigger​

State three rollback triggers that you would act on without discussion, and the rough timer budget for each.

Answer: Smoke test fails post-deploy -- 3 minutes; 5xx rate above 5% for 2 minutes -- 5 minutes; login broken on manual check -- 10 minutes. Each trigger has a pre-agreed response so there is no decision-making under pressure.

Question 11: Expand-Contract​

Walk through an expand-contract migration for renaming users.full_name to users.display_name.

Answer:

  1. Expand (release N): ALTER TABLE users ADD COLUMN display_name; UPDATE users SET display_name = full_name; App writes both columns and reads display_name with COALESCE fallback.
  2. Deploy and observe release N. Rolling back code to pre-N is safe because full_name still exists and is still written to by some versions.
  3. Contract (release N+1): ALTER TABLE users DROP COLUMN full_name; App reads/writes display_name only. Rolling back past N+1 is now a data-loss event and is treated as one.

Question 12: Feature Flag Discipline​

Why does Martin Fowler's framing call feature flags a "last resort"?

Answer: Every live flag adds an if branch that must be tested, and a config surface that must be maintained. A permanent flag is code rot in disguise. Use flags to decouple deploy from release or to provide a kill switch, and retire them aggressively -- ideally with a committed retirement date.

Question 13: Smoke Tests​

Why is curl /healthz -> 200 not a sufficient smoke test, and what three checks are?

Answer: /healthz only proves the process is alive. You also need (a) a readiness check that exercises the real database, and (b) a critical user path -- a login + authenticated request that represents a core feature. All three run against the environment you just deployed, not against staging or CI.

Question 14: Release Notes Audience​

Who is the primary reader of a capstone release note, and what three sections must it contain?

Answer: Your future self, months after the deploy. Sections: Changed (user-visible diffs), Why (one sentence of intent), Risk (what could have gone wrong, whether it did or not). Commit-log dumps are not release notes.

Question 15: Runbook Test​

What is the "stranger test" for a deployment runbook?

Answer: A peer who is not the author reads the runbook and attempts to deploy the capstone. Every line they pause on or ask about is a gap. The runbook is done when a stranger can deploy and verify from it alone.

Interleaved Review Questions​

Prior Module Question 1 (S10 M2: Implementation and Testing)​

Why is a flaky test in main a release-engineering issue, not a testing issue?

Answer: Because a flaky test trains the team to ignore red builds, which undermines the rule that main must stay deployable. Release engineering depends on trusted signals; a flaky test is an untrusted signal.

Prior Module Question 2 (S10 M1: Domain Analysis and Architecture)​

How does choosing a capstone topology relate to the architecture decisions made in Module 1?

Answer: Topology is the runtime expression of the Module 1 architecture. If Module 1 picked a three-tier architecture, the topology should be three tiers; if Module 1 picked serverless-first, the topology should match. Mismatches are an ADR that never got written.

Prior Module Question 3 (S9 M02: Infrastructure as Code)​

Why can state drift between cloud reality and Terraform state break a rollback, not just a forward deploy?

Answer: A rollback is just another apply with a different input. If state is wrong, the rollback plan will be wrong -- it might destroy resources the previous version depended on, or fail to recreate resources that were manually deleted.

Prior Module Question 4 (S8 M04: Scale, Reliability, Performance)​

How is MTTR (mean time to restore) related to deployment frequency?

Answer: High-performing teams deploy more often precisely because they have low MTTR. Rolling back is cheap, so the risk of any single deploy is low, so deploys happen more often. A slow rollback forces cautious, rare deploys.

Prior Module Question 5 (S7: Data & ML context)​

Why is a production-sized staging dataset important before shipping a schema migration?

Answer: Migrations that complete in seconds on a 100-row staging table can take hours on a 50-million-row prod table. Staging datasets shaped like prod are the only way to catch migration timeouts and lock-contention problems before they hit prod.

Self-Assessment and Remediation​

Mastery Level (90-100% correct):

  • Ready to advance to Module 4 (Operational Readiness and Security Review) with confidence.

Proficient Level (75-89% correct):

  • Re-read the missed concept pages and redo one practice section for each cluster that came up.

Developing Level (60-74% correct):

  • Rework Clusters 3-4 carefully. Most capstone failures at defense are pipeline and rollback gaps, and this range usually matches that.

Insufficient Level (<60% correct):

  • Return to S9 M02 and S9 M04 for a focused one-day refresh, then redo Clusters 1-3 here. Do not skip ahead to Module 4.