Senior Solutions Architect at Google: Comprehensive Interview Preparation Guide

Direct answer

When priorities shift out from under a strategy, the discipline is re-scoring the backlog against the new constraint explicitly, not silently reprioritizing by gut feel, and being willing to say which committed work is paused, not just which new work is added.

Structured elaboration

• Get the new hard constraint stated precisely, in writing, from whoever owns it (legal, a regulator, an acquirer). "Compliance" and "explainability" mean different specific things to different people, and building against a vague version of the requirement wastes the pivot.
• Re-score every active and planned initiative against a small, explicit, written set of criteria weighted toward the new constraint (regulatory impact, reach, effort, and confidence in the estimate, adapted to the moment). The same test works whether the forcing constraint is a regulator, an acquirer, or a hard performance target like sustaining 10x throughput under a fixed budget. Writing the score down is what makes the "what got abandoned" conversation defensible later, rather than looking political.
• The same re-scoring discipline applies even when the shift is internal rather than external: three stakeholders each request a different initiative for the same cycle and there is capacity for only one; an explicit-criteria comparison is what makes that choice defensible instead of a popularity contest.
• Sequence the response across time horizons instead of one big-bang change: an immediate 0-3 month slice covering the non-negotiable, hard-deadline work; a 3-12 month slice building the durable capability (real data lineage and access control, not a one-off report); and a 12-36 month slice for restoring the paused strategic work once the mandatory floor is met.
• Get explicit sign-off from whoever controls funding and headcount (finance, a CTO, or equivalent) on the reprioritization itself, not just on the technical plan. Reallocating people away from committed roadmap items is a resourcing decision, not only a technical one.
• Keep a visible "paused, not cancelled" list. Initiatives dropped for the mandatory work need an owner and a resume trigger, or they quietly become permanently cancelled without anyone deciding that on purpose.

Worked example

A company gets acquired and a new regulator-driven requirement (data retention and explainability of reporting) becomes non-negotiable, on top of an existing roadmap built entirely around growth-facing dashboards. Rather than absorbing the new work as one more backlog item, you convene the people who actually own the requirement, translate it into concrete deliverables (an auditable reporting view, retention automation, documented data lineage), and re-score the backlog against a deadline-driven weighting, pausing lower-urgency growth experiments explicitly rather than letting them slip silently. You phase the response: the auditable view and retention work ship first because they carry the hard deadline; lineage and access-control work that makes future audits cheaper follows once the deadline is met; the paused growth analytics work gets a resume date once the mandatory floor is in place, coming back with a smaller footprint that reuses automation built for compliance rather than restarting from the original scope. Getting explicit funding sign-off matters here specifically because analysts had to move off committed growth work, and that is a resourcing call that needs to be made on purpose, not absorbed silently.

Trade-offs and pitfalls

The main failure is treating a hard external deadline as just another high-priority ticket instead of restructuring the whole plan around it, which produces a roadmap that stays busy but still misses the deadline. The second is never explicitly un-pausing the deferred work: once a strategic initiative is quietly shelved for a mandatory one, it tends to stay shelved unless someone owns bringing it back. The third is picking the requirement's minimum literal interpretation to move fast and then having to redo the work once the fuller requirement is clarified; it is usually cheaper to over-clarify scope with the requirement's owner up front than to guess and rebuild.

Direct answer

Match the store to the shape of the access pattern and the guarantees the component actually needs, not to whichever store the team already operates: relational for data needing multi-record transactions and ad hoc joins, key-value for simple point lookups by a known key at very low latency, document for semi-structured records usually fetched whole, wide-column for very high write throughput on wide, sparse rows accessed by a known key plus a range, and graph for data whose primary queries traverse relationships across multiple hops rather than filtering on attributes.

Structured elaboration

Guiding factors, in the order a competent decision usually walks through them: what is the dominant query, a lookup, a scan, a join, or a traversal; how many hops does a typical query need to walk, zero or one hop rarely justifies a graph database, several hops usually does; how strict does the transactional guarantee need to be; and what is the actual sustained write rate and row shape, not just the current team's default toolchain.

