Skip to main content

Module Quiz

Complete this quiz after finishing all concept and practice pages.

Current Module Questions​

Question 1: Batch Size​

Why is a release that bundles 40 commits strictly worse than 40 releases of one commit each, from a delivery-safety perspective?

Answer: Failure probability correlates with change size, not deploy count. A 40-commit release makes failure diagnosis ambiguous (any commit could be the cause), makes rollback expensive (losing 39 good changes to fix one), and drops review quality because the diff is unreadable. Many small deploys let each one be attributed, rolled back cheaply, and reviewed properly.

Question 2: Trunk-Based vs GitFlow​

Name one product shape where GitFlow-style release branches are genuinely justified, and one where they are not.

Answer: Justified: a library or SDK supporting multiple versions in the field (1.x, 2.x, 3.x) where long-lived release branches hold security backports. Not justified: a web service with one production environment that can deploy continuously -- release branches only add stabilization delay with no compensating benefit.

Question 3: DORA Shortcomings​

Name the four DORA metrics and one explicit shortcoming of using them.

Answer: Deployment Frequency, Lead Time for Changes, Change Failure Rate, Failed Deployment Recovery Time (formerly MTTR). Shortcoming: they are system-level metrics, not team- or individual-performance measures. Using them for performance review causes teams to game definitions (e.g., re-labeling incidents as non-deployment-caused), destroying their diagnostic value.

Question 4: Build-Once Invariant​

A pipeline has docker build in both the build stage and the deploy-production stage. What invariant is violated, and what can go wrong?

Answer: "Build once, promote everywhere." The artifact tested in staging is not the artifact deployed to production. A new build can silently pick up different dependency versions, base image updates, or transient build-environment changes -- so what worked in staging may fail in production. Fix: build once, promote the same digest.

Question 5: Read This YAML​

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::111:role/deploy
          aws-region: us-east-1
      - run: aws s3 sync ./dist s3://acme-assets/

What security property does this workflow have that a version using aws-access-key-id would not?

Answer: It uses OIDC to request a short-lived AWS session via AssumeRoleWithWebIdentity. There is no long-lived static AWS credential stored as a repo secret -- nothing to leak, nothing to rotate. The cloud trusts GitHub's OIDC issuer and the repo/branch subject, not a copy-pasted key.

Question 6: Read This YAML​

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 2
    maxUnavailable: 2

A service has 10 replicas. A bug reaches the new image. What happens during rollout, and what single change would make this safer?

Answer: With maxUnavailable: 2, up to 2 of the 10 pods may be unavailable at any time. If the new image crashes, the rollout leaves you with up to 2 bad pods plus 2 fewer healthy ones -- a real user-visible error rate during the roll. Safer: maxUnavailable: 0 so the rolling update can never drop below the healthy count while new pods stabilize.

Question 7: Pick the Deployment Strategy​

Service: a new rewrite of the search backend. Correctness is uncertain under real production query distributions. You cannot compare results offline because production queries include private data. Choose a strategy and state why.

Answer: Dark launch. Deploy the new search service. Modify the request handler to call both old and new services, return the old result, and log a diff of the two. Observe under real load. Once correctness and latency are acceptable, flip a flag to use the new result. A canary would expose real users to incorrect results; a dark launch does not.

Question 8: Pick the Deployment Strategy​

Service: a payments ledger that writes to a strongly consistent store. You need to change the wire protocol between the application and the ledger -- mixed versions would cause inconsistent writes. Choose a strategy and state why.

Answer: Blue-green. Mixed versions in production are unacceptable for this protocol change, which rules out rolling and canary. Blue-green stands up a parallel fleet on the new version, validates it, and cuts over atomically; rollback is flipping the router back. Pair with an expand/contract migration on the protocol if possible so both versions can coexist during the cutover window.

Question 9: Rollback Criteria​

Write a rollback trigger as a concrete PromQL query and threshold for a user-facing HTTP API canary.

Answer: Any of:

(sum(rate(http_requests_total{service="api",status=~"5.."}[5m]))
 / sum(rate(http_requests_total{service="api"}[5m]))) > 0.01

-- 5xx error rate above 1% for 5 minutes -- OR --

histogram_quantile(0.95,
  sum by (le) (rate(http_request_duration_seconds_bucket{service="api"}[5m]))
) > 0.500

-- p95 latency above 500ms for 5 minutes. Breach of either triggers traffic shift back to the stable version.

Question 10: SemVer​

Under SemVer, what version bump is each of the following?

  1. Add an optional query parameter to an HTTP endpoint.
  2. Rename a field in a JSON response body.
  3. Add a new required field to a request body.
  4. Fix a typo in an error message.

Answer: (1) MINOR -- backward-compatible addition. (2) MAJOR -- renames break clients that read the old field. (3) MAJOR -- new required input breaks existing clients that do not send it. (4) PATCH (or MINOR if error message strings are part of the contract you advertise).

Question 11: Expand/Contract​

You need to drop a column users.legacy_token. Describe the minimum release sequence to do this safely.

