The correct answer is that the command was not committed. In SQL databases, a DELETE statement removes rows from a table only when the transaction is finalized with a COMMIT command; without it, the deletion remains in a pending state, and the database’s read consistency or transaction isolation ensures the row is still visible to subsequent SELECT queries. The reported “success” simply means the statement executed without syntax or runtime errors, but the changes are not made permanent until committed. On the CompTIA ITF+ FC0-U61 exam, this question tests your understanding of transaction control and the difference between executing a statement and making it permanent—a common trap is assuming “success” equals “saved.” Remember the memory tip: “DELETE without COMMIT is just a promise, not a permanent removal.”
FC0-U61 Database Fundamentals Practice Question
This FC0-U61 practice question tests your understanding of database fundamentals. Read the scenario carefully and evaluate each option against the stated constraints before committing to an answer. After answering, compare your reasoning against the explanation and wrong-answer breakdown below. Once you have made your selection, read the full explanation to reinforce the concept and understand why each distractor is designed to mislead on exam day.
Exhibit
DELETE FROM Customers WHERE CustomerID = 100;
Refer to the exhibit. A database administrator executes the DELETE statement, and it reports success. However, a subsequent SELECT still shows the row. Which is the most likely explanation?
Clue words in this question
Noticing these words before you look at the options changes how you read each choice.
Clue: "most likely"
Why it matters: Probability qualifier — the question wants the most probable cause or outcome, not a guaranteed one. Eliminate low-probability options.
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The command was not committed.
In SQL databases, a DELETE statement removes rows from a table only when the transaction is committed. If the database is using implicit transactions or the user has not issued a COMMIT command, the deletion is held in a pending transaction and remains visible to other sessions (or even the same session if read consistency is applied). The reported 'success' indicates the statement executed without error, but without a commit, the changes are not made permanent, so a subsequent SELECT still shows the row.
Key principle: Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
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 table is locked by another user.
Why it's wrong here
A lock would prevent the DELETE from executing.
✗
The WHERE clause used the wrong value.
Why it's wrong here
If it reported success, the value likely matched a row.
✓
The command was not committed.
Why this is correct
Without COMMIT, the deletion is not finalized and can be rolled back.
Clue confirmation
The clue word "most likely" in the question point toward this answer.
Related concept
Read the scenario before looking for a memorised answer.
✗
The user lacks DELETE privilege.
Why it's wrong here
If lacking privilege, the command would fail, not succeed.
Common exam traps
Common exam trap: answer the scenario, not the keyword
CompTIA often tests the distinction between statement execution success and transaction permanence, trapping candidates who assume 'success' means the data is immediately visible to all queries.
Trap categories for this question
Command / output trap
If lacking privilege, the command would fail, not succeed.
Detailed technical explanation
How to think about this question
Under the hood, SQL databases implement transaction isolation using undo logs or rollback segments. When a DELETE is executed without a COMMIT, the row is marked as deleted in the transaction's private workspace, but the undo data allows other transactions (or the same session with default read-committed isolation) to still see the original row. In Oracle, for example, a DELETE without COMMIT places row-level locks and the change is only visible to the session that performed the delete until commit; in MySQL with InnoDB, the row is hidden from other transactions but still appears in a SELECT from the same session if autocommit is disabled. Real-world scenarios include batch scripts that forget to issue COMMIT after a DELETE, leading to apparent data persistence.
KKey Concepts to Remember
Read the scenario before looking for a memorised answer.
Find the constraint that changes the correct option.
Eliminate answers that are true in general but not in this case.
TExam Day Tips
→Watch for words such as best, first, most likely and least administrative effort.
→Review why wrong options are wrong, not only why the correct option is correct.
Key takeaway
Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
Real-world example
How this comes up in practice
A small business has 20 workstations on the 192.168.1.0/24 network and one public IP from its ISP. The router uses PAT (NAT overload) so all 20 devices share one public address using different source ports. NAT questions test whether you understand the four address terms and which direction each translation applies.
What to study next
Got this wrong? Here's your next step.
Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.
Database Fundamentals — This question tests Database Fundamentals — Read the scenario before looking for a memorised answer..
What is the correct answer to this question?
The correct answer is: The command was not committed. — In SQL databases, a DELETE statement removes rows from a table only when the transaction is committed. If the database is using implicit transactions or the user has not issued a COMMIT command, the deletion is held in a pending transaction and remains visible to other sessions (or even the same session if read consistency is applied). The reported 'success' indicates the statement executed without error, but without a commit, the changes are not made permanent, so a subsequent SELECT still shows the row.
What should I do if I get this FC0-U61 question wrong?
Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.
Are there clue words in this question I should notice?
Yes — watch for: "most likely". Probability qualifier — the question wants the most probable cause or outcome, not a guaranteed one. Eliminate low-probability options.
What is the key concept behind this question?
Read the scenario before looking for a memorised answer.
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
This FC0-U61 practice question is part of Courseiva's free CompTIA 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 FC0-U61 exam.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.