Worked example

A single e-commerce platform, choosing per component rather than one store for everything:

• Order and payment ledger: relational, because it needs multi-row transactions across order, inventory, and payment state that must all succeed or fail together.
• User session cache: key-value, point lookups by session identifier, no joins, and very low latency is the only real requirement.
• Product catalog: document, records vary by product category and are typically read whole on a product page.
• Clickstream and event ingestion: wide-column, an extremely high write rate queried later by user identifier plus a time range, exactly the access pattern wide-column engines are built for.
• "Customers who bought this also bought" and fraud-ring detection: graph, because the actual query traverses relationships (co-purchase edges, shared payment instruments) several hops deep, which is expensive to express as repeated joins in a relational engine.

Trade-offs & pitfalls

• Defaulting to whichever store the team already runs, then discovering the real query pattern needs relationship traversal or very high wide-row write throughput, and bolting it onto the wrong engine, shows up later as application code re-implementing joins or graph-walks, or a single store buckling under a write pattern it wasn't designed for.
• Choosing a graph database for data with only shallow, one-hop relationships is over-engineering, a foreign key in a relational table is simpler and has better tooling for that case.
• Choosing a wide-column store for workloads that need ad hoc filtering across arbitrary attributes works against its design, wide-column stores are fast specifically because queries are restricted to key plus range, arbitrary attribute filtering is its weakest fit.
• The same logical dataset can legitimately live in more than one store at once, for example a relational system of record with a derived graph or search index kept in sync, when no single store serves every access pattern well, but that adds an explicit synchronization problem that needs an owner, not an assumption that it will stay consistent on its own.

Direct answer
Behavioral answer skeleton: describe a specific decomposition decision made (the boundaries chosen and why), what actually happened once it shipped (either it didn't go as planned, or it delivered a measurable improvement), and what that outcome revealed, whether a lesson learned from a setback or concrete evidence the decision was right.

Structured elaboration
A strong version of this story names the actual boundary decision (which service was split from what, and the reasoning at the time), not just "we adopted microservices." For the setback version: what specifically didn't go as planned (a boundary that turned out to force more cross-service coordination than expected, or a scaling assumption that didn't hold), how it was diagnosed (what signal first revealed the problem, whether an incident, a slow release cadence, or direct team feedback), and the concrete fix or the lesson carried forward (a corrected boundary, a new team-ownership model, or a changed process for validating boundaries before committing to them next time). For the success version: what was measured to confirm the decomposition actually delivered value, whether an increase in independent deploy frequency for the extracted service, a drop in incidents caused by unrelated changes to a previously-shared service, or a faster mean-time-to-recovery once the failure domain was smaller.

Worked example
A representative setback story: a service was split expecting two teams to be able to work independently, but the boundary was drawn along a technical line (splitting a read path from a write path) rather than a business-domain line, and the two resulting services turned out to need frequent, tightly-coordinated releases anyway because a business rule change usually touched both. The signal that revealed this was release velocity not improving the way the split was supposed to deliver, and cross-team coordination overhead showing up in retrospectives. The fix was re-drawing the boundary along the actual business domain instead of the technical read/write line, after which the two teams could genuinely release independently. A representative success story: extracting a reporting service from a shared order-processing service, after which order-processing's deploy frequency roughly doubled (no longer blocked by reporting's separate, slower release cycle) and a subsequent reporting-specific incident had zero impact on order processing, which was the exact goal the extraction was measured against.

Trade-offs and pitfalls
A weak answer to this question stays vague about what actually went wrong or right ("the migration was challenging but we got through it") without naming the specific boundary decision, the specific signal that revealed the outcome, or a specific number or concrete change that resulted; interviewers are listening for evidence the candidate can reason critically about their own past decomposition decisions, not just narrate that a project happened.

Approach

Right-sizing a VM fleet during a migration is a measure-then-decide process: figure out what to measure, measure it for long enough under realistic load, then use those numbers to pick both the instance family and the size within it, with explicit room for peaks.

