Practice the vocabulary of tolerating drift between independent clocks in a distributed system.
0 / 5 completed
1 / 5
At standup, a dev mentions the difference between a system clock's reported time and true time, or between two different nodes' clocks, which accumulates as drift across a distributed system. What is this difference called?
Clock skew is the difference between a system clock's reported time and true time, or between two different nodes' clocks, which accumulates as drift across a distributed system even between periodic synchronizations. Assuming a perfectly synchronized clock shared identically by every node ignores the physical reality that independent hardware clocks always drift somewhat. This skew is what makes comparing raw timestamps across two different nodes inherently risky without accounting for it.
2 / 5
During a design review, the team wants every node's clock periodically synchronized against a reference time source to narrow, though not fully eliminate, the skew between them. Which capability supports this?
NTP synchronization periodically aligns every node's clock against a reference time source, narrowing, though not fully eliminating, the skew that naturally accumulates between independent clocks. Leaving every node's clock entirely unsynchronized lets that skew grow much larger and more unpredictable over time. This periodic synchronization is a standard practice for keeping clock skew across a distributed system's nodes within a bounded, manageable range.
3 / 5
In a code review, a dev notices a protocol waits out a bounded uncertainty window before acting on a timestamp comparison, explicitly tolerating a known amount of possible clock skew rather than trusting an exact comparison. What does this represent?
Tolerating clock skew through a bounded uncertainty window has a protocol deliberately wait out a known, bounded amount of time before acting on a timestamp comparison, explicitly accounting for the possibility that two nodes' clocks aren't perfectly aligned. Acting immediately on an exact comparison assumes a precision between nodes that physical clocks can't actually guarantee. This bounded-uncertainty approach is what lets a distributed protocol remain correct even in the presence of a realistic, expected amount of clock skew.
4 / 5
An incident report shows two nodes with unsynchronized clocks disagreed on the ordering of two near-simultaneous events because the system compared raw timestamps directly without accounting for any clock skew between them. What practice would prevent this?
Designing the protocol to tolerate a bounded amount of clock skew, such as by waiting out an uncertainty window before acting on a timestamp comparison, prevents exactly the kind of disagreement this incident describes. Comparing raw timestamps directly with no accounting for skew assumes a precision between two independent nodes that real hardware clocks can't guarantee. This tolerance is a necessary design consideration for any protocol that relies on comparing timestamps from different nodes.
5 / 5
During a PR review, a teammate asks why the team designs a protocol to tolerate clock skew rather than assuming every node's clock is perfectly synchronized. What is the reasoning?
Physical clocks always drift somewhat even with periodic NTP synchronization, since synchronization narrows but never fully eliminates the skew between two independent nodes. A robust distributed protocol has to account for that bounded skew rather than trusting an exact timestamp comparison to always be correct. The tradeoff is the added complexity and occasional extra latency of waiting out an uncertainty window before acting on a timestamp-based decision.
What does the "Clock Skew Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to clock skew 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.