Learn the vocabulary of guaranteeing a database change survives a crash before it's applied.
0 / 5 completed
1 / 5
At standup, a dev mentions that a database records every change to an append-only log on durable storage before applying that change to its actual data files. What is this durability mechanism called?
A write-ahead log, or WAL, records every change to an append-only log on durable storage before that change is actually applied to the database's own data files, guaranteeing the change survives a crash even if it hadn't yet been applied to the main data files. Applying a change directly to the data files first, with no separate log, risks losing that change entirely if a crash happens mid-write. This log-first ordering is the foundation of how a database guarantees durability after a commit.
2 / 5
During a design review, the team wants the database to replay its write-ahead log after an unexpected crash, reconstructing any change that hadn't yet been fully applied to the data files. Which capability supports this?
Crash recovery through write-ahead log replay reconstructs any change that hadn't yet been fully applied to the data files by replaying the durable log after an unexpected crash. Assuming a clean restart with no replay risks silently losing a committed change that was logged but not yet applied. This replay mechanism is what lets a database confidently promise that a committed change survives a crash, not just an orderly shutdown.
3 / 5
In a code review, a dev notices the database periodically checkpoints its data files to match the write-ahead log, allowing older log entries to be safely discarded rather than growing the log indefinitely. What does this represent?
Checkpointing periodically syncs the data files to match the write-ahead log, allowing an older log entry to be safely discarded once its change is confirmed to be reflected in the data files. Keeping every log entry forever with no checkpointing would grow the log without bound and slow down crash recovery, since a longer log takes longer to replay. This checkpointing is what keeps a write-ahead log's size and recovery time manageable over the database's lifetime.
4 / 5
An incident report shows recovery after a crash took an unusually long time because checkpointing had been disabled for weeks, leaving an enormous, unbounded write-ahead log that had to be fully replayed. What practice would prevent this?
Running checkpointing on a regular schedule keeps the write-ahead log bounded, since an older entry can be safely discarded once its change is reflected in the data files, which in turn keeps a future crash recovery fast. Disabling checkpointing lets the log grow indefinitely, extending recovery time enormously, exactly as this incident describes. This regular checkpointing is essential to keeping a database's crash-recovery time predictable and fast.
5 / 5
During a PR review, a teammate asks why the database writes to a durable log before applying a change to its actual data files instead of just applying the change directly and skipping the extra log-write step. What is the reasoning?
Applying a change directly to the data files with no durable log risks losing that change entirely if a crash happens mid-write, before the change was ever safely recorded anywhere. Writing to the log first guarantees the change can be recovered and correctly applied even after an unexpected crash. The tradeoff is the extra write the database performs for every single change, which a well-designed WAL implementation keeps fast through sequential, append-only writes.
What does the "Write-Ahead Log Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to write-ahead log 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.