What to measure

CPU utilization, memory utilization, disk I/O (both IOPS, input/output operations per second, and throughput), network throughput, and an application-level signal (request latency or error rate) as a cross-check that a resize didn't quietly hurt correctness or the SLO (service level objective), not just that it "still ran."

How long, and under what conditions

Long enough to be representative, not a quick snapshot. At minimum a full weekly cycle, to capture weekday-versus-weekend variation, and ideally spanning any known seasonal peak the workload has (month-end batch jobs, a promotional traffic event), since a few hours of measurement will miss the load pattern that actually determines the right size.

Choosing the instance family

Match the family to the workload's resource shape, not just a generic size:

• A higher memory-to-vCPU ratio family for memory-bound workloads (large in-memory caches, for example).
• A compute-optimized family for CPU-bound workloads.
• A burstable, credit-based family for something idle most of the time with occasional short spikes, cheaper baseline cost, spending credits during the rare spike, rather than an always-on family sized for a peak that's mostly not happening.

Choosing the size

Within the chosen family, pick the smallest size whose capacity covers the observed peak, not the average, plus a headroom margin.

Handling headroom for peaks and bursty traffic

Apply a margin above the observed historical peak (a common convention is roughly 30-50% above peak) so a burst slightly larger than anything seen so far doesn't immediately saturate the instance. Combine that per-instance margin with fleet-level autoscaling, so the fleet as a whole absorbs bursts beyond any single instance's margin, rather than over-sizing every instance for a rare event that autoscaling could handle instead.

Direct answer

I would run hybrid discovery as three layers: first the business reason for the integration (what has to work for the deal to matter), then a map of every data flow between the on-prem databases and the cloud services with its latency, consistency, security and ownership constraints, then a request for the artifacts that let me check what people tell me. I would not design anything until I can draw the flows and the customer has confirmed the drawing.

Terms used below: on-prem means systems the customer runs in its own data centres. Discovery is the structured fact-finding before a proposal. CDC (change-data-capture) streams row changes out of a database's log. ETL (extract, transform, load) is batch data movement. RPO (recovery point objective) is how much data loss is tolerable, RTO (recovery time objective) is how long an outage is tolerable. SSO (single sign-on) lets users sign in once with a corporate identity, and an IdP (identity provider) is the system that authenticates them. A system of record is the one system whose copy of an entity is the official one. Atomically means two updates either both happen or neither does. Eventual consistency means copies may differ briefly but converge, and a reconciliation job is a scheduled comparison that finds and fixes differences. An outbox pattern saves the change and a to-send message in one local transaction, then a separate process delivers the message. A single transaction boundary means one database commit covers everything. Chatty designs make many small calls, each paying the cross-site delay. Kerberos and LDAP are common on-prem login and directory protocols; federation lets one side trust the other's logins. Stored procedures are code that runs inside the database. A DBA is the database administrator, and allow-listing means the firewall only admits named addresses. Default starting point: for a one-way copy, a polling extract or CDC; for lookups, an API; messaging when several consumers need the same events.

What I need to understand (the discovery plan)

Artifacts I ask for

1. Architecture or network diagrams (even outdated ones: the gaps between diagram and reality are findings).
2. A schema export or data dictionary for the in-scope tables, plus row counts and growth rate.
3. Interface list: existing integrations, file drops, stored procedures, scheduled jobs.
4. A sample of redacted production data and a week of peak-hour volume numbers.
5. Security policy extracts: data classification, encryption-at-rest and in-transit requirements, audit requirements, any compliance scope.
6. Current SLAs and incident history for the two or three flows that matter most.
7. Environment access plan: whether a non-production copy exists for the proof of concept (POC, a limited trial against agreed criteria).

Worked example of one flow

