Your choices and justifications are saved automatically.
Eight scenarios. Select the construct that best fits, justify your choice using the scenario, then check the model answer. Scenarios 5 and 8 are marked DISCUSS — either answer can be correct if well-justified.
A cinema box office program asks for a customer's age. If the age is 60 or over, it displays a message offering a senior discount; otherwise it displays the standard ticket price. The age is only ever entered once per customer.
age >= 60), and exactly one of two outcomes runs — the discount message or the standard price. Nothing in the scenario repeats: there is no re-asking, no counting, and no "until" condition, which are the signals a loop is needed instead.
A pupil is writing a program that prints the 12 times table from 12 × 1 up to 12 × 12, one line at a time. The number of lines to print — exactly 12 — is known before the program runs and never changes.
FOR loop (range(1, 13) in Python). The scenario states the number of repetitions (12) is known in advance and never changes, which is the exact test for choosing a fixed loop over a conditional one: the loop counter runs from 1 to 12 and the same line is printed on each iteration.
A door entry system asks a user to enter a 4-digit PIN. If the PIN is wrong, the system displays "Incorrect PIN, try again" and asks for it once more. This keeps happening for as many attempts as it takes until the correct PIN is entered — there is no set limit on the number of attempts.
WHILE loop (or REPEAT…UNTIL) testing pin != correctPin. The scenario explicitly says the number of attempts is not fixed and depends on when the correct PIN is entered — that is the defining feature of a conditional loop, not a fixed one, because the number of iterations cannot be known before the program runs.
A marking program takes one pupil's percentage score and decides which grade band it falls into: A (70+), B (60–69), C (50–59), or Fail (below 50). It checks the score once and prints exactly one grade.
A website asks a customer to enter their postcode before checkout. The spec says: "If the postcode is not in a valid format, display an error message telling the customer to correct it." The spec does not say what happens after the error message is shown.
If choosing Loop: In real input-validation practice (SDD10), an error message on its own is not useful unless the customer gets another chance to fix it — the standard pattern re-requests the postcode inside a WHILE loop until it is valid, so a sensible design would use a loop even though the spec doesn't spell out the retry.
Exam note: This is exactly the trap examiners set: the spec's wording is genuinely incomplete. A weak answer picks one option without noticing the gap. A strong answer states the spec only describes selection as written, but explains why a conditional loop with re-prompting is the better real-world design, or asks what the intended behaviour after the error message should be.
A feedback program collects exactly 5 star ratings (1–5) from a customer survey, adds them into a running total, and then divides by 5 to display the average rating. The survey always asks for 5 ratings, never more or fewer.
total = 0 initialised before the loop, then a FOR loop (range(5)) that adds each rating to total inside the loop body. "Always asks for 5, never more or fewer" is the scenario's clue that the iteration count is known in advance, which is exactly when a fixed loop — not a conditional one — is the right choice.
A theme park ride requires riders to be at least 10 years old AND at least 130 cm tall. A member of staff enters one rider's age and height once, and the system immediately displays whether that rider may ride or must be turned away.
age >= 10 AND height >= 130. Both parts must be True for AND to give True. The scenario says the age and height are entered "once" and the result is displayed "immediately" — there is no repetition, so this is selection with a complex condition, not a loop, even though two comparisons are combined.
A quiz program asks a pupil exactly 5 multiple-choice questions, one after another. After each answer, it immediately compares the pupil's answer to the correct answer and displays "Correct!" or "Wrong." before moving to the next question. A teacher asks which construct is "the important one" in this design.
FOR loop (range(5)) controls how many times the whole question-and-check process runs. Without the loop, the program would need five separate, near-identical blocks of code instead of one repeated block.If choosing Selection: The actual marking decision — comparing the pupil's answer to the correct one and choosing between "Correct!" and "Wrong." — is an IF/ELSE, and it is this decision that determines the output the pupil sees for each question.
Exam note: This design genuinely nests one construct inside the other: a fixed loop that repeats a selection five times. A weak answer picks a side and ignores the other construct entirely. A strong answer names both — the loop for repetition, the selection for the decision inside it — and explains that "the important one" depends on which part of the behaviour the question is actually asking about.
The most common generic error is answering with the label alone — "this needs a loop" or "this is selection" — without naming the specific construct (a fixed FOR loop versus a conditional WHILE, a simple IF/ELSE versus a complex condition with AND/OR) and without pointing to the exact word or phrase in the scenario that justifies it. "It repeats" is not evidence; "it says exactly 5, so the count is known before the loop starts" is.
The second common confusion is between a complex condition and a loop. Combining two comparisons with AND or OR (as in Scenario 7) still describes one decision, checked once — it is not a loop just because two things are being tested. Conversely, candidates sometimes miss that a scenario needs a loop because they focus on the single condition being tested inside it (as in Scenario 3) rather than on the fact that the whole check-and-message process repeats an unknown number of times. Always ask: does this decision happen once, or does something keep happening until a condition changes?
For the two Discuss scenarios: state clearly which construct the scenario's exact wording supports, and where the wording is incomplete or the design genuinely nests one construct inside another, say so explicitly rather than forcing a single clean answer.