Region Choice Under a Residency Constraint
Northwind Capital is migrating its trade-surveillance platform to a public cloud ahead of a regulatory deadline. The regulator requires that trade records be stored and processed only within country X. The provider operates a region in country X with three availability zones, but that region exposes only about 60% of the provider's managed services; the full catalogue is available in a region two countries away. In the pilot, p95 write latency hit 240 ms against an 80 ms internal SLA, traced to the application's calls to a managed message broker and a managed identity service that exist only in the remote region. The platform team proposes keeping the database in country X and calling the remote broker. Budget covers either a second in-country region or a self-managed broker, not both. The audit committee wants a decision in two weeks.
1. The platform team proposes keeping all persistent data in country X while calling the managed broker and identity service in the remote region. Evaluate that proposal against the regulator's requirement, the latency SLA, and availability.
Read the worked answer
The proposal fails the requirement as written, not merely in spirit. The constraint covers processing, not only storage. A message payload carries trade records; publishing it to a broker two countries away is a cross-border transfer and a processing event, and the remote identity service reads authentication metadata for in-scope users. Keeping the database local does not cure either.
- Latency: 240 ms p95 against an 80 ms SLA is a threefold miss on every write path. It is a synchronous WAN round trip, so it will not tune away.
- Availability: region X now inherits the remote region's failure domain. An outage there takes down a system the regulator believes is in-country.
- Audit exposure: the design is describable in one sentence an examiner will reject, and it makes every future residency attestation conditional.
No amount of local storage makes the remote broker defensible.
2. Recommend an architecture and justify the trade-off between the second region and the self-managed broker.
Read the worked answer
Establish the constraint hierarchy first. Residency is regulatory and non-negotiable. Latency is commercial but contractual. Disaster recovery is important yet not the binding constraint this quarter. That ordering eliminates the remote broker regardless of price.
Recommendation: deploy the full stack in country X and replace the managed broker with a self-managed broker across the three in-country AZs - unless the provider's reduced in-country catalogue already includes a queueing service, which you must verify before designing. Spend the budget on removing the cross-border dependency rather than on a second region: a second in-country region improves RTO and does nothing for the 240 ms p95.
Trade-offs to state explicitly: you absorb broker patching, upgrade cadence, and HA engineering that a managed service previously carried; the shared-responsibility line moves toward you. That is a known, bounded cost, unlike a regulatory finding. If any in-region queueing service exists, the calculus flips - take it even if it is less capable.
Residual risk: operational maturity of a self-managed broker; mitigate with IaC, a patching SLA, and a documented failover test before go-live.
3. If the broker is self-managed on IaaS, allocate shared responsibility for broker patching, TLS certificates the application terminates itself, and encryption at rest.
Read the worked answer
Split by layer, and be precise about where the boundary sits.
| Component | Provider | Customer |
|---|---|---|
| Physical hosts, hypervisor, network fabric, AZ power | Yes | - |
| Broker OS, patching, hardening | - | Yes |
| Broker configuration: auth, ACLs, listener TLS | - | Yes |
| TLS certificates the app terminates itself: issuance, rotation, private key custody | - | Yes |
| Encryption at rest cipher and key store | Yes | - |
| Key policy, access grants, choice of provider-managed keys | - | Yes |
| IAM policies, security groups, NACLs | - | Yes |
| Backups and restore testing | - | Yes |
The exam-relevant point: moving from a managed service to IaaS does not make the provider responsible for availability of your broker; it guarantees only the substrate. Conversely, if you adopt a managed in-region queue, patching of the broker software reverts to the provider while configuration and IAM remain yours. Record this matrix in the migration design so the audit committee sees the shift in accepted risk, not just the shift in cost.