Customer says orders live in an on-prem Oracle database and the cloud service needs them "in real time". I ask: "If an order shows up in the cloud 5 seconds late, what breaks? 5 minutes?" If the answer is that the warehouse dashboard goes stale after about 2 minutes, the requirement is a 2-minute freshness target (how old the cloud copy is allowed to be), not real time, and CDC or a polling extract is enough. If the on-prem database cannot expose its log (licensing, DBA policy), I record that as a risk and an alternative (timestamp-based incremental extract: it fetches rows changed since the last run, but a deleted row leaves no timestamp to find, so deletes must be tracked separately, for example with a deleted-flag or a delete log). The recorded line in my notes: "Orders: on-prem is system of record; cloud read-only copy; freshness target 2 min; peak 40 orders/s; link: site-to-site VPN; DBA approval needed for log access."

How I run it

Start with one 60-minute workshop with the architect and a business owner, then one deep-dive per flow with the engineer who owns it, then a read-back of my diagram and the open-questions list. I sequence the questions from the business outcome down so the technical detail has a purpose.

Trade-offs and pitfalls

• Asking for everything on day one stalls the deal: rank flows by business value and go deep on the top two or three.
• Accepting "it is all real time" or "we need strong consistency everywhere" without pricing it. Say what each costs so the customer prioritises.
• Designing before the identity and network answers exist: those two usually set the schedule.
• Treating the on-prem team as an obstacle. They own the risk; bring them in early and let them veto items with reasons.
• What would change my plan: if the proof of concept budget is small, I narrow to one flow and one system of record and propose phasing the rest.

Direct answer

Headroom is the fraction of total fleet capacity not currently in use: $\text{headroom} = (\text{total capacity} - \text{load}) / \text{total capacity}$. For 20 servers at 1,000 requests per second (RPS) each against an observed 95th-percentile (P95) load of 12,000 RPS, current headroom is exactly 40%, which means the fleet is already at the stated target and needs zero additional steady-state instances. The more interesting part of this problem is that "40% headroom" is not one number once operational realities like rolling deployments enter the picture, since taking servers offline to redeploy them temporarily reduces the same denominator that headroom is computed against.

Step-by-step: current headroom

$$\text{total capacity} = 20 \times 1{,}000 = 20{,}000\ \text{RPS}$$ $$\text{headroom} = \frac{(20 \times 1{,}000) - 12{,}000}{20 \times 1{,}000} = \frac{8{,}000}{20{,}000} = 0.40 = 40\%$$

Since the target is also 40% headroom, the fleet already meets it: 0 additional instances needed for steady-state P95 load as given.

Extending the answer: headroom under rolling deployment

A steady-state headroom number does not survive a rolling deployment unchanged, because a rolling deploy takes a batch of servers offline (to restart and warm up) while the rest of the fleet absorbs the same load. If a target recovery time objective (RTO) bounds how long a batch may be down, and each server needs, illustratively, a 2-minute warm-up before it serves at full capacity again, then the fleet needs to keep at least the minimum serving capacity above throughout the rollout, not just at rest.

Solving for the minimum number of servers that must remain in service to hold 40% headroom during a drained window, using the same 12,000 RPS load:

$$\text{total}_{serving} \times (1 - 0.40) \ge 12{,}000 \implies \text{total}_{serving} \ge 20{,}000\ \text{RPS} \implies \ge 20\ \text{servers serving}$$

That is the same 20 servers as the steady-state fleet, which means a rolling deploy that takes any servers offline at all will temporarily breach the 40% target unless extra servers are provisioned specifically to cover the batch that is mid-restart or mid-warm-up. With an illustrative batch size of 2 servers drained at a time (a deliberately conservative choice to bound blast radius and keep the 2-minute warm-up window short in aggregate):

$$N_{fleet} = N_{serving} + b = 20 + 2 = 22\ \text{servers}$$

So provisioning 22 servers instead of 20, two more than the steady-state minimum, keeps 20 servers always serving even while 2 are cycling through the 2-minute restart-plus-warm-up window, preserving the 40% headroom target throughout the rollout rather than only at rest. This same per-minute-granularity view, "how much serving capacity is available right now, given who's mid-warm-up," is what feeds a rolling capacity forecast into an autoscaler policy; because the forecast window is short (on the order of the 2-minute warm-up lead time itself), a lower steady-state buffer, for example a 20% headroom target rather than 40%, is often sufficient for that forecast layer, since it only has to smooth over the next couple of minutes rather than absorb a full traffic-growth cycle.

