Section 3 Solutions

These are the answers to the Section 3 Review's Knowledge Check. If you haven't attempted the five scenarios yet, do that first.

Scenario 1: "JMeter Is The Tool"

Correct answer: Performance Testing Tools's tool-neutrality principle — JMeter is a primary worked example, not the canonical or only correct tool; evaluating k6 on its actual merits is reasonable.

Explanation: The module explicitly states JMeter's role in this path — free and widely adopted, chosen as the worked example for those reasons, not because it's uniquely correct. The four underlying concepts (virtual users, scripts, timing, metrics) apply identically in k6.

Alternative approaches considered: Dismissing k6 without evaluation contradicts the module's own stated reasoning — a real choice between tools should weigh actual project needs (CI/CD fit, team skill, maintainability), not default loyalty to whichever tool was learned first.

Real-world reasoning: Directly tests whether the tool-neutrality principle was understood as a real, applicable stance, not just a disclaimer in the module's own text.

Scenario 2: Single-Level "Stress Test"

Correct answer: Executing Load, Stress, Spike, Soak, and Volume Tests's stress-test configuration principle — this isn't actually a completed stress test; it needs incremental load increases continuing until a breaking point is found.

Explanation: This is the module's own hospitality-platform example restated — a fixed-level test that "passed" tells you nothing about the actual ceiling, since a stress test's value specifically comes from finding where failure begins.

Alternative approaches considered: Accepting this as a complete stress test risks the same real consequence the module's own example described — a real breaking point that exists above the tested level, never actually found.

Real-world reasoning: A near-restatement of the module's own worked example, confirming the "stress test in name only" gap was understood as a real, checkable configuration failure.

Scenario 3: Degradation Correlating With Memory, Not CPU

Correct answer: Bottleneck Analysis and Monitoring's correlation technique — memory is the actual bottleneck here, confirmed by the timing correlation, not CPU (which stays comfortable).

Explanation: This directly applies the module's central technique — the resource whose curve bends at the same moment as the response-time degradation is the actual bottleneck, regardless of which resource might seem like the more obvious guess.

Alternative approaches considered: Assuming CPU is the bottleneck without checking the actual correlated data would miss the real cause entirely — exactly the risk the module's own CPU-only-monitoring anti-pattern describes.

Real-world reasoning: Tests whether the correlation technique (not just "check CPU") was understood as the general, resource-agnostic method to apply.

Scenario 4: Measuring Reaction Speed to a Sudden Surge

Correct answer: Executing Load, Stress, Spike, Soak, and Volume Tests's spike-test configuration — near-immediate ramp-up, not gradual.

Explanation: This is the module's own central spike-testing point — a gradual ramp to the same eventual peak tests something closer to a load test; only a near-immediate ramp actually measures reaction speed to a sudden change.

Alternative approaches considered: A load test at the target peak wouldn't answer this specific question — per the module's own explicit warning against confusing "a faster load test" with a genuine spike test.

Real-world reasoning: A direct, unambiguous test of the module's most emphasized distinction (spike vs. load configuration).

Scenario 5: "The System Was Slow Under Load"

Correct answer: Bottleneck Analysis and Monitoring's central lesson — this report is incomplete; it needs correlated resource data identifying the specific cause.

Explanation: This is the module's own opening scenario's exact failure mode — a symptom reported without a correlated cause forces whoever receives it to independently investigate from scratch, exactly the two-day cost the module's AtlasBank example described.

Alternative approaches considered: Accepting this report as complete and moving to a fix attempt risks addressing the wrong resource entirely, without ever confirming which one actually caused the degradation.

Real-world reasoning: Tests whether "a symptom alone isn't a finding" was understood as the module's actual takeaway, not just background context for its own specific example.

Section 3 Complete

Across three modules, this section covered concept-first tool literacy, deliberate per-type test configuration, and correlating monitoring data to find an actual bottleneck. From here, continue to Section 4 — Analysis and Operations, starting with Result Analysis and Reporting, where this section's findings become a communicated, actionable result for both technical and non-technical audiences.