.. _tutorials-onboarding-m5-quiz:


Final Quiz
==========

This final self-check combines practical cluster workflows, job submission
parameters, and terminal diagnostics to help verify your readiness for
production work on CoSTAR.


Note that these questions are not formally graded and can be retaken as many times as needed.

.. raw:: html

   <br><br>

.. quizdown::

   ---
   primary_color: "var(--color-brand-primary)"
   secondary_color: "var(--color-background-secondary)"
   text_color: "var(--color-foreground-primary)"
   shuffle_questions: false
   shuffle_answers: true
   ---

   ### What is the maximum allowable walltime limit for jobs executing on the cluster?

   1. [ ] 6 hours across all available systems.
   1. [ ] There are no time limits
   1. [ ] 2 hours max for test runs, with no limits on production workflows.
   1. [x] 4 days total execution time across the entire cluster layout.
       > Correct. You can view live limits anytime by running ``sinfo``.

   ### What software tools and execution workflows are demonstrated in the "Example 3" cluster template script?

   1. [ ] Launching a live interactive terminal session across a multi-GPU topology.
   1. [ ] Training an AI model on the MNIST dataset using TensorFlow inside a standard conda virtual environment.
   1. [ ] Spawning a short debugging run that samples raw GPU capability metrics without execution loops.
   1. [x] Executing a non-interactive batch job that utilizes an Apptainer container image to train a PyTorch deep learning model.
       > Correct! Example 3 outlines the modern production standard for containerized PyTorch execution on CoSTAR's H200 infrastructure.

   ### What core system mechanism is featured as the focus of the "Example 4" cluster template workflow?

   1. [ ] Spawning an interactive shell mapping direct GPU compute tasks with ``srun --pty``.
   1. [x] Implementing automated checkpoint and restart loops for a containerized TensorFlow model training on CIFAR-10.
       > Correct. Example 4 showcases how to safely handle periodic session dumps so your work can seamlessly resume if interrupted.
   1. [ ] Intercepting Linux system exit signals (``SIGTERM``) to benchmark custom low-level trap scripts.
   1. [ ] Launching multi-node, multi-GPU parallel processing arrays using explicit ``torchrun`` topologies.

   ### If you log into CoSTAR via SSH and execute the command exactly as written below, what will the terminal display?

   ```bash
   echo $H0STNAME
   ```

   1. [ ] ``login1``
   1. [x] An empty line (blank output)
       > Correct. This is a trick question. The command contains a typo—using a zero (0) instead of an uppercase letter O Because the environment variable ``$H0STNAME`` does not exist, the shell evaluates it to an empty string. The actual system variable is ``$HOSTNAME``.
   1. [ ] ``costar``
   1. [ ] ``costar-login01.surrey.ac.uk``


   ### How can you determine the exact compute node your current interactive Slurm session is running on?

   Select all that apply:

   - [x] Execute the standard `hostname` command directly in your current prompt.
       > Correct. This returns the precise node identifier (e.g., `costar04`) hosting your current active shell session.
   - [x] Query the scheduler queue state by running `squeue --me` or tracking your specific job ID.
       > Correct. The allocation layout columns in the `squeue` output map your active job ID directly to its running node destination.
   - [ ] Run the diagnostic tool block `scontrol show node`.
       > Incorrect. This dumps global hardware configuration state data for the entire cluster array rather than pinpointing your isolated terminal container.
   - [ ] Execute the cluster health script `showcluster`.
       > Incorrect. This shows a high-level architectural configuration summary rather than tracking your user runtime state.