Which description is most accurate for a Slack incident channel update?
The correct answer accurately reports the failed stage, the number and percentage of failing tests, and the duration. All three are essential for triage.
Key CI/CD vocabulary: • stage — a discrete phase in a pipeline (lint → build → unit-tests → integration-tests → deploy) • failure rate — the percentage of tests that failed: 3 / 847 × 100 = 0.35% • duration — how long the build took to run • triage — the process of identifying and prioritising problems
Why the distractors fail: • "All 847 tests broken" — factually wrong; only 3 failed • "Took too long" — 4m 12s is completely normal for CI; this isn't a timeout failure • "No action needed" — a 0.35% failure rate is NOT automatically acceptable; any pipeline failure blocks deployment and requires investigation
CI summary vocabulary: failed stage, test suite, failure count, failure rate, build duration, blocking PR/deploy, flaky test, red build, green build
What is the most precise way to describe this failure to the team?
Timeout means the stage ran but exceeded the maximum allowed time, causing it to be killed. This is different from a test failure (where the code runs to completion but produces wrong output).
Key vocabulary: • timeout — a stage was terminated because it exceeded its time limit • completed successfully / passed — stage ran without errors • e2e tests (end-to-end) — tests that simulate full user flows through the application • flaky test — a test that sometimes passes and sometimes fails with the same code (often causes timeouts in e2e)
Why option C is wrong: You cannot conclude there's a "bug in the test code" from a timeout alone. Possible causes: test environment was slow, a dependency was down, a network call hung, or the test config's timeout limit is too low.
Root cause analysis phrase: "The e2e-tests stage timed out at 8m 32s — this could indicate a slow test environment, a hung network call, or an insufficiently high timeout threshold. Checking logs to narrow down the cause."
3 / 10
Over the past 30 days, a team's CI pipeline shows:
Total builds: 847 Passed: 724 Failed: 123 Mean build time: 6m 14s
How would you present this at a sprint retrospective?
What makes this answer effective: 1. States the success rate AND failure rate (both perspectives) 2. Translates to plain English ("1 in 7 builds") 3. Includes the mean build time (team efficiency metric) 4. Flags it as a concern WITHOUT over-alarming — uses "worth investigating" 5. Names possible root causes (flaky tests, environment instability)
Key retrospective vocabulary: • failure rate — percentage of failed builds • success rate — percentage of successful builds (100% − failure rate) • mean build time — average duration across all builds • flaky test — intermittent test failure, not caused by code changes • environment instability — the CI infrastructure itself causes failures
Industry context: Elite software teams (DORA metrics) target <15% pipeline failure rate. 14.5% is on the boundary — worth attention but not a crisis.
What are the TWO separate problems this log line reports?
Two separate failure modes:
1. Test failures: 12 tests failed. Exit code 1 means the process exited with an error (exit code 0 = success, anything else = failure).
2. Coverage threshold breach: Code coverage of 67.3% is below the configured 80% minimum. Many CI configs enforce a minimum coverage threshold — failing to meet it automatically fails the build, even if all tests pass.
Key vocabulary: • exit code — the return value of a process: 0 = success, non-zero = failure • code coverage — the percentage of code lines executed by the test suite • coverage threshold — the minimum coverage percentage required to pass the build • skipped tests — tests marked with `.skip()` or similar that are not executed • independently fail the build — either issue alone would cause the build to fail
Common coverage vocabulary: "Coverage dropped from 84% to 67% — we need to add tests for the new authentication module before this can merge."
5 / 10
A tech lead reviews pipeline trends and sees this week-over-week comparison:
What this pattern suggests: When build time AND failure rate increase simultaneously, there's often a single root cause — typically a new test suite, slow integration test, or flaky external dependency added that week.
Key analytical vocabulary: • percentage points — the absolute difference between two percentages (94% → 81% = 13 pp; NOT 13% — that would mean 94 × 0.87) • week-over-week (WoW) — comparison between the current week and the previous week • correlation — two metrics moving together (build time + failure rate) • root cause — the underlying source of multiple observed problems
Precision note: Always say "percentage points" when comparing two percentages. Saying "success rate dropped 13%" is ambiguous — it could mean 94% × 0.87 = 81.8% (multiplicative) or 94% − 13% = 81% (additive). "13 percentage points" is always unambiguous.
6 / 10
Sarah, a junior developer, receives this CI summary via Slack from the integration team: 'Build #7213 – Critical Failure – Stage: deployment-tests. Error: Connection timeout to staging server. Duration: 5m 18s.' Which of the following is the MOST appropriate response for Sarah to send back to the team?
The correct response seeks clarification – Sarah doesn't immediately assume failure or offer solutions without understanding the root cause. A critical failure notification requires investigation before action. Options A and D are reactive and potentially incorrect; option C is too simplistic and assumes a known outcome.
7 / 10
During a daily standup, David, the DevOps engineer, shares this update about the CI pipeline: 'Over the last week, we've seen a consistent increase in build times – averaging 8 minutes and 30 seconds. The pass rate remains at 98%, but the trend is concerning.' What's the MOST impactful way to frame this information for the team?
David's update highlights an important trend (increasing build times) despite a high pass rate. Framing it as 'a problem because it increases our lead time' immediately communicates the potential impact on the team and project. Options A and D downplay the concern; option B focuses solely on one component.
8 / 10
Maria is reviewing a PR description for a new feature that includes automated CI integration. The description reads: 'Build successful – Lint passed. Unit tests: 95% pass rate. Integration tests timed out after 10 minutes.' What does Maria MOST likely need to investigate further?
The PR description indicates a timeout in the integration tests. Linting and code coverage are generally considered successful unless specifically flagged as issues. The most immediate concern is the failure of the integration tests themselves, suggesting a problem with their configuration or execution – thus requiring Maria to investigate the linting rules.
9 / 10
You're analyzing CI pipeline data and notice this: 'Last week: 1500 builds, avg. duration 7m 20s, success rate 96%. This week: 1480 builds, avg. duration 9m 50s, success rate 93%.' Which observation is the MOST valuable for identifying potential problems?
While the number of builds is a metric, the *significant* increase in average build time (from 7m 20s to 9m 50s) and the corresponding drop in success rate (from 96% to 93%) are the most critical observations. These changes indicate a potential problem impacting pipeline performance.
10 / 10
A CI log line reports: 'Step: Java compilation — Exit code: 1 — 5 tests failed, 98 passed — Coverage: 72% (threshold: 80%)'. What is the MOST important action to take based on this information?
The log line indicates test failures and insufficient code coverage (below the threshold). The priority is to investigate the failing tests and address the low coverage – these are fundamental issues that need resolution before deployment. Options A and D ignore critical feedback; option C addresses a symptom rather than the cause.
What will I practise in "Reading CI Pipeline Summaries"?
This module focuses on Numbers, Data & Metrics — real workplace phrasing you'll use on the job. It contains 10 scenario-based multiple-choice questions with instant feedback.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account or sign-up required.
How many questions does this exercise have?
This module includes 10 questions. Each one gives an immediate right/wrong result plus a full explanation of the correct phrasing.
What happens if I answer a question incorrectly?
You'll see the correct answer highlighted straight away, along with a plain-English explanation of why it's right and why the other options don't fit — mistakes are part of the learning here.
Can I retry the exercise if I want a better score?
Yes — use the 'Try again' button on the results screen to reset your score and go through the questions again. There's no limit on attempts.
Who is this Numbers, Data & Metrics exercise for?
It's aimed at IT professionals with working English who want to sound more natural and precise around numbers, data & metrics — useful whether you're preparing for real conversations at work or just building confidence with the vocabulary.
Do I need an account to track my progress?
No account is needed. Your progress through the exercise is tracked locally in your browser for the current session, and you can replay the module at any time.
How is this different from reading a blog article?
This exercise is an interactive drill that tests and reinforces specific phrasing through multiple-choice questions with instant feedback, while blog articles explain concepts and vocabulary in prose. The two work well together.
Where can I find more Numbers, Data & Metrics exercises?
See the Numbers, Data & Metrics hub for more modules like this one, or browse the full Exercises page for other IT-English topics.
Can I complete this exercise on my phone?
Yes — every exercise on CoderSlingo is fully responsive and works on phones and tablets, so you can practise anywhere.