Multi-cloud, lock-in, and making the case to the business

Why this matters

The previous lesson gave you the two axes. This one is about the arguments people actually have, because CompTIA's wording for this objective ends in "to support business needs" — and the exam takes that seriously. A large share of the questions on this objective are not "what is a hybrid cloud" but "given these constraints, which model, and why".

Those questions have a consistent structure: two options are technically workable and one fits the stated driver better. Answering them well means knowing what each model actually costs, not just what it offers. Multi-cloud in particular is oversold in marketing and undersold in exam answers — it buys a real thing, and it charges a real price.

The lesson

What multi-cloud actually buys, and the operational cost it charges for it

Multi-cloud means deliberately running on more than one public provider. The honest list of benefits is shorter than the brochure's:

• Provider-level resilience. If one provider has a regional or control-plane failure, a workload that genuinely runs on both survives. Note genuinely — a warm copy nobody has ever failed over to is a plan, not a capability.
• Commercial leverage. A credible ability to move is worth money at renewal.
• Access to a specific capability. One provider has the managed service or the regional footprint you need; the rest of the estate is elsewhere.
• Regulatory or customer requirement. Some contracts and some regulators require provider diversity.

The costs are consistently underestimated, and they are operational rather than technical:

• Everything is duplicated. Identity, networking, monitoring, logging, backup, cost management and the runbooks for all of them — twice, with different names and different behaviour.
• Skills are duplicated. Deep knowledge of two platforms is much more than twice as hard to maintain as deep knowledge of one, because the second set is used less and therefore stays shallower.
• You are pushed toward the lowest common denominator. The easiest way to stay portable is to use only the features both providers share, which usually means declining the managed services that made the cloud worth using.
• Inter-provider data transfer is billed egress, and it is the charge that quietly makes some multi-cloud designs uneconomic.

The exam-relevant summary: multi-cloud is a risk and commercial decision with an operational price. If a scenario's driver is cost or speed, multi-cloud is usually the wrong answer. If the driver is provider-failure resilience or a stated contractual requirement, it is usually the right one.

Vendor lock-in: data gravity, egress fees and the proprietary managed service

Lock-in is the difficulty of leaving. It comes from three places, and they are worth separating because they have different remedies.

Data gravity. Data accumulates, and everything else moves toward it. Petabytes are slow and expensive to move, and the applications that use them want to be close to them. The more data sits with one provider, the more the next system gets built there too — not by decision, but by physics and latency.

Egress economics. Getting data in is usually free. Getting it out is usually not. That asymmetry is not an accident; it is the commercial shape of the market, and it means the cost of leaving scales with how successful you have been.

Proprietary services. The managed services that save the most operational effort are the least portable: a provider-specific serverless platform, a proprietary data warehouse, a managed message bus with its own semantics. The value and the lock-in are the same feature.

The mitigations, roughly in order of how often they are the right answer:

• Accept it deliberately for the parts where the benefit is large, and write down that you did. Deliberate lock-in with open eyes is a normal engineering decision.
• Standardise the portable layer. Containers, open data formats and infrastructure-as-code reduce the cost of a move without giving up much.
• Keep an exit plan for the data, even if you never use it: where would it go, how long would it take, what would the egress cost.
• Abstract the provider away entirely — and be suspicious of this one. An abstraction layer over two providers is a third platform to maintain, and it usually delivers the lowest common denominator with extra steps.

Cloud bursting and the hybrid pattern that keeps a regulated workload at home

Cloud bursting is the hybrid pattern most often named in exam scenarios: a workload runs on private infrastructure sized for its normal load, and overflow capacity is provisioned in a public cloud when demand spikes.

It is attractive on paper and it has real preconditions, which is usually what the question is testing:

• The application must scale horizontally, and the burst nodes must be able to join the pool without manual work.
• There must be adequate, low-latency connectivity between the environments.
• The data must be reachable from the burst capacity without moving the whole dataset — which is why bursting suits stateless front ends and compute jobs, and suits databases badly.
• Images and configuration must exist in both places, which in practice means infrastructure as code.

The other common hybrid pattern is the inverse: keep the regulated workload private and put everything else public. A scenario mentioning data residency, a regulator, cardholder data or patient records, alongside a desire for elasticity elsewhere, is describing this. The answer is hybrid, and the interesting part is the join — identity federation, network connectivity and a clear data boundary.

Both patterns depend on the connectivity covered in objective 1.3, which is why the exam happily mixes the two objectives in a single scenario.

Matching a model to a stated business driver: cost, resilience, sovereignty or speed

A compact mapping to carry in:

Two cautions the exam rewards. Cost is rarely a clean argument for public cloud — it can be cheaper or more expensive depending on utilisation, and a steady, fully-utilised workload is often cheaper on owned hardware. And "security" is not a driver on its own; ask what the security requirement actually is, because sovereignty, tenancy and control point to different answers.

Answering "which model" questions when two options are technically fine

When you have eliminated the clearly wrong options and two remain, work through this order:

1. Re-read for the constraint. A single phrase — "must not leave the EU", "cannot be shared with other customers", "three-year hardware refresh just completed" — usually eliminates one option outright.
2. Prefer the simplest thing that meets it. Exams reward the minimum sufficient answer. If private meets every stated need, multi-cloud is not a better answer for being more capable.
3. Check who operates it afterwards. If the scenario stresses a small team or a lack of specialist skills, that argues up the service-model axis and against multi-cloud.
4. Watch for a drivers conflict. Where a scenario states two drivers that pull apart — lowest cost and provider-failure resilience — the answer is the one addressing the requirement stated as mandatory, with the other treated as a preference.
5. Do not pick on technical elegance. The best-engineered option is a distractor when the scenario's driver is a deadline or a regulator.

What to take into the exam

• Multi-cloud buys provider-failure resilience and leverage and charges duplicated operations, duplicated skills and egress. It is not a cost or speed play.
• Lock-in comes from data gravity, egress pricing and proprietary services. Deliberate lock-in is a legitimate decision; undocumented lock-in is not.
• Cloud bursting needs horizontal scaling, connectivity and a data strategy. It suits stateless compute and suits databases badly.
• Hybrid is the usual answer when a regulated workload must stay put while the rest needs elasticity.
• When two options both work, the stated driver decides, and the simplest sufficient option wins.