skip to content

How do you prove a second region actually runs your architecture rather than trusting the provider's service-availability information?

level: seniorimportance: must knowfreq 52%

answer

  1. the list answers a different question
  2. gaps live below the service name
  3. provision it, do not read about it
  4. success is not proof, diff it
  5. dated register with a decision each

basics

~20 s

By deploying it there. Build the second region from the same description as the first and let every gap surface as a failed request, then record what was refused, what provisioned differently, and what you accepted. A table of service names proves nothing.

solid answer

~50 s

Published availability answers "is this service offered here", and the question you actually have is "does my configuration provision here, at the size and with the options it needs". Only a real provisioning attempt answers that, because the gaps live below the service name: missing options, older hardware generations, regional ceilings and defaults. So the check is a **parity drill**: generate the second region's stack from the same description as the primary, request the real shape rather than a test-scale one, read back what was created and diff it against what was asked for, then tear it down. Every refusal and every silent difference goes into a written register with a decision attached — change the design, change the region, or accept it. Run the drill on a cadence, because the architecture changes and so does the region.

code

pseudocode · 20 lines
pseudocode
gaps = empty list

for each component in recoveryStack:
    request = render(component, region = secondaryRegion, scale = production)
    result  = provision(request)

    if result.refused:
        gaps.add(component, "refused", result.field, result.reason)
        continue                      // nothing was created, nothing to tear down

    differences = diff(result.attributes, request.attributes)
    if differences is not empty:
        gaps.add(component, "provisioned differently", differences)

    teardown(result)

if gaps is empty:
    status = "parity verified for this configuration, on this date"
else:
    status = "open gaps: " + count(gaps)

go deeper

for a junior

Remember the distinction: a list tells you a service is offered in a region; only actually creating your configuration there tells you it will work. Read the error text when a request is refused.

for a middle

Explain the four gap kinds that sit below a service name — missing options, hardware generations, regional ceilings, differing defaults — and why each is invisible to published availability but visible to a create call.

for a senior

Demonstrate the drill: one description for both regions, the full production shape, a diff of created against requested, teardown, and a dated register of accepted differences with owners.

for a principal

Set the policy: which workloads must carry proven second-region parity, how often it is re-proved, and who is accountable when the register is stale — since the architecture and the region both move between drills.

## Why the published information cannot answer the question A provider's availability information is organised around **services**, and it is accurate. It is simply answering a different question from yours. It says *this service is offered in this region*. You need to know *this stack, with these options, at this size, can be created in this region today*. Four kinds of gap live in the space between those two sentences: - an option of the service that has not rolled out there; - a hardware generation the region does not carry, so sizes differ; - a regional ceiling that stops you well below production scale; - a default that differs, so something provisions with a narrower meaning than you asked for. None of the four is visible in a list of service names. All four are visible to a create call. ## The parity drill The drill is deliberately unglamorous: 1. **Describe the stack once.** Both regions are produced from the same description, differing only in explicit, named parameters. If the two regions are described separately, the descriptions drift and the drill measures the drift instead of the region. 2. **Request the real shape.** Full size, all options, including the ones that only matter under load. A simplified test stack succeeds precisely where the real one would fail, which is worse than not testing. 3. **Read every response.** A refusal names the field or the ceiling — that is the highest-resolution parity information available anywhere. 4. **Diff created against requested.** Success is not proof. Read the object back and compare it field by field; options can be dropped or narrowed silently. 5. **Tear it down.** The drill costs the run, not a standing duplicate estate. 6. **Record every gap with a decision.** Change the design, change the region, or run differently there and accept it, with the consequence written next to it. ## Evidence, not claims | the claim | what counts as evidence | |---|---| | "the service is available there" | a created instance with the options we use | | "the fleet can run there" | the full machine count started, counted, and torn down | | "the sizes are equivalent" | the same family provisioned, with measured throughput | | "the configuration is identical" | a diff of the created objects showing no differences | | "we have no open gaps" | a register with a date and an owner, not a memory | ## The parity register What outlives the drill is a short written record: each difference found, when, what was decided, and who owns it. It matters for two reasons. First, an accepted gap that is not written down stops being a decision and becomes an assumption — the next engineer reads the architecture and believes both regions match. Second, gaps close: the provider eventually installs the hardware or ships the option, and the workaround built around it becomes dead weight nobody revisits. The register is what makes both the gap and its eventual disappearance visible. ## Cadence, and what moves between drills Parity is not a state you reach. Between drills, three things move independently: - **your architecture**, which grows options and dependencies continuously; - **the second region**, which receives capabilities on a rollout you do not control; - **your scale**, which drifts past the ceilings you arranged for last year. So the drill has a cadence — commonly tied to the same rhythm as other readiness exercises — and a trigger: any new platform dependency added to the design is a reason to re-test that component in the second region before it is called ready. A cheaper continuous version is a periodic automated pass that provisions the pieces carrying the most parity risk, checks the result, and tears them down, reporting only differences. It will not catch everything a full drill catches, but it turns the slowest-moving risks into a signal instead of a surprise. ## What a strong answer sounds like The candidate to hire says: published availability is the wrong resolution, so I provision the real shape from the same description and let the platform tell me; I diff created against requested because success is not proof; and I keep a dated register of accepted differences, because the alternative is an assumption nobody can see. The weaker answer is a promise to "check the region supports everything first" — which is the step that produced the false confidence the question is about.

  • Why generate both regions from the same description rather than writing the second one to match?
    Because a separately written second region drifts from the first, and the drill then measures the drift rather than the region's capability. With one description and explicit named parameters, any difference in the outcome is attributable to the region, which is the only thing the drill is trying to find out.
  • What is the lighter-weight version if a full drill is too expensive to run often?
    An automated pass that provisions only the components carrying parity risk — those using newer options, specific hardware families, or large counts — verifies the created objects, tears them down and reports only differences. It misses interactions a full drill catches, but it converts the slowest-moving risks into a continuous signal.
  • What should the drill produce besides a pass or fail?
    A dated register: each difference found, the decision taken about it, and an owner. Accepted gaps that are not written down become invisible assumptions, and gaps that later close leave behind workarounds nobody revisits. The register is what makes both directions of change noticeable.

saying these in an interview costs you the question

  • Treats a comparison of two regions' service lists as verification.
  • Runs the drill at test scale, which skips the options that carry the risk.
  • Assumes a create call that returned success honoured every option.
  • Treats parity as a one-time check rather than something that drifts both ways.
  • Keeps accepted differences in someone's memory instead of a dated register.
  • Describes the two regions separately, so the drill measures description drift.