Sample questions
Data Pipeline ReliabilityDifficulty 1
What is the key difference between a fail-fast and a dead-letter-queue (DLQ) error-handling strategy in a data pipeline?
- aFail-fast retries the failing record indefinitely, while a dead-letter-queue drops it immediately without keeping any record.
- bFail-fast stops the whole run at the first error; a DLQ sets failing records aside instead.✓
- cFail-fast and dead-letter-queue are simply two names teams use for the exact same technique.
- dFail-fast only applies to streaming pipelines, while a dead-letter-queue only applies to batch pipelines.
Explanation:Fail-fast halts the entire run at the first error so a bad state cannot propagate further, trading availability for safety. A dead-letter-queue instead isolates only the problematic records for later inspection, letting the rest of the batch keep moving. (a) misdescribes both strategies. (c) is wrong — they represent different trade-offs. (d) is a false restriction; both patterns can be applied to either processing style.
Data Pipeline ReliabilityDifficulty 2
A retry policy allows a maximum of 3 total attempts (1 original + 2 retries) with a fixed 5-second delay between attempts. The original attempt fails at t=0. If every retry also fails instantly, at what time does the pipeline give up and mark the operation as permanently failed?
- aAt t=10 seconds, once the third total attempt fails and the limit is reached.✓
- bAt t=15 seconds, after a fourth attempt is made beyond the configured limit.
- cAt t=5 seconds, after only the first retry, ignoring the configured maximum.
- dImmediately at t=0, since the original attempt already counts as a permanent failure.
Explanation:Attempt 1 fails at t=0; after a 5s delay, attempt 2 (retry 1) fails at t=5; after another 5s delay, attempt 3 (retry 2) fails at t=10. That is 3 total attempts, so the policy's limit is reached and the operation is marked permanently failed at t=10s. (b) exceeds the configured attempt limit. (c) stops before the limit is reached. (d) ignores that retries are configured at all.
Data Pipeline ReliabilityDifficulty 2
In an exponential backoff retry strategy, how does the wait time between successive retry attempts typically behave?
- aIt stays exactly constant regardless of how many attempts have already failed.
- bIt decreases with each attempt, so failing operations get retried faster and faster over time.
- cIt grows roughly exponentially with each failure, often combined with random jitter.✓
- dIt resets to zero after every attempt and is only meaningful for the very first retry.
Explanation:Exponential backoff multiplies the delay after each consecutive failure (e.g., 1s, 2s, 4s, 8s...), and jitter is commonly added so many clients don't retry at the exact same instant. (a) describes a fixed-delay strategy, not exponential backoff. (b) is the opposite of the intended behavior. (d) misunderstands the pattern entirely.
Data Pipeline ReliabilityDifficulty 1
What does a pipeline SLA (service level agreement) typically define in a data pipeline context?
- aThe exact internal algorithm used to transform the data before it is loaded into its destination.
- bAn agreed expectation for when data must be available, plus acceptable quality or completeness.✓
- cThe maximum number of engineers who are allowed to work on the pipeline's codebase.
- dA guarantee that the pipeline's code will never contain a bug.
Explanation:A pipeline SLA is a commitment about outcomes consumers can rely on — typically timeliness (by when data is ready) and sometimes quality thresholds — not an implementation detail. (a), (c), and (d) describe things unrelated to what an SLA actually commits to.
Data Pipeline ReliabilityDifficulty 2
A dataset is expected to update every hour. It last updated successfully at 14:00. The current time is 16:45. What is the current data freshness lag?
- a1 hour 45 minutes
- b2 hours 45 minutes✓
- c45 minutes
- d3 hours 45 minutes
Explanation:Freshness lag is the elapsed time since the last successful update: 16:45 minus 14:00 = 2 hours 45 minutes. Since the expected cadence is hourly, this also means the data is well overdue. (a), (c), and (d) are simple arithmetic errors.
Data Pipeline ReliabilityDifficulty 2
A downstream report shows unusually low numbers for a metric, but the pipeline completed with no errors and no failed job runs. What best describes this situation?
- aThis cannot happen; a pipeline that completes without errors always produces correct output.
- bThis is a normal SLA breach, since SLA violations always show up as job failures.
- cThis indicates only a retry-policy misconfiguration; more retries would have caught the problem.
- dThis may be silent data corruption: the data is wrong or incomplete despite reported success.✓
Explanation:A job can exit successfully while still producing wrong or incomplete output — for example due to an upstream schema change or a subtle logic bug that doesn't raise an exception. This is the defining trait of silent data corruption: no error signal, but bad data. (a) is false — success status does not guarantee correctness. (b) confuses SLA timeliness with data correctness. (c) misattributes the cause; retries address transient failures, not silent logic/schema issues.