Candidate Portal
Sign in, launch your workstation, and start troubleshooting.
Enter your name and session code, then open the assigned Windows toolbox VM in the browser.
The lab backend stays hidden. Work only from the tools available on the workstation and explain your reasoning.
Session model
Candidate-facing pathLogin Flow
Simple enough for candidates, controlled enough for interviews.
The portal should be a thin front end over an admin-controlled session broker. Candidates do not pick scenarios, browse device inventories, or see the hidden network map.
Session behavior
Candidate authenticates Portal validates timed session Candidate receives assigned Windows VM Portal shows only approved instructions Session expires automatically
Portal rules
- No candidate-side topology map.
- No raw GNS3 project access.
- No device inventory beyond what the workstation naturally reveals.
- All sessions are tied to a start and end window.
Broker status: checking configuration.
Connectivity test
If your session loads but the seat stays on “connecting”, your network or VPN may be blocking WebSockets. Run this test before launching.
Windows Toolbox VM
The candidate gets a believable workstation, not an admin backdoor.
Design Rules
The front end should feel polished while keeping the exercise honest.
Candidate sees
Portal, instructions, and the Windows seat
- Session status and remaining time.
- Allowed objectives and any provided symptoms.
- The Windows VM launch or reconnect action.
Backend hides
GNS3 project internals and administrative controls
- Switching and routing topology details.
- Device credentials beyond the ones intentionally issued.
- Scenario reset, answer keys, and interviewer notes.
Operations
Session broker and timed cleanup
- Assign one workstation per candidate.
- Expire access automatically at the end of the interview.
- Reset the hidden GNS3 scenario and Windows seat between sessions.