Answer: (R1) Ship code that no longer reads or writes legacy_token. (R2) Wait a safe window for old instances to drain and for any async jobs that referenced the column to complete. (R3) Run a migration ALTER TABLE users DROP COLUMN legacy_token. Never combine step 1 and step 3 -- a rollback of the code deploy would leave new code without the column it expects, which expand/contract avoids.

Question 12: Signing​

A deploy admission controller rejects an image. Inspection shows the image has a valid cosign signature, but from identity repo:attacker/malicious:ref:refs/heads/main. Why is this rejection correct and what does this demonstrate?

Answer: The signature is valid -- the blob is signed -- but the signer identity does not match the expected repo/ref. Keyless signing's value is that the identity binding is inspectable, not just "is this signed." The admission policy correctly requires repo:acme/api:ref:refs/heads/main (or similar). This demonstrates that signing proves provenance (who built it), and the trust decision is made against the provenance, not against a shared key.

Question 13: Feature Flag Debt​

Name the single practice that prevents feature-flag debt from accumulating in a codebase.

Answer: Every release flag is created with an expected removal date and a named owner, tracked in a backlog. Flags are audited quarterly. A flag that has been at 100% for longer than its removal deadline is treated as incident-worthy tech debt, not tolerated noise.

Question 14: OIDC Scoping​

An AWS IAM role with this trust policy condition:

"StringLike": {
  "token.actions.githubusercontent.com:sub":
    "repo:acme/*:*"
}

What access does this grant, and why is it probably wrong?

Answer: It grants the role to any workflow in any acme/* repo, on any ref, in any environment -- including feature branches and forked pull requests (in repos where forks can run workflows with this subject). That is almost never the intent. The correct pattern scopes to a specific repo and ref: repo:acme/api:ref:refs/heads/main, or to an environment: repo:acme/api:environment:production.

Question 15: Change Approval Boards​

What does DORA's research say about external change-approval boards (CABs) and delivery performance?

Answer: CAB-style external approvals correlate negatively with software delivery performance -- they increase lead time and do not improve stability. Peer review on the change itself is the approval process that correlates with better outcomes. The remediation is not "fewer reviews" but "move review to the PR, where it can be specific and timely."

Interleaved Review Questions​

Prior Module Question 1 (Module 3 -- Container Orchestration)​

What is the role of a Kubernetes readiness probe during a rolling update?

Answer: The readiness probe tells the kubelet when a pod is ready to receive traffic. During a rolling update, the Deployment controller only considers new pods "up" once their readiness probes succeed, so it waits before terminating old pods. Without it, traffic routes to a pod that is still starting up, causing connection errors.

Prior Module Question 2 (Module 2 -- Infrastructure as Code)​

Why is committing Terraform state to git a bad idea?

Answer: State files contain resource IDs and (often) secrets such as generated passwords and RDS endpoints. They must be writable by concurrent runs, which git cannot synchronize safely. Use a remote backend with state locking (S3 + DynamoDB, Terraform Cloud, GCS with locking) and never commit state to version control.

Prior Module Question 3 (Semester 7 -- Architecture)​

What is the "two-way door" heuristic for architectural decisions, and how does it relate to canary deployments?

Answer: A two-way door is a decision that is cheap to reverse. Canary deployments deliberately make what looks like a one-way door (replacing a running version) into a two-way door (you can shift traffic back). The idea is identical to the architectural concept: keep reversibility cheap so exploration is cheap.

Prior Module Question 4 (Semester 4 -- Git track)​

What is the difference between a Git tag and a branch?

Answer: A branch is a movable reference that advances as new commits are added. A tag is a fixed reference to a specific commit. Annotated tags (git tag -a or -s) are separate objects in the Git database, carrying message, tagger identity, and optional signature -- these are what release tags should be.

Prior Module Question 5 (Semester 6 -- Testing)​

What is a consumer-driven contract, and why can it be verified in the consumer's CI, not the producer's?

Answer: A consumer-driven contract records the fields and shapes the consumer actually depends on, produced in the consumer's tests and published as an artifact. The producer then runs that contract against its own service in its CI (as a contract verification step). Because the consumer authors the contract from its real usage, the consumer can shrink or widen what it depends on, and the producer can evolve anything the contract does not mention.

Self-Assessment and Remediation​

Mastery Level (90-100% correct):

  • Ready to advance with confidence.

Proficient Level (75-89% correct):

  • Review only the missed concept pages and redo two problems of each missed type.

Developing Level (60-74% correct):

  • Rework the practice pages, especially the deployment strategy workshop and the release/migration clinic.

Insufficient Level (<60% correct):

  • Return to the concept sequence and rebuild the "small, frequent, reversible" habit before advancing. Many wrong answers here trace back to treating delivery as a single event instead of a sequence of safe steps.

Added Process and Quality Questions​

  1. When would you choose a short Agile iteration over a fixed waterfall plan? Name the requirement signal that drives the choice.
  2. How do estimation, acceptance criteria, and CI checks reinforce each other?
  3. What is the delivery risk of long-lived branches, and how do trunk-based development, small commits, and review gates reduce it?
  4. Connect one SQA activity to one pipeline gate and one post-deploy signal.
  5. A rollback succeeded but the same bug returns next sprint. Which process artifact should change: test plan, runbook, branch policy, or estimation note? Defend your answer.