hardMultiple Select
CCSP Practice Question: A cloud architect is designing a multi-cloud…
A cloud architect is designing a multi-cloud strategy to avoid vendor lock-in. Which three design considerations should be included? (Choose three.)
⚠ Common exam trap
ISC2 often tests the misconception that standardizing on a single provider's core services is part of a multi-cloud strategy, when in fact it increases lock-in, and that provider-specific APIs are acceptable for portability, when they directly undermine the abstraction goal.
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
✓
Implement abstraction layers such as containers or cloud-agnostic APIs
Option A is correct because abstraction layers such as containers (e.g., Docker images orchestrated by Kubernetes) and cloud-agnostic APIs (e.g., S3-compatible object storage, OpenTofu/Terraform) decouple workloads from any single provider's proprietary interfaces, making migration between clouds feasible. Option B is correct because designing applications as loosely coupled microservices, ideally packaged in portable containers and communicating over standard protocols like HTTP/REST or gRPC, allows individual services to be redeployed on another provider without rewriting the whole application. Option C is correct because using cloud-agnostic data formats and storage interfaces (e.g., Parquet, JSON, SQL, or S3-compatible APIs) prevents data from being trapped in a proprietary store and keeps it readable and movable across providers. Option D is incorrect because standardizing on a single cloud provider for core services increases vendor lock-in rather than avoiding it. Option E is incorrect because provider-specific APIs, while sometimes offering better performance or deeper feature integration, tightly couple the application to that vendor and undermine portability.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Implement abstraction layers such as containers or cloud-agnostic APIs
Why this is correct
Abstraction layers decouple workloads from provider-specific services, letting containers and cloud-agnostic APIs run unchanged across AWS, Azure and Google Cloud. This directly satisfies the stem's vendor lock-in constraint by enabling portability, so migration between providers avoids the costly re-engineering that proprietary APIs and managed services would otherwise force.
- ✓
Design applications with portability in mind using microservices
Why this is correct
Microservices decouple application components into independently deployable services communicating via APIs, so workloads can migrate between providers without re-engineering monolithic code. This directly satisfies the stem's vendor lock-in constraint: portability across clouds is achieved because each service's runtime dependencies stay minimal and provider-agnostic.
- ✓
Choose cloud-agnostic data formats and storage interfaces
Why this is correct
Cloud-agnostic data formats and storage interfaces let data be read and moved across providers without proprietary translation. This satisfies the anti-lock-in goal by preventing data gravity from binding the organisation to one vendor's storage APIs.
- ✗
Standardize on one cloud provider for core services
Why it's wrong here
Standardising on a single provider for core services concentrates dependence on that vendor's APIs, pricing and regions, directly contradicting the anti-lock-in goal. It would be correct when consolidating for cost, unified identity or operational simplicity rather than portability.
- ✗
Use provider-specific APIs for optimal performance
Why it's wrong here
Provider-specific APIs bind application code to one vendor's interfaces, so migration requires rewriting integrations, which is the lock-in the strategy must avoid. They would be correct when maximising native feature depth within a single-cloud deployment where portability is not a requirement.
Quick reference
AWS S3 Storage Class Comparison
| Storage Class | Min Duration | Retrieval | Use Case |
|---|---|---|---|
| S3 Standard | None | Immediate | Frequently accessed data |
| S3 Standard-IA | 30 days | Immediate | Infrequent access, rapid retrieval |
| S3 One Zone-IA | 30 days | Immediate | Non-critical infrequent data |
| S3 Intelligent-Tiering | None | Immediate–hours | Unknown or changing access patterns |
| S3 Glacier Instant | 90 days | Milliseconds | Archive with instant retrieval |
| S3 Glacier Flexible | 90 days | Minutes–hours | Archive, flexible retrieval |
| S3 Glacier Deep Archive | 180 days | Hours | Long-term compliance archive |
Go deeper
Related to this question
About these practice questions
One of 934 original CCSP practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
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.