Moodle quiz and question bank implementation

Question categories are the folders that organize questions in a Moodle question bank, and each category sits in a context, such as a course or the whole site. A question kept inside one course is visible only to that course, which suits content tied to a single module. A shared bank works differently because its categories sit at a context that several courses can reach, so teachers in different courses can pull the same questions into their quizzes. Before you build that structure, confirm in the release notes for your chosen version how contexts, sharing and category permissions behave, since these rules shape everything that follows. Moodle also tracks question versions, so confirm how an edit to a shared question affects quizzes that already use it.

The question bank itself is delivered through the Qbank plugin type, which lets question bank features be added as separate plugins. Confirm which Qbank plugins ship in core for your version and which third-party plugins your team would depend on, and record each one with its maintainer and the Moodle versions it supports. The reworked question bank filters change how staff find and select questions, so check the release notes for the version you plan to run and test the filters on a copy of your category tree. Do not write category rules around filter behavior you have only read about. Test it with the people who will search the bank every day.

Set a naming convention before the first import, because renaming categories across a shared bank is slow and error-prone. Use names that describe the subject and level, such as a top-level category per department, followed by subject and topic. Avoid personal names, single-term dates and wording that will age badly. Keep a short written standard covering capitalization, separators and the order of levels. Use question tags for attributes that cut across categories, such as difficulty or learning outcome, so the category tree stays shallow. Illustrative example: a biology department might use the path biology, then cell biology, then formative quizzes, with tags for difficulty.

Every top-level category needs a named owner who is accountable for its questions. The owner decides what enters the category, approves moves and retirements, and answers questions from teachers in other courses. Map that ownership to site roles by confirming which capabilities separate creating and editing questions from only using them in a quiz, then assign those capabilities to the smallest group that does the work. Teachers who write questions for their own course should not automatically gain edit rights across the shared bank. Record owners in the naming standard so the rule survives staff changes.

A shared bank fills with duplicates unless new questions pass a review step. Require authors to search the target category for an existing question on the same point before they create one. Have a designated reviewer check each submission for wording, answer keys, feedback and metadata before it is published to the shared area. Record the reason for each rejected duplicate so the decision stays visible. Run a periodic sweep of each category for near-identical questions and merge or hide the extras. Hide or retire superseded questions and keep them in place, so quizzes and past attempts that reference them still make sense. Confirm the exact steps and tooling your version supports before you write the procedure down.

An exam-style quiz is shaped by a small set of settings that decide how long a student has, how many attempts they get, what order questions appear in, what they see afterward and who can reach the quiz at all. Set these deliberately before the first course is built, because changing them after students have attempted a quiz can affect how results are recorded and reported. Timing comes first: the time limit, the open and close dates, and the behavior when a time limit expires all interact with the question navigation mode and the question behavior. Confirm in your Moodle version exactly what happens to an attempt that is still in progress when the close date passes, since that rule decides whether a student loses work or keeps a submitted attempt.

Attempt rules and navigation determine how the exam feels in use. Decide how many attempts are allowed, whether attempts are graded by highest, average, first or last, and whether questions are shuffled within a page or across the quiz. Choose sequential or free navigation with care: sequential navigation limits students to one question page at a time, which some exam formats need and others find restrictive. Review options are a separate decision. Moodle lets you control what students see immediately after submission, later while the quiz is open, and after it closes, including correct answers, feedback and marks. Write these choices down as a table per quiz, and have the assessment owner sign it off, because the review settings are the most common source of later disputes.

Access controls are where exam security is usually built. Restrictions can limit a quiz by availability dates, group membership, or conditions such as completion of another activity. Browser security options, including full-screen mode, blocking copy and paste, and requiring a quiz password, are available in the quiz settings, but they are not a substitute for invigilation or a dedicated proctoring service. Ask your security and assessment teams to state which controls they need, test each one with a student account on the browsers your students use, and document any control that depends on a third-party tool. Then confirm each setting name and behavior in the Moodle version in use, since option labels and defaults have changed between releases.

Support work around exams is where most of the risk sits. Run at least one pre-exam test with a student account, ideally a full attempt that covers timing, navigation, submission and review, and repeat it after any change to the quiz or the server. Prepare a runbook for technical issues during an attempt. It should name who can extend a timer or reopen an attempt, how a student reports a problem, how the team confirms what the student saw, and how the attempt is preserved or recovered. Agree the escalation path with the platform team and the exam owner in advance, and record every action in the log so that the decision can be reviewed later.

Grade overrides need a written process. Moodle allows teachers to change a grade for a single attempt in the quiz report, and the change is recorded, but the reason and approver are not captured unless your team adds that discipline. Limit who holds the override capability, require a reason for each change, and review overrides after results are released. If you use the gradebook for weighting or outcomes, confirm how an overridden quiz grade flows into course totals in your version, and test that path before the exam period. Include the override log in the evidence you keep for assessment governance.