CCSP Cloud Concepts, Architecture, and Design Practice Question
An organization is designing a multi-cloud strategy using containers to avoid vendor lock-in. Which of the following approaches BEST ensures portability of containerized applications across different cloud providers?
⚠ Common exam trap
CCSP often tests the assumption that using containers automatically guarantees portability, when in fact proprietary orchestration services and cloud-specific integrations can reintroduce lock-in.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Standardize on Docker images and Kubernetes orchestration with open-source tooling.
Standardizing on Docker images and Kubernetes orchestration with open-source tooling (C) best ensures portability because Docker images are OCI-compliant and Kubernetes is a CNCF-graduated project supported by all major cloud providers. This combination avoids proprietary APIs and allows workloads to be moved between AWS EKS, Azure AKS, Google GKE, or on-premises clusters with minimal changes. Open-source tooling further reduces lock-in by providing consistent APIs and configuration formats.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use cloud provider-specific container services like Amazon ECS with proprietary APIs.
Why it's wrong here
Amazon ECS with proprietary APIs binds workloads to AWS constructs, so images and orchestration definitions cannot be lifted to another provider without rework. It is tempting because managed services reduce operational effort; it would be correct where the organisation commits to a single provider and prioritises convenience over portability.
- ✗
Use nested containers to abstract the underlying cloud provider.
Why it's wrong here
Nested containers add runtime layers without removing dependence on the host provider's orchestrator, networking and storage interfaces, so portability is not achieved. It is tempting because abstraction sounds like insulation from vendor specifics; it would be correct where isolation between workloads, not cross-provider movement, is the objective.
- ✓
Standardize on Docker images and Kubernetes orchestration with open-source tooling.
Why this is correct
Standardising on Docker images with Kubernetes orchestration and open-source tooling removes provider-specific dependencies, so the same artefacts deploy unchanged across clouds. This directly satisfies the stem's portability requirement, unlike managed proprietary services that bind workloads to one vendor.
- ✗
Deploy containers directly on virtual machines without an orchestration layer.
Why it's wrong here
Without an orchestrator, scheduling, service discovery, scaling and health management must be hand-built per provider, so the same container images still need provider-specific glue, undermining portability. It is tempting because running containers on plain VMs is simple and avoids Kubernetes complexity, and would suit a single small static workload on one cloud.
About these practice questions
Courseiva writes every CCSP question from scratch — 934 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official ISC2 exam blueprint
This CCSP practice question is part of Courseiva's free ISC2 certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CCSP exam.