5 exercises — IaaS/PaaS/SaaS/FaaS/CaaS service models, SLA vs. SLO vs. SLI, CDN edge caching, and spot instance tradeoffs.
0 / 5 completed
1 / 5
A vendor comparison table lists "IaaS, PaaS, and SaaS" as three cloud service models. What do these three abbreviations mean, and how do they differ?
IaaS / PaaS / SaaS describe an increasing level of abstraction, and correspondingly, decreasing responsibility for the customer. The standard way to remember it: as you move from IaaS to SaaS, you manage less and the provider manages more. Each layer builds on the one below it — a SaaS product is typically built on top of PaaS or IaaS infrastructure that the vendor manages internally.
These abbreviations are foundational vocabulary for describing any cloud architecture decision — "should we run this ourselves on IaaS, or use a managed PaaS" is one of the most common early architecture conversations in any project.
2 / 5
A newer term appears in a serverless architecture discussion: "FaaS" and "CaaS". How do these relate to the more familiar IaaS/PaaS/SaaS model?
FaaS (Function as a Service) is the technical foundation of "serverless" computing — you write a single function, it runs only when triggered (an HTTP request, a queue message, a scheduled event), scales automatically, and you're billed per invocation/execution time rather than for an always-running server.
CaaS (Container as a Service) gives you the flexibility of packaging your app as a container (more control than FaaS, since you're not limited to a single function's execution model) without managing the underlying servers or orchestration cluster yourself.
Recognising the full family — IaaS, PaaS, SaaS, FaaS, CaaS — and correctly slotting a new product announcement into the right category ("is this FaaS or PaaS?") is a common technical vocabulary test in architecture discussions and cloud certification exams alike.
3 / 5
A support ticket references "our SLA guarantees 99.95% uptime." What does SLA stand for, and how does this relate to the terms "SLO" and "SLI" that often appear alongside it?
SLA / SLO / SLI form a related trio that's frequently tested and frequently confused. The relationship, from most to least formal:
• SLA (Service Level Agreement) — an external, often contractual commitment made to customers, typically with defined consequences (service credits, refunds) if breached • SLO (Service Level Objective) — an internal target the engineering team holds itself to, usually set stricter than the SLA to provide a safety margin before actually breaching the customer-facing commitment • SLI (Service Level Indicator) — the actual, concrete measurement (e.g. "percentage of requests completed under 200ms," "percentage of successful requests") used to determine whether the SLO/SLA is currently being met
Memory aid: Agreement (external, legal) → Objective (internal, target) → Indicator (measured, real number) — moving from the most formal/external to the most concrete/measurable.
4 / 5
A content delivery discussion mentions "using a CDN to reduce latency for users in different regions." What does CDN stand for, and why does it reduce latency specifically?
CDN (Content Delivery Network) works by caching content (static files, images, sometimes API responses) at many "edge" locations around the world. When a user requests content, it's served from the nearest edge server rather than travelling all the way to a single origin server, which directly reduces round-trip network latency — the physical distance data has to travel is often the dominant factor in perceived load time for geographically distant users.
Related vocabulary commonly paired with CDN:edge location (a CDN's regional server), cache hit/miss (whether content was already cached at that edge location or had to be fetched from origin), origin server (the source server the CDN pulls from when content isn't cached), TTL (Time To Live) (how long cached content is considered valid before the CDN re-fetches it from origin).
5 / 5
A cloud cost-optimisation discussion mentions "moving to spot instances could reduce our EC2 costs" alongside "we should check our SLA before switching." How would you explain the tradeoff being discussed?
This scenario tests whether you can connect two separate abbreviations (spot instances aren't technically an abbreviation, but the cost-vs-reliability tradeoff vocabulary and the SLA concept) into a coherent architecture decision — a common real-world pattern in cloud cost conversations.
Spot instances (AWS terminology; other clouds use similar concepts like "preemptible VMs" on GCP) offer significant discounts (often 60-90% off on-demand pricing) in exchange for the provider's right to reclaim the capacity with short notice when it's needed elsewhere.
Why the SLA connection matters: if a workload is running under a customer-facing SLA promising high availability, running it entirely on interruptible spot instances without a fallback strategy risks breaching that SLA when instances are reclaimed. The mature approach — often described as a mixed fleet — runs a baseline of on-demand (or reserved) instances to guarantee SLA-covered capacity, supplemented by spot instances for the elastic, interruption-tolerant portion of the workload.
What will I practice in "Cloud Abbreviations — IT Abbreviations Exercises"?
This is an IT Abbreviations exercise set. It walks through 5 scenario-based multiple-choice questions built around real usage of IT Abbreviations terminology that IT professionals encounter on the job.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to complete with no account, sign-up, or paywall.
How many questions are in this exercise?
This set contains 5 questions. Each one shows immediate feedback and a detailed explanation after you answer, so you learn the correct usage right away rather than waiting for a final score.
Do I need prior experience to complete this exercise?
No prior experience is required. Each question includes a full explanation covering the reasoning behind the correct answer, so the exercise itself teaches the IT Abbreviations vocabulary as you go.
Can I retry the exercise if I get questions wrong?
Yes — use the "Try again" button on the results screen to reset your answers and go through all the questions again. There is no limit on attempts.
Is my progress saved?
Your answers and score for the current session are tracked in the browser as you go. No account or login is needed, and there is nothing to install.
What if I don't understand a term used in a question?
Read the explanation shown after you answer each question — it breaks down the correct term in plain English with a real-world example. You can also check the site Glossary for quick definitions.
How is this different from reading a blog article on the topic?
Exercises like this one are interactive drills that test and reinforce specific vocabulary through multiple-choice questions, while blog articles explain concepts in prose. Practising here after reading builds active recall, not just passive recognition.
Where can I find more IT Abbreviations exercises?
See the IT Abbreviations exercises hub for the full set of related pages, or browse all exercise categories from the main Exercises index.
Can I use this exercise to prepare for a technical interview?
Yes — IT Abbreviations vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.