Why does my trace table always go wrong on the last iteration?

Because you are almost certainly checking the condition at the wrong moment, and the last row is the only place that difference shows up.

The thing that is actually going wrong

Take a loop like this:

count <- 1
total <- 0
WHILE count <= 5 DO
    total <- total + count
    count <- count + 1
ENDWHILE
OUTPUT total

Most students trace this by writing a row for each pass and updating both variables, which is right. The error creeps in at the end. After the fifth pass, count becomes 6. A lot of trace tables stop there, because five passes felt like the whole job.

But the loop has not finished. It goes back to the top, checks 6 <= 5, finds it false, and then exits. That final check is a step, and if the question asks for the value of count when the loop terminates, the answer is 6, not 5.

The completed table:

Output is 15. count finishes at 6.

Why this specific mistake is so common

Two reasons, and they compound.

The first is that in your head, the loop "runs five times", so five rows feels complete. The sixth row does not correspond to any work being done, so it feels like it should not exist. But the trace table is not a record of work done. It is a record of the machine's state at each step, and checking a condition and failing it is a step.

The second is that when you write code in an editor you never see this. The loop exits, the program carries on, and the final value of the counter is invisible unless you print it. Tracing on paper is the only place it becomes a question, which is exactly why the exam asks it there.

How to stop doing it

Write the condition as a column. Not a mental check, an actual column in the table, filled in for every row including the last. The moment "condition" is something you have to write down, you cannot skip the row where it turns false.

Then, before you hand the table over, ask one question: does my last row show the loop being told to stop? If it does not, the table is incomplete.

The variation that catches people out

Swap WHILE for REPEAT ... UNTIL and the same students make the opposite error. A REPEAT loop checks its condition at the end of the pass, which means the body always runs at least once, even when the condition is already true going in. Students who have drilled WHILE tracing sometimes add a phantom condition-check row at the top, which is just as wrong in the other direction.

The fix is the same: write the condition column, and put the check where the construct actually puts it.

What this is worth in the exam

Trace table questions are typically three to six marks and they are, with practice, close to free. There is no cleverness in them. They reward exactly one thing, which is doing the bookkeeping carefully when you already believe you know the answer.

That last clause is the whole difficulty. Strong programmers are worse at trace tables than average students surprisingly often, because they read the algorithm, understand what it does, and write down what they believe the output should be rather than working through each iteration. The examiner writes these questions with an off-by-one at the boundary precisely to catch that.