CTFL-v4 Testing Throughout the SDLC Practice Question
Exhibit
Log snippet: [WARN] Memory Usage: 90% reached. [DEBUG] Cache clearing triggered. [ERROR] Connection lost due to timeout. [INFO] Restarting service.
Refer to the exhibit. The log shows a recurring sequence in a test environment. What does this suggest about the 'Testing throughout the SDLC' approach applied here?
⚠ Common exam trap
Candidates often believe that using automated restarts in production is a valid testing outcome, missing that it acts as a symptomatic workaround masking an underlying defect.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Testing failed to catch a performance/resource defect, leading to a symptomatic workaround.
The logs indicate that system stability issues are being treated with a 'restart' mechanism, masking the root cause (a memory leak or resource exhaustion). A proper testing approach should have identified this memory trend during component or integration testing. Relying on service restarts in production is a failure of testing to identify and advocate for fixing underlying architectural defects early in the life cycle.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The test team successfully implemented automated recovery procedures.
Why it's wrong here
Service restarts are a recovery procedure, but they do not address the memory leak causing the 90% usage. The existence of an ERROR log followed by a restart indicates that the system is failing, not that the recovery is a success. True success would be preventing the memory exhaustion entirely.
- ✗
The memory leak was identified and resolved during the early development phase.
Why it's wrong here
If the memory leak had been resolved, the system would not be reaching 90% usage and triggering restarts. The logs confirm that the memory issue is still active in the current test environment, which means the testing process failed to identify or verify the fix for this defect early.
- ✓
Testing failed to catch a performance/resource defect, leading to a symptomatic workaround.
Why this is correct
The sequence of events shows a performance bottleneck causing a failure. The restart is a symptomatic workaround, not a solution. The failure to catch this earlier in the SDLC demonstrates that the testing process was not rigorous enough regarding non-functional performance requirements or resource management during integration and testing cycles.
- ✗
The log level configuration is too strict, causing unnecessary restarts.
Why it's wrong here
Log levels indicate the verbosity of information, not the cause of system failure. Restarts are triggered by the logic of the application when the memory reaches 90%. Changing the log level would change what is recorded, but it would not fix the underlying memory exhaustion that is triggering the restart.
About these practice questions
Courseiva writes every CTFL-v4 question from scratch — 144 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official ISTQB exam blueprint
This CTFL-v4 practice question is part of Courseiva's free ISTQB certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CTFL-v4 exam.