Cloud Digital Leader Why cloud technology is transforming business Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Avoiding cloud entirely and keeping all services on-premises to maintain full control

  Why it's wrong here

  Rejecting cloud entirely to keep everything on-premises forfeits the core benefits the question is about—elastic scaling, cost-efficient managed services, geographic redundancy, and innovation velocity—while failing to eliminate lock-in: on-prem systems still depend on specific hardware vendors, hypervisors, and middleware that have their own upgrade cycles and incompatibilities. It replaces a manageable architectural risk with a strategic risk of being underserved by on-prem-only capacity, slower release cadence, and larger capital expenses, all without any inherent portability gain. The goal is not to avoid cloud but to adopt it in a way that keeps exit costs proportional to effort, which is achieved through containerization and open APIs, not by refusing to move.

• ✗

  Using only one cloud provider's most specialized proprietary services for all workloads to maximize integration

  Why it's wrong here

  Relying exclusively on a single provider's most proprietary services (e.g., proprietary databases, workflow engines, and serverless event architectures) maximizes the opposite of portability: each proprietary feature trains your code, data models, and operational runbooks on interfaces that have no equivalent elsewhere. This creates deep lock-in because even a minor change in usage patterns can trigger a multi-month migration, and the provider's pricing or feature roadmap becomes an unnegotiable factor in your architecture. Unlike open standards, which trade some integration convenience for choice, this approach explicitly trades all future choice for near-term integration, making the provider an irreplaceable dependency rather than a disposable vendor.

• ✓

  Adopting open standards, containerized workloads, and a multi-cloud or hybrid architecture to preserve portability while benefiting from cloud services

  Why this is correct

  Adopting open standards such as Kubernetes for orchestration, containerized workloads for packaging dependencies, and a multi-cloud or hybrid architecture to distribute risk directly addresses the root cause of cloud lock-in: proprietary APIs and data gravity. Containers run consistently across any CNCF-compliant cluster, while SQL-compatible databases and open protocols (e.g., OIDC, S3) let teams migrate components between providers without rewriting code. This preserves the ability to consume high-value cloud services (managed AI, analytics, serverless) while retaining the architectural freedom to move workloads when business, cost, or compliance needs change.

• ✗

  Negotiating a contract with the cloud provider that forbids them from changing their service APIs

  Why it's wrong here

  Contractually prohibiting a provider from altering service APIs is structurally infeasible because cloud providers must evolve APIs to fix security flaws, meet legal obligations, and deploy new features—major API versions have finite support lifetimes, and deprecation is an operational necessity, not a negotiable clause. Even if such a clause were signed, it would not prevent the provider from announcing end-of-life or refusing to fix critical bugs in an old version, and suing for breach would take years while your production workloads are already broken. This approach treats a commercial agreement as a technical guarantee, which no jurisdiction or engineering reality can uphold, and it does nothing to reduce baseline reliance on a single vendor's control plane.

Go deeper

Related to this question