Testing: flaky test, test quarantine, flakiness rate, test sharding
0 / 10 completed
1 / 10
A DevSecOps engineer explains pipeline security stages: "We run three scanners on every pull request. The first analyses source code without executing it — catching SQL injection patterns, hardcoded secrets, and insecure crypto. The second hits the running app with real HTTP requests to find runtime vulnerabilities. The third checks our package.json against CVE databases for vulnerable dependencies." Which scanner is described by "analyses source code without executing it"?
SAST (Static Application Security Testing): analyses source code, bytecode, or binaries without executing the application. Runs early in the pipeline (on push/PR). Catches: SQL injection patterns, XSS vulnerabilities, hardcoded credentials, insecure crypto usage. Tools: Semgrep, SonarQube, Checkmarx, Bandit (Python). DAST (Dynamic Application Security Testing): tests the running application by sending real HTTP requests and observing responses. Finds runtime issues SAST cannot detect: authentication bypasses, server-side request forgery. Tools: OWASP ZAP, Burp Suite. SCA (Software Composition Analysis): scans third-party dependencies (npm, Maven, pip) against CVE databases. Tools: Snyk, OWASP Dependency-Check, Trivy. Quality gate: a pipeline stage that fails the build if security or quality metrics breach a defined threshold — e.g., "zero critical CVEs" or "coverage > 80%". In conversation: "SAST caught the SQL injection pattern statically; DAST later confirmed it was exploitable against the running app — both tools together give full coverage."
2 / 10
Complete the platform engineer's explanation using the correct term:
"We store all Docker images in our private ___. We enforce immutable tags — once myapp:v1.2.3 is pushed it cannot be overwritten. We pin Kubernetes manifests to the image digest (SHA-256 hash of the image content), so even if a tag is moved our pods keep running the exact image we tested."
Which term fills the blank?
Artifact registry: a versioned, access-controlled repository for build outputs — container images (Docker/OCI), language packages (npm, Maven), binaries, and Helm charts. Examples: Docker Hub, AWS ECR, Google Artifact Registry, GitHub Container Registry, JFrog Artifactory, Harbor (open-source). Immutable tag: a registry policy preventing an existing tag from being overwritten. Prevents silent supply chain attacks where a compromised pipeline replaces a known-good image with the same tag name. Image digest: the SHA-256 hash of an image manifest. Pinning to a digest (e.g. myapp@sha256:abc123...) guarantees the exact image content regardless of tag changes — even if a tag is later moved to a different image, digest-pinned deployments are unaffected. Deployment gate: a pipeline checkpoint requiring a manual approval or automated quality check before promoting a build to the next environment (e.g. staging → production). Different from a quality gate — a deployment gate is environment-level, a quality gate is metric-level. In conversation: "After a supply chain incident we enforced digest pinning everywhere — tags are human-friendly aliases, but only the digest guarantees immutability."
3 / 10
Match the correct definition to the term rollback trigger:
An engineering manager describes the release process: "We promote our canary to 100% automatically unless a rollback trigger fires. We define thresholds: if error rate exceeds 1%, or p99 latency rises above 500 ms, the system automatically reverts to the previous version without human intervention."
Rollback trigger: an automated condition — typically a metric threshold — that initiates reversion to the previous deployment when breached. Part of progressive delivery pipelines. Common triggers: error rate spike, latency p99 increase, success rate drop, custom business metric anomaly. Tools: Argo Rollouts analysis templates, Flagger metric checks, Spinnaker automated judgements. Related vocabulary: Percentage rollout — gradually shifting traffic from 0% to 100% for a new version, with rollback triggers guarding each step. Kill switch — a feature flag specifically designed for emergency disablement; distinct from a rollback trigger because it operates at the feature level (not the deployment level) and takes effect without a new deployment. Feature toggle / flag debt: stale flags never cleaned up after a rollout completes; become a maintenance burden and source of hidden complexity. Every flag should have a planned removal date. In conversation: "The rollback trigger fired at 2% traffic when error rate hit 0.8% — the system rolled back automatically before any customer noticed."
4 / 10
A tech lead explains the branching strategy: "We practise trunk-based development. Everyone integrates to main at least once a day. Feature branches live no longer than two days. Long-running work is hidden behind feature toggles so the trunk is always releasable. We also use a merge queue — it serialises merges and runs CI on each in order, so a passing branch that conflicts with a concurrent merge can never silently break main." What problem does a merge queue solve?
Merge queue: a mechanism that serialises merges to the main branch. When a PR is added to the queue: (1) it is rebased on the current main plus any queued PRs ahead of it, (2) CI runs on this combined state, (3) only if CI passes does the merge complete. This prevents the "works on my branch" problem where two passing branches conflict when merged concurrently. Supported natively by GitHub (merge queue feature), GitLab (merge trains), and Aviator/Mergify. CODEOWNERS: a file (`.github/CODEOWNERS` on GitHub) mapping repository paths to teams or individuals who must approve changes. Example: `src/billing/` owned by `@payments-team`. Enforces ownership without manual tracking. Trunk-based development (TBD): a branching model requiring all developers to integrate to a single shared trunk (main/master) at least daily, using feature flags to hide incomplete work. Enables continuous integration and DORA Elite performance. In conversation: "Before the merge queue, two teams could both see green CI and merge simultaneously — and break main. The queue catches that."
5 / 10
A senior engineer discusses release management hygiene: "We have a flag debt problem. Eighteen months ago we launched a percentage rollout for the new checkout flow. It reached 100% and was never cleaned up. Now we have 47 dead feature flags cluttering the codebase. The code paths for the old checkout still exist, still tested, still confusing new developers. Meanwhile, our flaky test count is at 89 — engineers routinely re-run CI without investigating failures, which means real bugs are getting ignored." What is flag debt and what is the risk it creates?
Flag debt: the accumulation of feature flags (toggles) that have outlived their purpose — fully rolled out but never removed. Causes: dead code branches that still require maintenance, confusing conditional logic that new developers must understand, test matrix explosion (which code paths are active?), latent bugs in the "off" path that nobody tests. Best practice: every flag has a removal ticket created at creation time with a target date. Flaky test: a non-deterministic test that sometimes passes and sometimes fails without any code change. Causes: shared mutable state between tests, timing dependencies (sleep() instead of polling), unmocked external calls, random data without fixed seeds. Harm: trust erosion — engineers learn to re-run CI without investigating, which means real failures get treated as flakiness and ignored. Mitigation: quarantine flaky tests (still run, do not block merges), track flakiness rate as a quality metric, treat each flaky test as a P2 bug. In conversation: "We treat flag debt the same as technical debt — it appears in our quarterly tech health report alongside flaky test count."
6 / 10
Sarah, a junior developer, sends this Slack message to the team: 'Just deployed the new API endpoint. It's running smoothly for now, but I'm monitoring it closely.' Which term best describes Sarah's proactive approach to post-deployment observation?
Canary Releases involve deploying a new version of an application to a small subset of users before rolling it out to everyone. Sarah's action—monitoring the API closely after deployment—is characteristic of this strategy, allowing for early detection of issues in a controlled environment. The other options represent distinct deployment strategies with different goals and implementation methods.
7 / 10
Mark, the DevOps Lead, is explaining the concept of 'Infrastructure as Code' to a new team member. He says: 'We define our entire infrastructure – servers, networks, databases – using code. This allows us to automate deployments and ensure consistency across environments.' Which tool would be most appropriate for Mark to manage this code?
Terraform is a popular Infrastructure as Code (IaC) tool that enables you to define and manage your infrastructure using code. It allows for automation, version control, and consistent deployments across different environments, aligning with Mark's explanation. Jenkins is a CI/CD pipeline tool; SonarQube analyzes code quality; Docker Compose manages multi-container applications.
8 / 10
During a standup meeting, David, a developer, states: 'We're using a Git flow branching model. Every feature branch is merged back into the main branch after testing and code review.' What does David primarily refer to when discussing 'code review'?
Peer Code Examination is the core of a code review process. It involves other developers scrutinizing your code for errors, potential bugs, and adherence to coding standards. While version control systems are used, and CI/CD pipelines often incorporate automated testing, David's statement focuses on the human aspect of reviewing code before merging.
9 / 10
Elena, a Release Manager, is describing an incident response plan. She says: 'If a critical bug is detected in production after deployment, we can quickly revert to the previous stable version using our automated rollback mechanism.' What is the primary benefit of this 'automated rollback mechanism'?
Rapid Recovery from Failures is the key function of an automated rollback mechanism. It allows for a swift return to a known-good state in case of issues, minimizing downtime and impact on users. While increased deployment frequency and reduced lead time are benefits of CI/CD, they aren't directly addressed by a rollback process.
10 / 10
John, the Tech Lead, is explaining a complex PR description: 'We're using feature toggles to manage this new user authentication flow. This allows us to deploy code to production without exposing it to all users initially – we can enable it for a small percentage of our user base first.' What is the primary purpose of utilizing feature toggles in this scenario?
Enabling Controlled Feature Rollouts is the core purpose of using feature toggles. They allow developers to deploy code to production without immediately exposing it to all users, facilitating a phased rollout and reducing risk. Build times, branching strategies, and automated testing are separate concerns addressed by different practices.
What does the "CI/CD Advanced Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to ci/cd advanced vocabulary through 10 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 10 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.