# Hands-on labs > PAM SIM is an independent educational simulator. It is not affiliated with, endorsed by, or derived from any commercial privileged access management product, and it is not a substitute for one. It never connects to a real system, never executes a real command, and never stores a real password. Every account, host, identity and credential named in it is invented. It uses the standard vocabulary of the field because that is the vocabulary a real deployment and a real interview use. 8 labs, each verified against real application state rather than self-reported. The debrief at the end of each is the part worth reading even without doing the lab: it says what the exercise was actually teaching. The labs run at https://pamsim.com/labs. ## Lab 1 — Discover a Privileged Account *Locate the riskiest privileged account in the environment and understand why it scores the way it does.* **Difficulty:** beginner **Time:** about 5 minutes **Concepts:** Privileged account, Risk scoring, Account inventory, Safe Privileged access management starts with discovery. Before you can protect privileged accounts you have to know they exist, know what they can reach, and know which of them carry the most risk. In this lab you will use the Accounts inventory and the risk engine to find the single most dangerous account in PAM SIM. ### Steps - **Open the Accounts inventory.** Navigate to Accounts. This is the account inventory — every onboarded privileged account in the Vault appears here. - **Sort or filter by risk.** Use the Risk filter (or click the Risk column) to bring Critical accounts to the top. Risk is computed from privilege level, password age, access frequency, session anomalies and policy violations. - **Open the account.** Click the highest-risk account to open its details page and read the Risk breakdown pane, which explains every point that contributed to the score. ### Graded tasks **Identify the highest-risk account** — graded on the answer submitted Find the account with the highest overall risk score in the inventory. *Question:* Which account has the highest risk score? *Where:* `/accounts?risk=critical` **Inspect its risk breakdown** — graded from real application state Open that account's details page. Viewing an account is itself an audited action — this task is graded from the audit trail. *Where:* `/accounts` ### Hint The Accounts page has a Risk filter in the filter bar. Break Glass and Domain Administrator accounts carry the highest base privilege weight, and an overdue password adds a large amount on top. ### Success criteria You named the highest-risk account and opened its details page. ### Debrief Risk in PAM SIM is additive and explainable: base privilege for the account type, plus password age relative to the platform's change interval, plus access frequency, plus session anomalies, plus policy violations. Real PAM platforms do the same thing — commercial platforms score privileged activity and surfaces the accounts most worth your attention. The lesson is that an inventory alone is not enough; you need a way to rank it. --- ## Lab 2 — Fix an Overdue Password *Find accounts whose password age has exceeded the platform policy and bring one back into compliance.* **Difficulty:** beginner **Time:** about 8 minutes **Concepts:** CPM, Password rotation, Platform policy, Compliance status Every platform in PAM SIM defines a change interval — the maximum number of days a password may live before the CPM must rotate it. When an account passes that interval it becomes non-compliant and its risk score climbs. In this lab you will find the overdue accounts and run a credential change to bring one back into compliance. ### Steps - **Open Credential Management.** The Credential Management page is PAM SIM's CPM. It shows the rotation queue, accounts due and overdue, and the history of every change, verify and reconcile job. - **Count the overdue accounts.** Overdue means password age exceeds the change interval defined on the account's platform. - **Rotate one.** Run Change on an overdue account and watch the simulated CPM sequence: connect, authenticate, change, verify, update Vault. ### Graded tasks **Count the overdue accounts** — graded on the answer submitted How many accounts are currently past their rotation deadline? *Question:* How many accounts are currently overdue? *Where:* `/cpm` **Rotate an overdue credential** — graded from real application state Run a successful Change job against an account that was overdue at the time you started the job. *Where:* `/cpm` ### Hint The Credential Management page has an Overdue tile at the top and an 'Overdue' filter on the queue. After a successful change the account's password age resets to 0 and its compliance status flips to Compliant. ### Success criteria You reported the overdue count and successfully rotated an overdue account. ### Debrief A successful rotation changed real application state: the password age reset, the next rotation date moved, the compliance status flipped, the account's risk score dropped, and an audit event was written. In a production platform the CPM does exactly this on a schedule defined by the platform, and 'non-compliant' accounts are the primary operational metric a PAM administrator works from. --- ## Lab 3 — Approve Privileged Access *Work an access request end to end from the approver's side of the dual-control workflow.* **Difficulty:** beginner **Time:** about 8 minutes **Concepts:** Dual control, Access request, Approval workflow, Time-limited access, PVWA Dual control means a privileged account cannot be used until a second person authorises it. The requester supplies a business justification and a time window; an approver reviews it in the Incoming Requests queue and confirms or rejects. In this lab you take the approver's seat. ### Steps - **Open Incoming Requests.** This is the approver queue. Each row shows the requester, the account, the justification, the requested window and the account's risk. - **Review the Request Overview.** Select a request to open the details pane. Check that the justification is specific, that a ticket is referenced, and that the duration is proportionate. - **Confirm the request.** Confirm with a comment. The requester is notified, the request becomes Approved with a hard expiry time, and an audit event records who authorised it. ### Graded tasks **Confirm a pending access request** — graded from real application state Approve any request sitting in the Incoming Requests queue. You need the requests.approve permission — switch identity from the profile menu to a Security Administrator or an Approver. *Where:* `/requests/incoming` **Understand the access window** — graded on the answer submitted After approval the request carries a hard expiry. Read the approved request and report what happens when that window elapses. *Question:* When the approved access window elapses, what status does the request move to? *Where:* `/requests/incoming` ### Hint Approvals live under Secure Access → Incoming Requests. If the Confirm button is disabled, your current role lacks requests.approve — switch identity from the avatar menu in the header. ### Success criteria You confirmed a pending request and explained what happens at the end of the access window. ### Debrief Approval is not a rubber stamp — it is the control that turns standing privilege into time-limited privilege. The approved request creates a grant that expires on its own, which is the practical mechanism behind just-in-time access and Zero Standing Privileges. Note how many things moved at once: request status, requester notification, audit event, and the account becoming connectable for that user only. --- ## Lab 4 — Investigate a Suspicious Session *Review a recorded privileged session and judge whether the activity inside it was legitimate.* **Difficulty:** intermediate **Time:** about 10 minutes **Concepts:** PSM, Session recording, Session risk score, Forensic review Session recording exists so that privileged activity can be reconstructed after the fact. PAM SIM records every keystroke-level activity as a timeline event and scores each one. A session's risk score reflects its riskiest activity. In this lab you will find the worst session on record and read its timeline. ### Steps - **Open Session Recordings.** Every terminated session that had recording enabled has a playback timeline. - **Sort by risk.** The riskiest sessions are the ones containing high-risk activities — credential dumping tools, mass account enumeration, log clearing, disabling auditing. - **Read the timeline.** Step through the activities in order and decide whether the sequence is consistent with the stated business justification. ### Graded tasks **Find the riskiest recorded session** — graded on the answer submitted Identify the recorded session with the highest risk score. *Question:* What is the session ID of the highest-risk recording? (e.g. PSM-000012) *Where:* `/recordings` **Review its timeline** — graded from real application state Open that recording's playback timeline. Opening a recording is an audited action. *Where:* `/recordings` ### Hint Recordings are sortable by risk. Look for a session whose timeline includes credential-dumping or audit-tampering activity — those raise Critical activity events and drive the session score up. ### Success criteria You identified the highest-risk recording and opened its timeline. ### Debrief Recording turns privileged access from an unobservable action into reviewable evidence. Note the pattern in the timeline you read: authentication, reconnaissance, then an action that has nothing to do with the stated justification. That mismatch between justification and behaviour is the single most useful signal in privileged session review, and it is why PAM SIM forces a business justification on every request. --- ## Lab 5 — Break Glass *Execute the full emergency access workflow and observe the compensating controls that fire around it.* **Difficulty:** advanced **Time:** about 15 minutes **Concepts:** Break glass, Emergency access, Compensating controls, Automatic rotation, Security alerting A break glass account is the credential of last resort — used when normal access paths are unavailable. Because it bypasses ordinary friction, it is wrapped in heavy compensating controls: emergency justification, mandatory recording, a critical security alert, and automatic credential rotation the moment the session ends. In this lab you run the whole sequence. ### Steps - **Raise an emergency request.** From the Access Portal, select a Break Glass account and submit a request with the Emergency flag set. Emergency requests demand a fuller justification. - **Approve it.** Emergency requests still require authorisation — the control is speed, not absence of oversight. - **Connect.** Launch the session. Recording is mandatory and cannot be disabled for break glass. - **Terminate and observe.** End the session. PAM SIM automatically queues a credential change so the break glass password is never reused, and a critical alert is raised for security review. ### Graded tasks **Submit an emergency request for a break glass account** — graded from real application state Use the Access Portal, tick Emergency access, and choose an account in the Break Glass Accounts safe. *Where:* `/portal` **Approve it and open a session** — graded from real application state Confirm the request, then connect to the break glass account. *Where:* `/requests/incoming` **Terminate the session and let the credential rotate** — graded from real application state End the session. A break-glass-triggered rotation job must complete for this task to pass. *Where:* `/sessions` ### Hint The Break Glass Accounts safe holds BreakGlass01 and BreakGlass02. Dual control forbids approving your own request, so switch identity from the profile menu to an approver, approve it there, then use Connect from the account page or from My Requests. ### Success criteria You raised an emergency request, approved it, opened a break glass session, terminated it, and a break-glass rotation completed. ### Debrief Look at the audit trail you just produced: emergency request, approval, credential retrieval, session start, session end, automatic rotation, critical alert. That chain is the entire point of break glass — the account stays usable in a crisis, but every use is expensive to hide. Automatic post-session rotation is what stops a break glass password from quietly becoming a shared standing credential. --- ## Lab 6 — Investigate a Failed Rotation *Diagnose why the CPM could not change a credential, and repair it with a reconcile.* **Difficulty:** intermediate **Time:** about 12 minutes **Concepts:** CPM, Rotation failure, Reconciliation, Verification, Operational PAM Rotation failures are the most common operational issue in a PAM deployment. When the CPM cannot change a password the account drifts out of compliance and stays that way until someone intervenes. In this lab you will find a failed rotation, read its failure reason, and use the reconcile account to force the credential back into a known state. ### Steps - **Find the failures.** Credential Management → the Failed filter. Each failed job records the step it died on and the underlying cause. - **Read the cause.** Typical causes: target unavailable, invalid current credential, password policy violation on the target, permission denied, network failure. - **Reconcile.** A reconcile uses a separate, highly privileged reconciliation account to forcibly reset the password on the target, restoring a known-good state. - **Re-run the change.** After a successful reconcile the ordinary change job should now succeed. ### Graded tasks **Diagnose the failure** — graded on the answer submitted Look at the failed rotation jobs and report what is blocking them. *Question:* What failure reason is recorded on the failed rotation jobs? (a few words is enough) *Where:* `/cpm?tab=failed` **Run a successful reconcile** — graded from real application state Reconcile one of the failing accounts. This clears the fault condition on the target. *Where:* `/cpm?tab=failed` **Confirm recovery with a successful change** — graded from real application state Run Change on the same account and confirm the job now completes successfully. *Where:* `/cpm` ### Hint Open a failed job to see its step list — the step highlighted in red is where it died, and the cause is printed underneath. Reconcile is available from the account's Credentials tab and from the CPM job actions. ### Success criteria You reported the failure cause, reconciled the account, and completed a successful change on it. ### Debrief Reconciliation is the recovery path that makes automated rotation safe to run at scale. Without it, one drifted password means permanent manual intervention. Notice that the reconcile is itself a privileged operation using a separate reconciliation account — that separation is deliberate, because the reconcile account is powerful enough to reset credentials it does not currently know. --- ## Lab 7 — Audit a Privileged User *Reconstruct everything one privileged user has done, using only the audit trail.* **Difficulty:** intermediate **Time:** about 10 minutes **Concepts:** Audit trail, Accountability, RBAC, Investigation Auditing answers the question 'who did what, to which asset, when, and was it authorised?'. In a real investigation you are handed a name and expected to produce a defensible timeline. In this lab you will find the most active user in PAM SIM and reconstruct their activity. ### Steps - **Open Audit.** The audit log records every meaningful action with timestamp, actor, action, resource, source IP, result and risk. - **Group by user.** Use the User filter to isolate one identity. The Users page also has a per-user activity view. - **Build the timeline.** Read the events in order and separate routine operations from privileged operations. ### Graded tasks **Find the most active identity** — graded on the answer submitted Which user account has generated the most audit events? *Question:* Which username has the most audit events? *Where:* `/audit` **Review that user's activity** — graded from real application state Open that user's profile and read their activity timeline. Reviewing a user is itself audited. *Where:* `/users` ### Hint Users → click a user → Activity tab shows every audit event attributed to them, plus their sessions and requests. The audit page also lets you filter by user directly. ### Success criteria You named the busiest identity and opened their activity timeline. ### Debrief Two properties make an audit trail useful: it is complete (every privileged action writes an event, including read-only ones like retrieving a credential) and it is attributable (the event names a human, not a shared service account). PAM delivers the second property specifically by ensuring a person authenticates as themselves before borrowing a privileged identity — the shared admin password is never typed by a human. --- ## Lab 8 — Configure a Safe *Build a new safe, grant least-privilege membership, and place an account inside it.* **Difficulty:** intermediate **Time:** about 12 minutes **Concepts:** Safe, Least privilege, Safe membership, Authorisation model, RBAC A safe is the unit of authorisation in a vault. Permissions are granted on the safe, not on individual accounts, which is what makes access control manageable at scale. In this lab you will design a safe from scratch and populate it. ### Steps - **Create the safe.** Safes → Create safe. Give it a purpose-specific name, an owner and a risk level. Broad safes are an anti-pattern: a safe should map to one team's scope of duty. - **Add members.** Grant each member the lowest permission level that lets them do their job: Use to connect, Manage to administer accounts, Approve to authorise requests, Audit to read history only. - **Move an account in.** Assign an account to the safe and confirm the account's access control now follows the safe's membership. ### Graded tasks **Create a new safe** — graded from real application state Create a safe with a meaningful name and description. Requires the safes.manage permission. *Where:* `/safes` **Add a member to your safe** — graded from real application state Add at least one member with an explicit permission level. *Where:* `/safes` **Place an account in your safe** — graded from real application state Move an existing account into the safe you created, or create a new one there. *Where:* `/safes` ### Hint Create the safe first — the member and account tasks are graded against the safe you personally created, not the seeded ones. Account → Move to safe is on the account details page, and the safe details page has an Add account action. ### Success criteria You created a safe, gave it at least one member, and placed at least one account in it. ### Debrief Notice what you did not do: you never granted a permission on an individual account. That is the whole design. Safes collapse an unmanageable N-users × M-accounts permission matrix into a small number of group-to-container grants, which is why the first question in any PAM design review is 'what is your safe naming and ownership model?'