5 exercises — ETL vs. ELT, OLTP vs. OLAP, Change Data Capture (CDC), RPO vs. RTO disaster recovery targets, and connecting data vocabulary in real scenarios.
0 / 5 completed
1 / 5
A data engineer explains: "We're rebuilding our ETL pipeline as ELT instead." What's the difference between ETL and ELT?
The ETL-to-ELT shift reflects how modern cloud data warehouses (a DWH, or data warehouse) became powerful enough to handle transformation workloads themselves, removing the need for a separate transformation server/step before loading.
ETL (Extract, Transform, Load) — the traditional pattern: pull data from a source, transform/clean/reshape it in a dedicated processing layer, then load the finished result into the warehouse. This front-loads all transformation logic before data ever lands in the warehouse.
ELT (Extract, Load, Transform) — load raw data into the warehouse first, then run transformations as SQL (or dbt models) directly against the warehouse's compute. This is now the dominant pattern for cloud-native data stacks, since it keeps raw data available for re-processing and leverages the warehouse's scalable compute rather than a separate ETL server.
2 / 5
A database architecture discussion contrasts "OLTP" and "OLAP" systems. What's the fundamental difference, and why can't one database type efficiently serve both purposes?
The OLTP vs. OLAP distinction explains why companies typically run a separate analytics/reporting database (data warehouse) rather than running heavy analytical queries directly against their production application database.
OLTP — designed for high-concurrency, low-latency operations on individual records (insert an order, update a user's profile). Uses row-based storage, since a full row is usually read/written together. Running a large analytical query (e.g. "total revenue by region for the last 3 years") against an OLTP database can be slow and, worse, can lock rows or consume resources needed for live application traffic.
OLAP — designed for scanning and aggregating large volumes of data efficiently. Uses column-based storage, since analytical queries typically read a few columns across many rows (e.g. just amount and region, summed across millions of rows) rather than entire rows.
This is precisely why CDC (Change Data Capture) — streaming changes from the OLTP database into an OLAP warehouse — exists as a standard pattern: it keeps analytics fresh without burdening the production database.
3 / 5
A database replication discussion mentions "using CDC to stream changes from Postgres into our data warehouse in near real-time." What does CDC stand for, and how does it differ from a nightly batch export?
CDC (Change Data Capture) is a foundational technique in modern data pipelines, enabling near-real-time data synchronisation without the overhead of repeatedly scanning and re-exporting an entire source table.
How it typically works: CDC tools (e.g. Debezium, or built-in features of some cloud databases) read the source database's transaction log (also called the write-ahead log or binlog, depending on the database) — the internal record every database already maintains of every change — and stream those changes to a downstream consumer (a message queue, then a data warehouse) as they occur.
Why this beats a nightly batch export: a full nightly export means downstream analytics are always up to 24 hours stale, and re-exporting an entire large table repeatedly wastes resources on data that hasn't changed. CDC only propagates what actually changed, arriving with much lower latency — often seconds to minutes rather than a full day.
4 / 5
A disaster recovery plan states: "Our RPO is 15 minutes and our RTO is 2 hours." How would you explain these two targets to a non-technical stakeholder?
RPO and RTO are the two core metrics of any disaster recovery plan, and precisely distinguishing them is essential since they drive very different engineering investments.
RPO (Recovery Point Objective) answers "how much data can we afford to lose?" — it's driven by how frequently data is backed up or replicated. A tighter RPO (e.g. near-zero) requires continuous replication to a standby system; a looser RPO (e.g. 24 hours) can be satisfied by nightly backups alone.
RTO (Recovery Time Objective) answers "how long can we afford to be down?" — it's driven by how quickly a failover or restoration process can complete. A tight RTO (minutes) typically requires an already-running standby system ready to take over instantly (hot standby); a looser RTO (hours/days) might allow restoring from backups onto freshly provisioned infrastructure.
Explaining a DR plan clearly to stakeholders means stating both numbers together — "we could lose up to 15 minutes of data, and we'd be back online within 2 hours" — since either number alone tells only half the story.
5 / 5
A data platform review notes: "Our OLTP database's SLA guarantees 99.9% availability, but our nightly ETL job occasionally causes replication lag that briefly affects our OLAP dashboards." How would you summarise this situation using the correct terms?
This scenario tests whether you can correctly connect multiple data-engineering abbreviations into one precise, accurate technical summary — a genuinely valuable communication skill when reporting incidents or explaining architecture to stakeholders who might otherwise conflate "the database is down" with "the dashboard shows old data," which are very different severities.
Precise summary components: • The SLA applies specifically to the production OLTP system — its own separate availability commitment, unaffected by the ETL job • Replication lag — the delay between a change happening in the source and that change being reflected downstream — is the specific mechanism causing staleness, distinct from an outage • The OLAP dashboards being briefly stale is a data-freshness issue, not an availability issue, and typically doesn't violate any uptime SLA at all (unless a separate freshness SLA exists for the dashboards specifically)
Being able to say precisely "this is a data-freshness issue in the OLAP layer, not an availability issue in the OLTP layer" prevents an overreaction (treating a minor lag as a major outage) and correctly directs the fix toward the ETL/replication pipeline rather than the production database.
What will I practice in "Data 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.