HSC Software Engineering practice questions for 2026 with worked solutions

Q1

(C) Broken access control. The attacker changes a record identifier they should not be able to access. This is insecure direct object reference, a subcategory of broken access control. Mitigation: enforce object-level authorisation on every endpoint so the server checks the current user actually owns invoice 124.

Q2

(B). A 301 means the resource has permanently moved; the client should follow the URL in the Location response header and update any stored links. Contrast with 302 (temporary), 200 (success with body), 401 (unauthenticated) and 5xx (server error).

Q3

(C). Symmetric encryption uses one shared secret key for both encryption and decryption (fast, used for bulk data). Asymmetric encryption uses a public and private key pair (slower, used for key exchange and digital signatures). Hashing is one-way and is not encryption.

Q4

(B) Supervised learning. The data has labels (approved or rejected), so the model learns the mapping from features to label. Unsupervised learning has no labels; reinforcement learning learns from rewards through interaction.

Q5

(C) git add file.py stages the file. git commit records staged changes, git push uploads commits to a remote, and git clone copies a whole repository.

Q6

Authentication answers "who are you" and verifies identity, for example logging in with a username and a password (ideally with multi-factor authentication). Authorisation answers "what are you allowed to do" and controls access to resources, for example only a user with the admin role can open /admin/users while an ordinary user is denied. Markers reward the identity versus permission distinction plus one concrete example of each. A strong answer notes that authentication happens first and authorisation is checked on every request, server-side.

Q7

Weakness 1: MD5 is fast and cryptographically broken, so an attacker can brute-force or use rainbow tables to recover passwords quickly. Better practice: use a slow, purpose-built password hashing function such as bcrypt or Argon2 with a work factor. Weakness 2: with no salt, identical passwords produce identical hashes, so one cracked hash exposes every user who chose that password, and precomputed rainbow tables apply. Better practice: add a unique random salt per user (modern functions like bcrypt and Argon2 do this automatically). Markers reward two distinct weaknesses each paired with a specific remedy.

Q8

(a) The query lists the name of each student together with how many courses they are enrolled in, but only for students enrolled in two or more courses. (b) A LEFT JOIN keeps every student even if they have no matching enrolments (those would show course_count of 0), whereas an INNER JOIN would silently drop students with no enrolments. The HAVING clause filters the grouped results after aggregation; you must use HAVING rather than WHERE because the filter is on the aggregate COUNT. (c) Students with zero courses:

SELECT s.name
FROM students s
LEFT JOIN enrolments e ON e.student_id = s.id
GROUP BY s.id
HAVING COUNT(e.course) = 0;

(Equivalently, a WHERE NOT EXISTS subquery would work.) Markers reward a correct reading of the original query, the reason for LEFT JOIN, the HAVING versus WHERE point, and a correct rewrite.

Q9. The route concatenates untrusted user input (term) directly into a SQL string, which is a SQL injection vulnerability (OWASP injection). An attacker can submit a value that breaks out of the string and runs arbitrary SQL. Fix with a parameterised query so input is always treated as data:

@app.get("/search")
def search():
    term = request.args.get("q", "")
    rows = db.execute(
        "SELECT * FROM products WHERE name LIKE ?",
        ("%" + term + "%",),
    )
    return jsonify(rows)

The wildcard characters are built into the bound parameter, and the database driver escapes the value. Markers reward naming SQL injection and a correct parameterised rewrite, not just "validate the input".

Q10

Supervised learning trains on labelled data, where each example has features plus the known correct answer (the label); the model learns the function from features to label. Example application: classifying email as spam or not spam, trained on messages a user has already marked. Unsupervised learning trains on unlabelled data (features only) and finds structure on its own. Example application: customer segmentation, where a clustering algorithm groups shoppers with similar buying habits without anyone defining the groups in advance. The key difference is the presence or absence of labels. Markers reward both definitions, the labels versus no labels distinction, and a realistic application for each.

Q11

Overfitting is when a model learns the training data too closely, including its noise, so it performs well on training data but poorly on new, unseen data. Detect it by holding out a validation or test set: a large gap between high training accuracy and low validation accuracy signals overfitting. Reduce it by techniques such as gathering more training data, simplifying the model, regularisation, dropout (for neural networks), or early stopping. Markers reward a correct definition emphasising poor generalisation, a detection method using held-out data, and one valid mitigation.

Q12

Waterfall is a sequential, plan-driven methodology: requirements, then design, then implementation, then testing, then maintenance, with each phase completed before the next begins. Agile (Scrum) is iterative and incremental: work proceeds in short sprints that each produce a working increment, with continuous feedback and changing requirements welcomed. Waterfall suits projects with stable, well-understood requirements and fixed regulatory constraints (for example, safety-critical avionics). Agile suits projects with evolving requirements and a need for frequent user feedback (for example, a consumer web app). Markers reward the sequential versus iterative contrast and a suitable situation for each.

Q13

Output: [20, 50]. The bug is that the loop starts at index 1 (range(1, len(values))), so the first value (10) is never added and the first running total is missing. The intended output of a running total over [10, 20, 30] is [10, 30, 60]. Fix by starting the loop at index 0: for i in range(len(values)), or iterate directly over the values. Markers reward the correct predicted output and identifying that the loop skips the first element.

Q14

A full-mark response evaluates the current state as insecure and structures recommendations around at least three OWASP risks, each with a concrete mitigation tied to the secure development lifecycle.

• Cryptographic failures: the site uses plain HTTP and stores passwords in plain text, exposing data in transit and at rest. Mitigation: enforce HTTPS site-wide (TLS), hash passwords with bcrypt or Argon2 with per-user salts, and encrypt or tokenise stored card data (ideally do not store full card numbers at all; use a compliant payment provider).
• Injection (SQL injection): queries are built by string concatenation. Mitigation: use parameterised queries everywhere and validate input against an allow-list. Add static analysis (SAST) to the build to catch unsafe query construction.
• Broken access control: a likely risk given the poor security posture. Mitigation: enforce server-side authorisation checks on every endpoint, deny by default, and test for insecure direct object references.

Tie these to the secure development lifecycle: threat modelling during design, secure coding standards and code review during development, dependency scanning, and security testing (SAST, DAST and a penetration test) before deployment. A strong conclusion states that security must be built in from the start, not bolted on, and prioritises the highest-impact fixes (HTTPS and password hashing) first. Markers reward three distinct, correctly named OWASP risks, a specific developer-side mitigation for each, and integration with the lifecycle.

Q15. A strong response separates ethical risks from engineering practices and connects them.

Ethical risks: algorithmic bias (a model trained on historical hiring data can learn and amplify past discrimination, as in well-documented cases of resume-screening tools disadvantaging women); lack of transparency and explainability (candidates rejected by a black-box model have no clear reason or avenue for appeal); privacy (applicant data is sensitive personal information); and accountability (who is responsible when the system makes an unfair decision).

Software engineering practices to manage these: during development, audit and balance training data, document data provenance, and consider fairness-aware techniques; choose more interpretable models or add explanation tooling where possible. During testing, evaluate the model for disparate impact across protected groups, not just overall accuracy, and keep a held-out test set. During deployment, keep a human in the loop for final decisions, log decisions for audit, monitor for drift, and provide an appeals process. Manage the project with version control, code review and a clear methodology so changes are traceable. Markers reward identifying concrete ethical risks (especially bias and explainability) and pairing them with realistic engineering and governance practices across the lifecycle.