Sample questions
Qa Ci Cd TestingDifficulty 1
In a CI/CD pipeline, what does it mean for automated tests to act as a "gate"?
- aA failing required test blocks the code from moving to the next stage✓
- bTests run only after the software has already been released to users
- cA human reviewer must manually re-run every test before the pipeline can continue
- dTest results are logged for later reading but never affect the pipeline outcome
Explanation:A test gate means the pipeline is configured to stop (block merge, block deploy, block promotion) when required tests fail, so untested or broken code cannot silently progress further.
Qa Ci Cd TestingDifficulty 2
What is the main reasoning behind the "fast feedback loop" principle in a test pipeline: running the cheapest and quickest tests first?
- aCheap tests are more accurate than expensive ones, so results are more trustworthy early on
- bAn obvious failure is reported within minutes instead of after a long suite finishes✓
- cRunning cheap tests first reduces the total number of tests that need to be written
- dExpensive tests always depend on cheap tests passing, so order does not actually matter
Explanation:Ordering tests from cheapest/fastest to most expensive means an obvious break is reported in minutes rather than after a long-running suite finishes, shortening the time a developer waits to learn something is broken.
Qa Ci Cd TestingDifficulty 2
A pipeline currently runs its slow end-to-end UI tests before its fast unit tests. What is the main downside of this ordering?
- aUnit tests become unreliable because they run after the UI tests instead of before them
- bEnd-to-end tests cannot be automated at all unless unit tests already passed
- cA trivial bug is only reported after the much longer UI suite finishes✓
- dThe total number of tests that can be written in the pipeline is limited by the ordering
Explanation:If cheap, fast tests run last, even a trivial mistake is reported only after the expensive suite completes, delaying feedback and wasting the time and compute the slow suite consumed on code that a fast test would have already rejected.
Qa Ci Cd TestingDifficulty 1
What is a commonly recommended staging strategy for ordering test types within a pipeline?
- aRun every test type simultaneously as one combined stage regardless of speed or dependency
- bRun end-to-end tests first so that unit and integration tests only run when the whole system already works
- cRandomize test type order on every run so that no single type consistently blocks the pipeline
- dRun unit tests first, then integration tests, then broader end-to-end tests, smallest scope first✓
Explanation:Staging tests from the narrowest and cheapest (unit) to the broadest and most expensive (end-to-end/UI) mirrors the test pyramid and lets failures surface at the cheapest stage that can catch them.
Qa Ci Cd TestingDifficulty 2
A pipeline configuration defines three sequential stages: unit-tests, integration-tests, e2e-tests, where each stage only starts if the previous stage succeeded. What happens if unit-tests fails?
- a
integration-tests and e2e-tests do not run at all✓ - bAll three stages run in parallel anyway, since the pipeline only reports the final combined result
- cOnly
e2e-tests is skipped, but integration-tests still runs because it does not depend on unit tests - dThe pipeline automatically retries
unit-tests in a loop until it passes, then continues
Explanation:With strictly sequential stages gated on success, a failing unit-tests stage stops the pipeline before later stages start, since each stage's start condition is the previous stage's success.
Qa Ci Cd TestingDifficulty 3
A test suite runs against a shared database. Two pipeline runs execute at the same time and both insert a record with the same fixed ID, causing one run to fail with a duplicate-key error unrelated to any real bug. What is this an example of?
- aA flaky test caused purely by network latency between the test runner and the database
- bA test environment isolation problem: concurrent runs share state and contaminate each other✓
- cA correctly working test gate that is doing exactly what it is supposed to do
- dA test parallelization problem inside a single test process, unrelated to the environment
Explanation:The failure has nothing to do with the code under test; it happens because two runs share the same database/state without isolation. This is a classic test environment isolation and cleanup problem, distinct from flakiness caused by timing inside one run.