A second worked example: rolling maintenance at larger scale

The same batch-drain formula applies at a different fleet size with different constraints. Take a 100-server fleet undergoing rolling maintenance where each server needs a 2-minute restart followed by a 3-minute warm-up, and the operational requirement is to keep at least 80% capacity serving throughout:

$$\text{max batch}\ b:\quad 100 - b \ge 0.80 \times 100 \implies b \le 20\ \text{servers per wave}$$

With a maximum batch of 20 servers per wave and 100 servers total, that's 5 waves ($100 / 20$). At roughly 5 minutes per wave (2-minute restart plus 3-minute warm-up), a fully serial rollout takes about 25 minutes; waves could be shortened by running them with some overlap once a wave's warm-up phase no longer needs to block the next wave's restart phase, but that adds coordination complexity in exchange for a shorter total window.

Validating the headroom target with load testing

A headroom number computed from stated per-server capacity is only as good as that capacity figure. Before trusting it operationally:

• Stress test: push a single server (or a small cluster) past its stated 1,000 RPS to find its actual breaking point, confirming the capacity figure used in the headroom math is not optimistic.
• Soak test: hold the fleet at target load for an extended period to catch degradation that only shows up over time (memory growth, connection exhaustion), which a short burst test would miss.
• Spike test: apply a sudden jump well above the P95 load figure to confirm the stated headroom actually absorbs a real burst, not just the smoothed average the P95 number represents.
• Ramp-up schedule and success criteria: define the load curve in advance (for example, step up by 20% of capacity every few minutes) and a clear pass/fail bar (P95 latency stays under target, error rate stays near zero) rather than eyeballing dashboards during the test.

Trade-offs and pitfalls

The most common mistake here is computing headroom once at rest and treating it as a constant, when in practice every rolling deployment, maintenance window, or partial-zone failure temporarily changes the denominator; a fleet sized exactly to its steady-state headroom target has effectively zero headroom the moment any servers are intentionally taken offline. The second common mistake is picking a batch size for rolling operations based on deployment speed alone, without checking that the resulting drained capacity still clears the headroom bar, which is exactly the kind of gap that surfaces as a latency spike during otherwise-routine maintenance rather than during an actual traffic surge.

Direct answer

I put a commitments register and a tiered sign-off in front of every proposal. Each technical claim is classified before it is written down: standard (already in the product, cite the documentation), roadmap (planned but not yet shipped; needs product sign-off and a not-a-guarantee clause, a sentence stating the item is intent and not a contractual promise), or custom (needs an engineering estimate and executive approval; custom means beyond configuration of the standard product, so something engineers must build or change). Nothing goes to the customer until the register is complete and the named owners have signed. The Solutions Architect (SA, the technical lead on the deal) runs the process; the people who sign are the ones who would be blamed if the claim were wrong.

The review, step by step

