Learn the vocabulary of logging intended changes durably before applying them to data pages so a crash can be safely replayed.
0 / 5 completed
1 / 5
A teammate explains that a database appends every intended change to a sequential log file and forces it to durable storage before applying that change to the actual data pages, so a crash mid-update can be replayed from the log instead of corrupting the data. What technique is being described?
Write-ahead logging is exactly this: every intended change is appended to a sequential log file and forced to durable storage before the change is applied to the actual data pages, so if a crash happens mid-update, the log can be replayed on restart to recover exactly the changes that were durably logged but not yet applied. A DNS zone transfer is an unrelated concept about replicating name server records. This log-before-apply approach is exactly why write-ahead logging is the standard durability mechanism in relational databases.
2 / 5
During a design review, the team relies on write-ahead logging for a database that must survive a power loss mid-transaction without corrupting data pages. Which capability does this provide?
Write-ahead logging here provides crash-safe durability via replayable logged intent, since the log records every change before it touches data pages and can be replayed to recover the exact pre-crash state. Applying changes directly to data pages with no log at all risks leaving pages in a half-updated, corrupted state if a crash occurs mid-write, with no record of what was intended. This log-before-apply-then-replay behavior is exactly why write-ahead logging is required for crash-safe durability.
3 / 5
In a code review, a dev notices a storage layer applies updates directly to data pages on disk with no preceding log entry, instead of writing the intended change to a durable log first as write-ahead logging would require. What does this represent?
This is a missed write-ahead-logging requirement, since applying updates directly with no log risks leaving data pages corrupted if a crash interrupts the write. A cache eviction policy is an unrelated concept about discarded cache entries. This log-free-direct-write pattern is exactly the kind of durability gap a reviewer flags once crash safety is required.
4 / 5
An incident report shows a database was left with a corrupted data page after a power failure interrupted an in-place update, because the change had been applied directly to disk with no preceding durable log entry to replay on restart. What practice would prevent this?
Adopting write-ahead logging ensures every change is durably logged before being applied, letting the log be replayed to recover the intended change after a crash instead of leaving the page corrupted. Continuing to apply updates directly to data pages with no log regardless of how often power failures interrupt in-place writes is exactly what caused the corruption described in this incident. This log-before-apply approach is the standard fix once direct in-place writes are confirmed to risk corruption on crash.
5 / 5
During a PR review, a teammate asks why the team relies on write-ahead logging instead of just fsyncing the data pages directly after every update, given that fsyncing the pages themselves seems like it should already guarantee durability. What is the reasoning?
Write-ahead logging trades the overhead of an extra sequential log write for crash safety even if a page write is interrupted mid-flush, while fsyncing data pages directly still risks a torn, half-written page if the crash lands during that very fsync. This is exactly why write-ahead logging is the standard mechanism for crash-safe durability in databases, while relying solely on fsyncing data pages directly leaves a torn-write window that logging closes.
What does the "Write-Ahead Logging Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to write-ahead logging vocabulary through 5 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 5 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — browse the full vocabulary exercises hub to find related modules covering adjacent IT topics and roles.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.