1. Extract the commitments. The SA reads the draft proposal and lists every sentence that promises something (feature, integration, performance, security control, date, effort).
2. Classify and route. Each line goes to its owner:
   | Commitment type | Example | Who signs |
   |---|---|---|
   | Standard capability | "Single sign-on via SAML" (a standard that lets customers log in with their corporate identity) | SA, with a link to the documentation |
   | Roadmap | "Bulk export in Q3" | Product manager, plus wording that it is not a contractual commitment |
   | Custom or non-standard | "Deploy in the customer's data centre" | Engineering lead (effort and feasibility), plus the sales director |
   | Security and compliance | "SOC 2 report available" (an independent auditor's report on our security controls) | Security or compliance lead |
   | Delivery effort and plan | "Go-live in 12 weeks" | Services or delivery manager |
   | Legal and commercial terms | Liability, service-level agreement (SLA, the contractual uptime promise) | Legal and finance (the deal desk, the internal team that approves pricing and contract terms) |
3. Check three dimensions: technical accuracy, commercial alignment (price and scope match the terms), and compliance (nothing contradicts a certification or policy). Example of one claim failing one dimension: "Data stays in one region" is technically true for production, but if the backups replicate to a second region the compliance dimension fails and the wording must change. The review tiers by risk: a standard claim with a documentation link gets the lightest review (SA alone), a roadmap item needs product, and a custom build or a legal term gets the heaviest (engineering plus a director, or legal).
4. Sign off in the register. The register records claim, class, owner, evidence link, date signed.
5. Final read. A second SA who did not write it reads the clean copy against the register.

Roles, SLAs, escalation (illustrative targets, set to your own deal pace)

• Standard claims: no extra review beyond the evidence link.
• Roadmap and custom claims: owner responds within one business day.
• If no response in two business days, escalate to the owner's manager; at the deal deadline, the sales director decides whether to remove the claim, never to keep it unsigned.
• Rule: an unsigned commitment is deleted from the proposal, not softened.

Example register excerpt

Templates and automation (one short paragraph)

For speed, I keep an approved library of answers and sections, each with an owner and a last-verified date, and auto-expire entries after a set period so stale claims cannot reappear. SAs tailor within slots (customer name, volumes, regions) without editing the verified wording.

Trade-offs and pitfalls

• Too much review slows deals; tiering makes the common case fast.
• Reviewers who sign without reading are worse than none: require evidence links.
• The classic failure is a roadmap item written as a present-tense fact. Safe wording: "Bulk export is planned for Q3. This is a statement of current intent, not a commitment, and is not a condition of this agreement; timing may change." Unsafe wording: "The platform supports bulk export."
• What would change my approach: very high deal volume, where I would move the register into the proposal tool and measure turnaround time.

Direct answer

For a global transactional application needing low latency and strong consistency, Spanner's multi-region configuration is the right recommendation over a hand-built cross-region Cloud SQL topology, because Cloud SQL fundamentally has one authoritative primary. A cross-region Cloud SQL setup can give you regional read replicas for low-latency reads, but every write still goes through a single primary in one region, meaning every write from anywhere in the world pays that primary region's round-trip latency, and a regional outage of the primary is a real, manual failover event, not an automatic one. Spanner's multi-region configuration distributes both reads and a quorum-based write path across regions natively, giving strong (in fact, stronger than typical "strong consistency": external consistency) guarantees globally with automatic failover, at the cost of higher baseline write latency than a single-region deployment and real cost and design complexity.

Structured elaboration

Spanner multi-region configuration. A multi-region configuration designates a default leader region (housing the leader replicas for each shard), a second read-write region, and a witness region that holds a voting replica without serving reads, plus optional additional read-only regions for low-latency local reads elsewhere. Every write forms a quorum: one of the replicas in the leader region plus two of the four remaining voting replicas across the other regions must agree before a write commits, which is what gives Spanner external consistency (a guarantee stronger than standard strong consistency, meaning transaction order is preserved in a way consistent with real time globally, not just per-object). Multi-region configurations offer higher availability than a regional one (99.999% versus 99.99%), precisely because losing any single region still leaves enough voting replicas to form a quorum.

Cross-region Cloud SQL topology. The realistic version of "cross-region Cloud SQL" is one primary in a home region with cross-region read replicas near other user populations, so reads local to those replicas are fast, but every write anywhere still round-trips to the single primary's region. A regional outage of the primary requires promoting a replica to primary, which is an operator-initiated (or scripted) failover with a real recovery time, not the automatic, sub-second quorum failover Spanner's model provides. There's no native Cloud SQL feature that gives you a globally-distributed write path with strong consistency; building an approximation (application-level sharding by geography, conflict resolution logic for cross-region writes) is a significant, ongoing engineering investment that's reinventing a narrower, less battle-tested version of what Spanner provides as a managed service.

Failover and replication compared directly:

Recommendation and justification. For a genuinely global, write-heavy transactional application needing strong consistency (the stated requirement), recommend Spanner's multi-region configuration: it's the only one of the two that actually gives strongly-consistent writes with low latency from more than one region, because Cloud SQL's single-primary architecture makes "low latency writes from everywhere" and "one authoritative primary" mutually exclusive. If the actual requirement, on closer inspection, turns out to be "low-latency reads globally, but writes can tolerate one region's latency" (a materially different and more common requirement than it first sounds), a cross-region Cloud SQL topology with regional read replicas is simpler, cheaper, and sufficient, so it's worth explicitly confirming which requirement is real before committing to Spanner's added cost and complexity.

Worked example

A global ride-hailing dispatch system needs a driver's location update and a rider's booking confirmation to be consistent worldwide (a driver can't be double-booked across two regions' views of the same fleet), with drivers and riders spread across North America, Europe, and Asia. On Spanner, a multi-region configuration spanning those three regions gives every region low-latency local reads and a consistent write quorum, so a booking confirmed in Europe is immediately, correctly reflected if queried from Asia. On cross-region Cloud SQL with a single primary in, say, us-central1, every booking write from Europe or Asia pays a full round trip to the US regardless of how many local read replicas exist, and a us-central1 regional outage means dispatch is down globally until a replica is manually promoted, both of which directly violate the stated low-latency and strong-consistency requirements. The identical argument holds for a global financial-services application processing payments across the same three regions: a payment authorization is the same kind of write that must be immediately, consistently visible everywhere (to prevent the same funds being authorized twice from two regions), so the recommendation and the reasoning behind it don't change just because the domain moves from ride-hailing to payments.

Trade-offs & pitfalls

• Recommending Spanner without confirming the write requirement genuinely needs global strong consistency (rather than just global low-latency reads) means paying for capability the application doesn't use; verify which property the business actually needs before defaulting to the more powerful option.
• Spanner's multi-region write latency is real and higher than single-region Spanner or a well-placed Cloud SQL primary serving nearby users; a workload that's latency-sensitive on writes specifically (not just consistency-sensitive) needs to be tested against that added latency, not assumed away.
• A cross-region Cloud SQL topology can look deceptively similar to Spanner on paper (multiple regions, replicas), which is exactly what makes it easy to mis-recommend for a workload that actually needs strongly-consistent global writes; the failover behavior and write-path latency are where the architectures diverge in practice, not just theory.

Direct answer

After a drill I run a structured post-exercise review that classifies every finding as people, process, or technology, scores it for severity, assigns a single named owner and a due date scaled to that severity, and requires an independent verification test before the finding can be closed, not just the owner's word that it's fixed. Individual findings then roll up into a small set of trend metrics that a recurring governance review looks at, so leadership can tell whether the continuity program is actually improving over time rather than just accumulating a backlog of open tickets.

Structured elaboration

Classification. People (training, staffing, or awareness gaps, like nobody being reachable at the right time), process (a missing, wrong, or unclear runbook step), or technology (a system or tooling failure). Many findings are genuinely two categories at once, for example an automated failover script that failed is a technology issue, but nobody catching the error before the drill is a process issue in the review or testing procedure itself; classify the root cause that, if fixed, prevents recurrence, not just the surface symptom.

Severity and ownership. Score each finding by business impact: does it threaten a documented recovery time objective (RTO, the target time to get a function working again) or recovery point objective (RPO, how much recent data the function can afford to lose, measured in time), or does it block declaration authority (who has the standing to formally declare and activate the plan) entirely? Assign one accountable owner per finding, with a sponsor who can escalate if it stalls. Critical findings get the shortest fuse and the most visible tracking.

Verification before closure. The distinction that matters most: "marked done" is not the same as "closed." A finding should only close once there's an independent verification test, ideally at the next scheduled exercise from the tabletop-to-full-scale ladder, confirming the fix actually works, not a self-report from the person who made the change.

Governance cadence and trend metrics. Individual findings feed a recurring review, for example a quarterly continuity steering meeting, that tracks two things at the aggregate level: how quickly findings are actually closing (with verification, not just ticket status), and whether the same root cause is recurring across drills, which indicates the underlying plan or system was never really fixed the first time. This is what turns a series of one-off reviews into evidence the program is maturing, and it's also the artifact regulators and auditors typically want (see the regulatory-obligations answer on this topic for what a compliance program expects to see documented).

Tooling. Track findings in a central, auditable system (a ticketing tool with status, owner, and due date, not a slide deck that gets archived and forgotten), since the whole point of the review is a defensible trail from finding to verified fix.

Worked example

A team ran four quarterly drills and tracked how many days it took to close each Critical finding, from the day it was logged to the day its verification test passed. In Q3, five Critical findings closed with these lead times in days: 12, 18, 21, 25, and 29.

$$\text{Average close time} = \frac{12+18+21+25+29}{5} = \frac{105}{5} = 21 \text{ days}$$

That 21-day average, tracked quarter over quarter alongside a second metric (the percentage of findings that recur in a later drill), is what the quarterly steering review actually looks at. A shrinking average close time with a low recurrence rate is real evidence the program is improving; a shrinking close time with a high recurrence rate usually means findings are being marked closed to hit the metric without the underlying gap actually being fixed, which is exactly why the verification-test requirement exists.

Trade-offs and pitfalls

Measuring only closure speed creates a perverse incentive to close findings before they're actually fixed, which is why speed has to be paired with a recurrence-rate metric, not tracked alone. Remediation work reliably stalls when the team is busy with feature delivery unless a named executive sponsor has the standing to protect capacity for it; without that sponsor, "we'll get to it" quietly becomes never. It's also worth being explicit about what this process is not: it's a review of the continuity plan and program itself, not a technical incident post-mortem of a system failure, so the findings and remediation often land on documentation, staffing, and ownership as often as they land on a system fix.

Direct answer. I would sell a fixed-scope, evidence-based review: a two-week "posture review" built from the same six steps every time, delivered as a short written summary plus a call. I would promise what I can observe and show (architecture, controls as designed, evidence we already hold) and refuse to promise anything that amounts to a guarantee of security, a penetration test (an authorised, hired attempt to break into the product to find weaknesses) I have not run, or access to production.

Scope (what the review covers). Architecture review means walking the design and asking where trust boundaries (points where data passes between parts that trust each other differently, such as browser to server or our service to a partner) are and whether controls sit in the right layers. Keep it to the product the prospect will actually use.

The ten working days are two calendar weeks, so the call lands on a weekday.

Repeatable. The architecture pack, the evidence index (a maintained list that maps each security claim to the document or report that proves it) and the answer library are maintained once and reused. Once the library exists, a second prospect should cost hours rather than weeks (an expectation to confirm by timing the first two reviews, not a measured figure). Anything new that a prospect asks goes back into the library.

What I refuse to promise.

• Any claim that the product is "secure" or "unbreachable". I state controls and evidence, with dates.
• A custom penetration test or code review inside two weeks, or any testing of production by the prospect.
• Features or fixes on a date before engineering has committed.
• Certification we do not hold. If the prospect wants an audit report we lack, I say so and offer a roadmap date only if leadership has approved it.
• Exceptions to standard contractual security terms; those go to legal.

Worked example. A prospect will upload customer invoices and asks for single sign-on, encryption at rest and a 24-hour breach notice. On day 1 I note invoices are sensitive financial data. In the architecture walk I confirm SSO and encryption are in the standard design, but find the audit log is not exportable. The gap table says: SSO met (evidence: configuration doc), encryption met, the log export gap is compensated (covered in the interim) by sending the prospect a monthly activity report until the export feature ships, roadmap item for the next quarter with product owner named. The 24-hour breach notice goes to legal, because it is a contract commitment, not an architecture fact.

Trade-offs and pitfalls. Over-sharing internal diagrams without a non-disclosure agreement; answering questionnaire rows from memory instead of from the evidence index; letting sales promise the roadmap. What would change my call: a very large deal could justify an outside penetration test that we schedule after signing, with the prospect's agreement, but never inside the two-week window.