# PAM SIM — the complete corpus > 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. Generated from the application's own content modules. The individual documents are served under https://pamsim.com/llms/ and indexed at https://pamsim.com/llms.txt. # PAM SIM — overview > 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. ## What it is A working Privileged Access Management environment you can take apart. You request access to a privileged account, have a second person approve it, open a brokered session, watch a credential rotate, and then read the audit trail you just produced. The point is that the workflows are real: the approval genuinely gates the session, the rotation genuinely changes state, and the audit record genuinely comes from what you did. There is no sign-in and there are no passwords. A visitor arrives with an administrative session already established, so nothing in the simulator is walled off and nobody is asked who they are before they can look. Identity still exists underneath: role-based access control is enforced by the API as well as by the interface, and switching to a narrower identity from the profile menu changes what the application will *do*, not merely what it shows. An Auditor asking the REST console to retrieve a credential gets a real 403. ## Where PAM sits PAM is one of three pillars of identity and access management. IGA — Identity Governance and Administration — owns joiners, movers and leavers, provisioning, access reviews and segregation of duties. AM — Access Management — owns authentication for ordinary users: single sign-on, multi-factor, federation, adaptive access. PAM owns privileged credentials: the vault, rotation, session brokering and the recording. AM decides whether you are who you say you are. PAM decides what you may do once you hold elevated rights, and records it. IGA decides whether you should have had that access in the first place, and asks again every quarter. **PAM SIM simulates the third pillar only.** The identity switcher is a demo convenience, not a federation — there is nothing to authenticate against. ## The spaces, and every route The platform is split into spaces, switched from the service picker in the header — the same way a real deployment separates Privileged Access from Access and from Audit and Reports. ### Privileged Access Vault, safes, accounts, credential rotation and session management. Lands on `/`. - `/` — **Home** (needs dashboard.view) - `/accounts` — **Accounts View** (needs accounts.view) - `/discovery` — **Discovery** — industry term: Account discovery (needs accounts.view) - `/requests/mine` — **My Requests** (needs requests.create) - `/requests/incoming` — **Incoming Requests** — industry term: Dual control (needs requests.approve) - `/safes` — **Safes** (needs safes.view, accounts.view) - `/applications` — **Application Access** — industry term: AAM / Credential Provider (needs applications.view) - `/secrets` — **Secrets Manager** — industry term: Conjur / Secrets Manager (needs secrets.view) - `/sessions` — **Active Sessions** — industry term: PSM - `/recordings` — **Session Recordings** — industry term: PSM recording - `/cpm` — **Credential Management** — industry term: CPM (needs accounts.view) - `/policies` — **Policies** (needs policies.view) - `/reports` — **Reports** (needs reports.view) - `/platforms` — **Platform Management** (needs platforms.view) - `/rest-api` — **REST API** — industry term: PVWA REST API (needs accounts.view) - `/vault` — **Secure Vault** — industry term: Credential vault (needs safes.view) - `/users` — **Identities** (needs users.view) - `/roles` — **Roles & Permissions** (needs users.view) - `/settings` — **Configuration** (needs users.manage, policies.manage) ### Access Reach the assets secured in Privileged Access, whether vaulted or provisioned just in time. Lands on `/portal`. - `/portal` — **Access Portal** — industry term: PVWA (needs accounts.view) - `/access/infrastructure` — **Infrastructure** — industry term: SIA (needs accounts.view) ### Audit and Reports Cross-service record of privileged activity, and the sessions view that spans every access method. Lands on `/audit`. - `/audit` — **Audit** (needs audit.view) - `/platform-sessions` — **Sessions** (needs audit.view, recordings.view) - `/target-events` — **Target Event Log** — industry term: Windows Security log (needs audit.view) ### Identity Security Intelligence Behavioural risk scoring over privileged accounts, sessions and identities, and the events it raises. Lands on `/risk`. - `/risk` — **Risk Center** (needs dashboard.view) - `/alerts` — **Security Events** (needs alerts.view) ### Learn Guided walkthroughs, graded labs, the concept reference and the glossary. PAM SIM's own — no product counterpart. Lands on `/guides`. - `/guides` — **Guided walkthroughs** (needs labs.view) - `/labs` — **Labs** (needs labs.view) - `/concepts` — **PAM Concepts** - `/glossary` — **Glossary** ## Services named but not simulated Listed so a reader can place them, never faked: - **Identity Administration** — Directory integration, authentication policy and provisioning. PAM SIM models identities and roles inside Privileged Access instead. - **Connector Management** — Deployment and health of the connectors that reach target networks. - **Secrets Hub** — Synchronisation of vaulted secrets into cloud-native secret stores. - **Secure Cloud Access** — Time-bound, role-based access to cloud consoles with zero standing entitlements. ## Roles and permissions Every identity holds exactly one role, and a role is a set of permissions the API checks on each call. Two designs in this table are deliberate and worth noticing: the PAM Administrator who operates the vault is **not** an approver, because the operator of a system should not authorise its use; and the Auditor can see every session and recording but can never retrieve a credential. | Role | Permissions | What it is for | | --- | --- | --- | | Administrator | 28 | Unrestricted platform access. Used sparingly and itself subject to audit — in production this role would be vaulted and requested, not held permanently. | | Security Administrator | 19 | Owns security posture: policies, security events, session monitoring and approvals. Can force credential rotation but does not administer safes or platforms. | | PAM Administrator | 24 | Day-to-day operation of the vault: safes, accounts, platforms and credential rotation. Deliberately not an approver — the operator of the system should not authorise its use. | | Auditor | 14 | Read-only oversight. Sees every audit event, session and recording, and can run any report — but can never retrieve a credential or open a session. | | Approver | 10 | Authorises privileged access requests on behalf of the business. Can raise and use requests of their own, but sees no administrative configuration. | | Help Desk | 8 | First-line support. May retrieve credentials for the safes they belong to and open sessions, but cannot change any configuration or approve requests. | | Standard User | 5 | An ordinary engineer. Can search the account inventory, raise access requests with justification, and use whatever is approved for them. | | Read Only | 8 | Compliance and reporting visibility with no ability to act. Useful for regulators, risk functions and onboarding. | | Privileged Access Auditor | 14 | Product-named role. Read-only oversight of the privileged access service: accounts, sessions, recordings, audit and reports. Cannot retrieve a credential. | | Session Risk Managers | 10 | Product-named role. Reviews privileged sessions and acts on risk: monitor, suspend and terminate live sessions, replay recordings and close security events. | ### The permission vocabulary The 28 permissions the API recognises: `dashboard.view`, `accounts.view`, `accounts.manage`, `credentials.retrieve`, `credentials.rotate`, `requests.create`, `requests.approve`, `sessions.own`, `sessions.monitor`, `sessions.terminate`, `recordings.view`, `safes.view`, `safes.manage`, `platforms.view`, `platforms.manage`, `policies.view`, `policies.manage`, `users.view`, `users.manage`, `audit.view`, `alerts.view`, `alerts.manage`, `reports.view`, `applications.view`, `applications.manage`, `secrets.view`, `secrets.manage`, `labs.view`. ## Recent changes - **2026-08-21 · Platform — Spaces and services.** Navigation is now organised into spaces — Privileged Access, Access, Audit and Reports, Identity Security Intelligence — switched from the service picker rather than stacked in one sidebar. - **2026-08-21 · Accounts — Favorites, saved views and password versions.** The accounts view opens on Favorites, searches can be saved as named views, and each account now has a Versions tab showing every value the CPM has set — including the temporary ones a reconcile leaves behind. - **2026-08-21 · Monitoring — Monitor a live session.** A fourth action alongside suspend, resume and terminate: open a copy of a running session to watch it, or take co-control. The session owner is notified either way. - **2026-08-21 · Access — Request Timeframe and multiple access.** Requests now carry an explicit from/to window and a 'multiple access is required' option, and a reason is mandatory on the approver's side of every decision. - **2026-08-20 · Labs — Eight graded hands-on labs.** Labs are verified against real application state — the audit trail, rotation jobs and safes you actually produce — rather than a checkbox. ## The rest of the corpus Every other document is listed at https://pamsim.com/llms.txt. # PAM concepts > 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. ## The stack — where each piece sits *Four products, four different questions, one sentence.* **Industry term:** ZTNA + MFA + authenticator + PAM **In the app:** `/concepts` Expect an opening question about how these fit together, and expect it to be testing whether you see them as competing tools. They are not. Each answers a different question in the same sentence. Zscaler — can you reach it? It brokers the connection. Zero Trust Network Access replaces the VPN: you are granted a path to one specific application, never placed on the network. The multi-factor service — are you really you? It proves the human behind the credential, and raises or lowers friction according to risk signals. The authenticator — how strongly can you prove it? A FIDO2 security key is phishing-resistant in a way a push notification is not, which is why privileged users get one. The privileged access platform — what can you do once you are in? It controls the elevated credential: vaulted, rotated, brokered through a recorded session, never handed to the user. The sentence that ties them together: network access decides whether you reach the system, the factor and the token prove who you are, and privileged access management controls what you can do as an administrator once you are there — with audit evidence produced at every step. Defence in depth, where each layer fails safe. Only the fourth is simulated here. The others are named so you can place them, and because the failure modes cross over: a federation outage stops privileged work while the vault is perfectly healthy. --- ## Why privileged access management exists *Blast-radius containment, not password hygiene.* **Industry term:** PASM / PEDM / secrets / CIEM **In the app:** `/risk` The answer that separates a candidate is being able to walk an attack chain and say which control breaks which link. Initial access, then credential theft, then lateral movement, then privilege escalation, then domain dominance, then persistence. The named techniques worth recognising: pass-the-hash, pass-the-ticket, Kerberoasting, AS-REP roasting, DCSync, golden and silver tickets, NTLM relay, token impersonation, and harvesting credentials from the memory of the local security authority process. They map to the credential-access and lateral-movement tactics in the public adversary catalogue, which is worth saying when it helps rather than as decoration. Where the controls bite: vaulting removes the shared secret people know; rotation makes a stolen credential expire on its own; brokering keeps the secret off the endpoint so it cannot be harvested from memory; session recording makes what happened reconstructable; and just-in-time elevation removes the standing membership that made escalation worth attempting. The taxonomy matters because each class has its own failure mode, and forgetting a class is how estates stay exposed. Local administrator; domain, enterprise and schema admin. Service accounts, and the hardcoded credentials in scripts and configuration. Break-glass and shared accounts. Unix root and sudo. Database privileged accounts. Network device enable accounts. Hypervisor and backup-system accounts — routinely forgotten and effectively Tier 0, because whoever holds the backups holds the data. SSH keys, usually the largest unmanaged population in the estate. API keys, tokens and certificates. Pipeline secrets. Cloud privileged identities and the entitlement sprawl that follows them. And the fact underneath all of it: non-human identity now outnumbers human identity, which is the hardest part of the job rather than a footnote to it. The complete control set a mature programme deploys: vaulting; rotation with verification and reconciliation; enforced uniqueness and complexity; credential injection so no human sees the secret; session proxying, isolation, recording, live monitoring and termination; just-in-time elevation, ephemeral credentials and zero standing privilege; approval workflows, dual control and time-boxed access; endpoint least privilege and application control; discovery and automated onboarding; secrets management for applications and pipelines; threat analytics; and tamper-evident audit trails. One framing to have ready: the analyst-firm split of the market into account and session management, privilege elevation and delegation, secrets management, and cloud entitlement management. Most conversations that call themselves privileged access management are only the first of those four. --- ## Tiering the administrative plane *Credentials that can reach everything must never be typed on machines that browse the internet.* **Industry term:** Tier 0 / Enterprise Access Model / PAW **In the app:** `/vault` The tiered model splits administration by what an identity can control. Tier 0 is anything that controls identity itself — domain controllers, the identity provider, the vault, backup systems, hypervisors. Tier 1 is servers and applications. Tier 2 is user workstations. The rule is that credentials never flow downwards: a Tier 0 credential is never used on a Tier 1 or Tier 2 machine, because typing it there exposes it to whatever has compromised that machine. Microsoft's successor framing is the enterprise access model, which broadens the same idea to control planes, management planes and data planes across cloud and on-premises, rather than three server tiers. Know both names; the principle did not change. The practical expression is a privileged access workstation: a hardened, single-purpose machine used only for administration, with no email and no general web browsing, which is where Tier 0 work actually happens. A jump or bastion host does a related job for a specific target estate. The session gateway is a jump host with the credential handling and recording built in. The earlier design with a separate hardened forest — the red forest — is retired, and knowing why is a small credibility marker: it protected identity administration well and did nothing for the cloud control plane, which is now where the crown jewels sit. It gets asked because it distinguishes people who learned this recently from people who learned it once. The vault is itself Tier 0. That is not a slogan: it drives hardening, high availability, a disaster recovery replica and a recovery path you have actually tested — and it is why the credentials that recover the platform cannot depend on the platform. --- ## Authenticators — and why the form factor is not the point *Phishing resistance is the dividing line, not whether you can hold it.* **Industry term:** FIDO2 / WebAuthn / OTP tokens / PIV **In the app:** `/concepts` The instinct that hardware is automatically strongest is wrong, and saying so is the answer. A security key implementing the modern web authentication standard is phishing-resistant. A one-time-password fob is hardware and still phishable, because a relay can capture and replay the code inside its validity window. What makes a key resistant is not the plastic: the private key never leaves the device, and the credential is bound to the origin, so it will not sign for a lookalike domain. A user pushed to a convincing replica simply cannot complete the ceremony. User verification by PIN or biometric adds the second factor, and discoverable credentials enable passwordless sign-in entirely. One-time-password hardware — the classic fob, and the open-standard time-based and counter-based tokens — shares a seed at manufacture and displays a rotating code. Stronger than a code sent by message, and still phishable. The operational details that come up: clock drift, next-tokencode mode, and a passcode formed from a PIN plus the displayed code. Certificate-based smart cards sit behind a public-key infrastructure: the card holds the private key and a PIN unlocks it. Common in government and heavily regulated estates, and they bring a whole certificate lifecycle with them — issuance, renewal, revocation, and a certificate authority that is itself Tier 0. Multi-protocol devices are why one key can cover a mixed estate: the same device can act as a modern web authenticator, a smart card, a time-based token and a code generator at once. That flexibility is what makes them practical for privileged users who still meet legacy systems. The lifecycle is the hard part, and it is where audit findings come from. Procurement and inventory, enrolment to a named user, distribution with a chain of custody, replacement for lost or broken devices, revocation on loss, and return on termination. An unreturned token from a leaver is a finding; an untracked spare is worse. Every deployment needs an answer to "I left it at home", and that answer is the control most likely to decay into a routine workaround. Verify identity out of band before issuing anything — the lost-token call is a social-engineering target, so that step is a control, not paperwork. Prefer a second registered key to a bypass code. If a code is issued, make it single-use and short-lived, alert on issue and use, and review who is using them and how often. Policy in practice: hardware for privileged and high-risk populations, software authenticators for everyone else. The federal assurance framework's highest authenticator level effectively requires hardware, which is the standards-based way to justify the cost. --- ## Zero trust network access, precisely *Two different products with opposite directions, and people call both of them "the VPN".* **Industry term:** ZTNA / SASE / SSE **In the app:** `/concepts` Be precise, because the imprecision is itself the filter. The private-access product is a zero-trust replacement for the VPN. The internet-access product is a cloud secure web gateway. They are licensed, configured and logged separately, and they point in opposite directions. Private access replaces the VPN. Connectors sit beside the application and make outbound connections to the cloud service; when a user requests the application, the broker stitches the user's outbound connection to the connector's outbound connection in the middle. There is no listening port on the application side, no inbound firewall rule, and nothing internet-facing to scan. Users are brokered to one specific application and never placed on a network — which removes by design the lateral movement a VPN grants by design. Internet access is the outbound half: URL filtering, encrypted-traffic inspection, cloud firewall, sandboxing, cloud application visibility and data loss prevention. Traffic reaches it through an endpoint agent, proxy configuration files, or tunnels from branch offices. The architecture pieces worth naming: the endpoint agent, the connectors deployed beside private applications, the enforcement nodes in the cloud where policy is applied, and the central authority that distributes configuration and policy. Inspecting encrypted traffic is necessary because that is how threats arrive, and it is consequential: it needs a trusted root certificate on every endpoint and bypass lists for banking, healthcare and certificate-pinned applications. Privacy, legal and works-council considerations are part of the answer rather than an afterthought — saying so is what makes the answer sound like it came from a deployment. Identity and posture converge here. Authentication federates to the identity provider, users and groups synchronise by the provisioning standard, and device posture — patch level, disk encryption, an endpoint detection agent, a certificate, domain membership — gates access. Posture is a point-in-time attestation from the endpoint, so it complements controls on the target rather than replacing them. The logs are evidence: who reached which application, when, from what device, streamed into the enterprise security monitoring platform. Two acronyms that appear constantly in job descriptions: the convergence of networking and security delivered from the cloud, and the security half of that convergence on its own — the secure web gateway, cloud application broker, zero-trust access and data loss prevention pieces. How it combines with privileged access: network access decides whether you can reach the administrative plane at all, per application, with identity and posture as inputs, exposing nothing inbound — so it shrinks blast radius before privilege is involved. Privileged access decides what you can do once there. Layered, stolen credentials alone do not get an attacker to the jump host; they also need an enrolled identity and a device that passes posture. --- ## Running the platform — upgrades, resilience and cost *The half of the job that is not access engineering, and where the awkward questions live.* **Industry term:** DR / upgrade order / licensing **In the app:** `/vault` Resilience first, because privileged access is a Tier 0 availability dependency. A disaster recovery vault replicating from the primary, distributed or satellite vaults where an estate is geographically split, and load-balanced portal, credential manager and session manager components. Backup and restore have their own dedicated utilities rather than being a file copy, because the encrypted store is not something you back up by copying the directory. Expect the follow-up question, and expect it to be the real one: have you actually tested a failover, or only documented one? A replica nobody has promoted is a belief. The honest answer names when you last tested and what broke. Upgrades have an order and it matters: the vault first, then the portal, then the credential manager, then the session managers, with version compatibility checked across components. In-place against side-by-side is a risk decision rather than a preference. And always re-validate a rotation and a live brokered session afterwards — an upgrade that leaves credential management silently failing is worse than no upgrade, because nothing alerts and the failure surfaces months later as an audit finding. Where to look when it breaks, by component: the credential manager's console and trace logs for rotation failures; the session manager's logs for connection component errors; the portal's logs for interface and API problems; the vault trace for authentication and permission problems. Most failures are environmental rather than product defects, and saying that unprompted signals experience. The common failure modes, in the order you meet them: the credential manager cannot rotate, because of drift, reconcile-account permissions, connectivity or platform misconfiguration; session connection components erroring; discovery missing accounts; replication falling behind; and service dependencies breaking after a rotation. Licensing is licensed per managed account, which is why "onboard everything" meets budget resistance and why prioritising by risk — Tier 0 first — is simultaneously good security and good politics. Being able to say that out loud is a sign you have argued for a budget rather than only consumed one. Deployment model: self-hosted keeps control of upgrade timing, network placement and data residency, which regulated banks often want and sometimes need. The hosted model removes the infrastructure, availability and upgrade burden, which is real capacity returned to access engineering. Have a view and be able to justify it, and say what would change your mind. --- ## Maturity and the numbers that prove it *How to frame a roadmap answer, and what to quantify when you do.* **Industry term:** PAM maturity model / programme metrics **In the app:** `/reports` The arc, which is the frame for any "where would you take this?" question: ad hoc, then discovered and inventoried, then vaulted, then rotated, then session-controlled, then least privilege enforced, then just-in-time with zero standing privilege, then analytics and identity threat detection driven. The value of the arc is that it forces the order. You cannot secure an estate you have not inventoried; you should not attempt session control before the credential is vaulted and rotating; and zero standing privilege is meaningless while nobody knows what standing privilege exists. The numbers to quantify with. Coverage: the percentage of the known privileged estate actually under management, and discovery coverage against the estimated estate. Hygiene: rotation compliance, credential age, and the failed-rotation backlog. Control: the percentage of privileged sessions isolated and recorded. Direction of travel: standing-privilege reduction and just-in-time adoption. Operations: time to onboard an account, break-glass usage count and review rate. Lifecycle: orphaned or stale privileged accounts eliminated, and deprovisioning time for leavers. Authentication: multi-factor coverage on administrative access, and specifically the share on phishing-resistant factors. Hardware: tokens issued, returned on termination, and unreturned — an audit-visible number. Compliance: access-review completion rate, and control gaps closed. The first metric is the most diagnostic, and it works as a question to ask them as well as an answer to give: what percentage of the privileged estate is under management? If there is no number, that is the number — no denominator means no discovery, and the first six months of the job are an inventory exercise. --- ## The standards behind the requirements *Which document a control actually comes from, and which ones a bank examiner works from.* **Industry term:** NIST / CIS / ISO / PCI DSS / FFIEC **In the app:** `/concepts` The federal control catalogue is the vocabulary most control language borrows from: account management, segregation of duties, least privilege, remote access, and the whole audit and accountability family. When somebody asks why a control exists, this is where the requirement is written down. The digital identity guidelines split assurance into three dimensions — how strongly the identity was proofed, how strongly the authenticator proves possession, and how strongly a federated assertion is protected. The top authenticator level effectively requires hardware, which is the standards-based justification for buying keys. The zero trust architecture publication is the model behind network access that refuses to trust anything because of where it sits on the network. The internet security benchmarks contribute two directly relevant controls — account management and access control management — plus the hardening baselines you are measured against. The international management standard contributes its access-control clauses. The card-data standard's requirements seven and eight cover restricting access by business need and identifying and authenticating every user, including multi-factor for all administrative access and the rule that shared accounts must be individually attributable. For a bank specifically: the financial privacy legislation's safeguards reach banks through interagency guidelines enforced by the banking agencies rather than through the trade regulator's rule — a distinction worth getting right. The examination council publishes the handbook examiners actually work from. The national bank supervisor sets heightened standards for large institutions. And the financial reporting legislation is what makes access to programs and data an audited domain rather than a preference. On the data side, the requirements that touch access decisions: classification, loss prevention, encryption at rest and in transit, key management, data access governance, and the privacy regimes where they drive who may see what. --- ## The wider landscape *Do not be a one-vendor candidate.* **Industry term:** Market landscape **In the app:** `/concepts` Naming the alternatives shows you understand the category rather than one product's menu, and it is a normal interview question because most estates have more than one of these. Privileged access: the main platform this simulator models, plus the other established vendors in the space, each with a password-store product and an endpoint-privilege product. Their existence matters because you will meet them in an acquisition. Secrets and infrastructure access: the general-purpose secrets managers and the modern infrastructure-access products that broker SSH, Kubernetes and database sessions with short-lived certificates rather than stored passwords. Increasingly the answer for engineering estates. Multi-factor and identity: the federation and multi-factor vendors, and the large cloud identity providers whose own privileged identity management does time-bound role activation natively. Zero trust and the security service edge: the network-access vendors whose products replace the VPN and inspect outbound traffic. Cloud-native privilege: the cloud providers' own secret stores and identity centres, plus just-in-time role activation. This is where the model shifts from an account with a password to a role that can be assumed, and from rotation to eliminating persistent access altogether. The useful sentence: the fundamentals survive the vendor. Discover, apply least privilege, remove standing access, broker and record, produce evidence. The product decides how, not what. --- ## The federation and multi-factor portfolio *The multi-factor service is one product in a stack you should be able to name.* **Industry term:** PingID / PingFederate **In the app:** `/concepts` Banks often favour this vendor because its federation server can run on-premises and hybrid, unlike pure cloud-only identity platforms — which matters when data residency and examiner expectations constrain where authentication happens. The pieces: the multi-factor service; the federation server that speaks the assertion, connect and delegated-authorisation protocols and acts as an authorisation server; the cloud platform; the web access management and reverse proxy product; the directory; the fine-grained authorisation product; and the identity orchestration tool. The federation server is the component most likely to sit in the login path of everything, which makes its availability design a first-order concern rather than a detail. Its concepts worth knowing: identity-provider and service-provider connections, adapters for form, Kerberos and composite authentication, token translation between protocols, attribute mapping and policy contracts, and clustering. Authentication methods, roughly in order of strength: security keys and platform biometrics first, because they are origin-bound; then push with number matching; then time-based codes in an application; then codes by email; with message and voice delivery last, because of subscriber-identity swapping and interception. Desktop login for both major operating systems, and offline one-time codes for the no-network case. Where it integrates: network devices and VPN concentrators through the legacy remote-authentication protocol, desktop login, SSH, third-party single sign-on, and custom applications through the software development kit. That legacy protocol is the standard answer to how multi-factor gets in front of infrastructure that cannot speak modern federation. Policies evaluate signals — impossible travel, address reputation, a new device, network zone, device posture — and step challenges up or waive them, so friction is proportional to risk. For privileged identities, set a floor rather than letting a low score waive the challenge. The operational reality is device lifecycle: pairing and enrolment, device management, lost and replaced phones, temporary bypass codes and re-enrolment. Bypass codes are the soft underbelly — a legitimate necessity and a standing risk. --- ## What is a Vault? *The hardened, encrypted store that holds every privileged credential.* **Industry term:** Credential vault / Enterprise Password Vault (EPV) **In the app:** `/vault` The Vault is the secure repository at the centre of a PAM deployment. Privileged passwords, SSH keys and secrets are encrypted and stored here instead of living in scripts, spreadsheets, password managers or people's heads. A vault is built around a layered key hierarchy: each stored object is encrypted with its own key, those keys are protected by a safe key, and the safe keys are protected by a server key that is held outside the database. Losing the database alone therefore yields nothing usable. Critically, the Vault is not just storage — it is a policy enforcement point. Nothing enters or leaves without an authenticated identity, an authorisation check against the safe, and an audit record. That is what separates a vault from a database with a password column. --- ## What is a Safe? *A logical container that groups privileged accounts and controls who may use them.* **Industry term:** Safe **In the app:** `/safes` A safe is the unit of authorisation inside the Vault. Accounts are placed into safes, and permissions are granted on the safe rather than on individual accounts — so access control scales with the number of teams, not the number of credentials. A well-designed safe maps to a single scope of duty: one team, one environment, one class of system. 'Windows Servers — Production' is a good safe. 'All Passwords' is not, because every permission grant on it is automatically over-broad. Membership is granular. A user may be allowed to retrieve credentials (Use), administer the accounts inside (Manage), authorise other people's requests (Approve), or only read the history (Audit). Least privilege is expressed here. --- ## What is a privileged account? *Any identity whose credentials grant elevated control over a system, application or cloud tenant.* **Industry term:** Account **In the app:** `/accounts` A privileged account is one that can change the state of a system rather than merely use it: domain administrators, local administrators, root, service accounts, database owners, network device enable accounts, cloud tenant administrators and break glass accounts. In PAM terms an 'account' is the combination of a username, a target address, and the platform that describes how the credential is to be managed. The same username on two different servers is two accounts, because each has its own credential lifecycle. Privileged accounts are attractive to attackers precisely because they are shared, long-lived and often unmonitored. Vaulting them replaces all three properties: the credential becomes unknown to humans, short-lived, and used only through an audited path. --- ## What is the PVWA? *The web portal where users search for privileged accounts, request access and launch sessions.* **Industry term:** PVWA (Password Vault Web Access) **In the app:** `/portal` The Password Vault Web Access is the primary human interface to the Vault. Users do not connect to target systems directly and they do not learn passwords — they come to the portal, find the account they need, justify why they need it, and receive time-limited access. The portal is also where administrators onboard accounts, define safes and platforms, and review compliance. In the modern platform this experience has been folded into a single unified portal alongside the other identity security services. The design principle is that the portal is the only front door. If a user can reach a privileged credential any other way, every control behind the portal — approval, recording, rotation, audit — is optional in practice. --- ## What is the CPM? *The engine that automatically changes, verifies and reconciles privileged credentials.* **Industry term:** CPM (Central Policy Manager) **In the app:** `/cpm` The Central Policy Manager enforces credential policy without human involvement. On a schedule set by the platform it connects to each target, changes the password to a new random value that satisfies the complexity rules, verifies that the new value works, and writes it back into the Vault. Three job types matter. Change replaces the password. Verify confirms the stored password still authenticates against the target — this is how drift is detected. Reconcile uses a separate, highly privileged reconciliation account to forcibly reset a credential that has drifted out of sync. Automatic rotation is what makes a compromised credential expire on its own. It also means no human ever needs to know the password, which in turn is what makes session brokering and full auditability possible. --- ## What is the PSM? *A controlled gateway that brokers privileged sessions so they can be isolated, monitored and recorded.* **Industry term:** PSM (Privileged Session Manager) **In the app:** `/sessions` The Privileged Session Manager sits between the user and the target system. The user's client connects to the PSM; the PSM retrieves the credential from the Vault and opens the real connection to the target. The credential is injected, never revealed. Because every session passes through the gateway, three things become possible: isolation (malware on the user's endpoint never touches the target directly), monitoring (an administrator can watch, suspend or terminate a live session), and recording (a replayable, searchable record of everything that was done). This is also where risk detection happens. Commands and window activity are scored as they occur, so a session that starts as routine maintenance and turns into credential dumping raises an alert while it is still running. --- ## What is the PSMP, and how does it differ from the PSM? *The same brokering idea for SSH, done as a proxy so the native client still works.* **Industry term:** PSMP / PSM for SSH **In the app:** `/platforms` The Privileged Session Manager for SSH — usually written PSMP — brokers SSH, SCP, SFTP and Rsync. It exists because the Windows-oriented PSM model does not fit how engineers actually work on Unix: forcing them through a Windows jump host to reach a Linux box is friction they will route around. The difference is the shape, not the principle. The PSM is a jump server: your RDP client connects to it, and it runs the session on your behalf on a Windows host. The PSMP is a transparent proxy: you use your normal ssh client, with a connection string like ssh alice@root#linux-prod-01@psmp.corp, and the proxy authenticates you, fetches the credential from the vault, opens the real session and records it. Nothing is installed on the target. Consequences worth knowing. PSMP runs on Linux and PSM on Windows, so they are separately deployed, separately hardened and separately capacity-planned. PSMP supports SSH key authentication as well as passwords. And because it keeps the native client, it is what makes 'no direct SSH to production' an enforceable rule rather than a policy nobody follows. In an interview the trap is treating them as one product with two names. They are two components, and the tell is the port: 3389 for RDP through the PSM, 22 for SSH through the PSMP. --- ## How do applications get privileged credentials? *They ask a provider at runtime, and the provider authenticates the application itself.* **Industry term:** AAM / Credential Provider / CCP **In the app:** `/applications` Everything else in a PAM platform assumes a human who can be shown a portal and asked to justify themselves. Applications cannot do that, and they need privileged credentials constantly — a database password, an API key, a service account for a scheduled task. Left alone, those end up in config files, deployment scripts and source control, where they never rotate because rotating them breaks something. The credential provider inverts it. Nothing is stored in the application: it asks for the secret when it needs it, and the provider authenticates the *application* by its own properties — the host it runs on, the OS account it runs as, the path and cryptographic hash of its executable, or a client certificate. Because the application holds nothing, the credential is finally free to rotate. Two deployment shapes. The Credential Provider is an agent on the application server: the call is local, it can inspect the calling process directly, and it caches so a retrieval survives a network outage. The Central Credential Provider is agentless — an HTTPS call to a REST endpoint — which is the only option for containers, appliances and hosts rebuilt from an image, at the cost of a network dependency and weaker identity, since there is no local process to inspect. The failure worth knowing: an application identified only by its network address. Anything else running on that host presents the same address, so the credential is protected by nothing more than a foothold on the server. Taking a password out of a config file and stopping there is half a remediation, and it is extremely common. --- ## Where does PAM sit inside IAM? *One of three pillars — governance, access management and privileged access.* **Industry term:** IAM / IGA / AM / PAM **In the app:** `/concepts` PAM is a subset of IAM, not a synonym for it, and at a bank each pillar is usually a separate team with its own tooling and its own manager. IGA — Identity Governance and Administration — owns the lifecycle. Joiners, movers and leavers; provisioning and deprovisioning; access review campaigns and recertification; segregation-of-duties rules. It answers whether an identity should have access at all, and asks again every quarter. AM — Access Management — owns authentication for ordinary users. Single sign-on, multi-factor, federation over SAML and OIDC, adaptive or risk-based access, session management. It answers whether you are who you say you are. PAM owns privileged credentials: vaulting, rotation, session brokering, recording. It answers what you may do once you hold elevated rights, and makes it reconstructable afterwards. They are not independent. You reach the privileged portal through AM, so an MFA or federation outage stops privileged work while the vault is perfectly healthy — a real incident pattern that catches people out. And IGA's leaver process is what should remove safe membership; when it fails, the orphaned privileged access is what makes the failure visible. --- ## What is a secrets manager, and how is it different from a vault? *Identity comes from the platform, and many secrets are minted on demand and expire.* **Industry term:** Conjur / Secrets Manager / Secretless **In the app:** `/secrets` The vault model assumes a credential that exists between uses: it is stored, it is rotated, and the control is how often you change it. That is right for a domain administrator account and a network switch, and it fits badly around containers and pipelines, which appear and disappear faster than any rotation schedule. A secrets manager changes two things. Identity is borrowed from the platform the workload already runs on — Kubernetes signs a service-account token, AWS confirms which role signed a request, an OIDC provider signs a token for a specific pipeline run. Nobody has to place a bootstrap credential on the host, which is the circular problem that defeats the naive approach. The second change is dynamic secrets. Instead of storing a value and rotating it, the manager mints one when it is asked for — a short-lived STS credential, a database user created with the right grants and dropped afterwards — with a time to live. Nothing exists before the request and nothing persists after the lease, so there is no rotation to schedule, no standing credential to steal, and a leaked build log is worthless by the time anyone reads it. The unit of management is the lease, and the containment action is to revoke it. It does not replace the vault, and saying so is part of the answer. A target has to support minting and destroying credentials for a dynamic secret to be possible; a mainframe cannot. Real estates run both and synchronise the static secrets between them so one credential has one source of truth. Access is defined as policy in version control rather than clicked together, which is what makes 'who can read this secret' a question you answer with grep. --- ## What is PTA? *The analytics layer that decides which privileged activity is worth waking someone for.* **Industry term:** PTA (Privileged Threat Analytics) / Identity Security Intelligence **In the app:** `/alerts` Privileged Threat Analytics watches privileged activity and raises named detections. The audit trail records everything that happened; PTA is the judgement about which of it matters. Without that layer a bank generates millions of privileged events a month and reviews none of them meaningfully. It draws on three sources at once, which is what lets it see things no single source can. From the vault it knows every legitimate credential retrieval and rotation. From the session gateway it knows what was typed and run. From directory and network telemetry it knows what authenticated where. A privileged logon on a domain controller that has *no* matching vault retrieval is the classic finding: someone used a credential the vault did not hand out. The detections are a finite list rather than a vague notion of 'anomaly' — suspected credential theft, PSM bypass, golden ticket, over-pass-the-hash, unmanaged privileged account, irregular hours, irregular source, excessive access. Each carries a remediation, and the important ones can be automatic: on suspected theft the platform can rotate the credential immediately, which invalidates what the attacker took while the investigation is still being opened. Know where it sits relative to the SIEM. PTA is privileged-specific and understands vault context; the SIEM is enterprise-wide and does not. In practice PTA detects and the SIEM correlates — PTA findings are forwarded there so a privileged detection can be joined to endpoint and network evidence. --- ## What is a Platform? *The policy template that defines how a class of accounts is managed.* **Industry term:** Platform **In the app:** `/platforms` A platform answers the operational questions for a whole class of accounts at once: how long may the password live, how complex must it be, how do we connect to change it, do we verify, do we auto-reconcile on failure, is dual control required, must sessions be recorded, how long may a session run. Accounts inherit their behaviour from their platform. Change the change interval on the Windows Domain Account platform and every account using it is re-evaluated for compliance — this is why platforms, not accounts, are the right place to express policy. Platforms also encode the connection mechanics: which connection component drives an RDP session, whether SSH uses a key or a password, which SQL driver reaches the database. That is the part that makes a policy actually executable. --- ## How does privileged access approval work? *Dual control: a second person must authorise before privilege can be used, and only for a fixed window.* **Industry term:** Dual control / access workflow **In the app:** `/requests/incoming` The requester selects an account, states a business justification, optionally references a ticket, and asks for a specific time window. Nothing is granted yet — the request sits in the approver's Incoming Requests queue. The approver reviews the justification against the sensitivity of the account and the requester's role, then confirms or rejects with a comment. Approval creates a grant with a hard expiry; when the window elapses the grant dies on its own without anyone remembering to revoke it. This is the mechanism underneath just-in-time access and Zero Standing Privileges. The user holds no privilege at rest; they acquire it for the duration of a task and lose it automatically. Every step — request, decision, use, expiry — is audited. --- ## How does session recording work? *Everything done in a brokered session is captured as a replayable, scored timeline.* **Industry term:** PSM recording **In the app:** `/recordings` Because the session gateway sits in the middle of the connection, it can capture the session as it happens: commands typed in a shell, window titles opened in a desktop session, SQL statements issued against a database. The result is a timeline rather than a video file alone — individual activities are indexed, searchable, and scored for risk, so a reviewer can jump straight to the interesting moment instead of watching an hour of idle desktop. Recording serves two purposes: deterrence (people behave differently when the session is on the record) and forensics (after an incident you can reconstruct exactly what a privileged identity did, and prove what it did not do). --- ## How does RBAC work here? *Permissions attach to roles; roles attach to users; safes add a second, resource-scoped layer.* **Industry term:** Roles, safe permissions **In the app:** `/roles` PAM SIM uses two complementary layers. The role determines what kind of thing you may do at all — retrieve credentials, approve requests, manage platforms, read audit. Safe membership determines which resources you may do it to. An Auditor can read every audit event and every recording but cannot retrieve a single credential. A Standard User can search accounts and raise requests but cannot approve their own. A PAM Administrator manages safes, accounts, platforms and rotation but is deliberately not an approver by default. That separation is the point: the person who can grant access, the person who can use access, and the person who can review access should not be the same person. Try switching identity in the header — the navigation and the buttons change with your permissions, not just the error messages. --- ## How does auditing work? *Every meaningful action writes an immutable, attributable event.* **Industry term:** Audit / Identity Security Intelligence **In the app:** `/audit` An audit event records timestamp, actor, action, resource, source IP, result and risk. Read-only actions count: retrieving a credential is one of the most important events in the log, because it is the moment a human gained the ability to act as a privileged identity. Attribution is what PAM adds over native system logs. A target system only ever sees 'Administrator logged in'. The vault knows which human borrowed that identity, under which approval, for which stated reason. Good audit is complete and boring — it is not an alerting system. Security events and risk scoring sit on top of the audit trail to pick out what deserves attention; the trail itself is designed to be exhaustive. --- ## What is break glass access? *The credential of last resort, wrapped in heavy compensating controls.* **Industry term:** Break glass / emergency access **In the app:** `/portal` Break glass accounts exist for the day the normal path fails — the identity provider is down, the approval chain is unreachable, or a domain-wide outage has locked everyone out. They are deliberately powerful and deliberately uncomfortable to use. The controls around them are compensating rather than preventive: mandatory emergency justification, expedited but still-required authorisation, unconditional session recording, a critical security alert the moment they are touched, and automatic credential rotation as soon as the session ends. The rotation is the part people forget. Without it, an emergency password becomes a shared standing credential that a handful of people now know — which is exactly the risk the whole PAM programme was built to remove. --- ## How is risk scored? *An additive, explainable model: privilege + password age + usage + anomaly + violations.* **Industry term:** Risk scoring / Identity Security Intelligence **In the app:** `/risk` PAM SIM scores each account out of 100 by adding named factors. Base privilege reflects what the account can do (a domain administrator outranks a read-only service account). Password age is measured against the platform's change interval, so 'old' is relative to policy rather than absolute. Access frequency, session anomalies (high-risk activity observed in recorded sessions) and outstanding policy violations add the rest. Every contributing factor is shown on the account with its point value and the reason it applied. Explainability is the design goal. A risk score nobody can decompose is a number nobody acts on — the useful question is never 'is this 82 or 74?' but 'which of these five things do I fix first?' --- ## What are Zero Standing Privileges? *Nobody holds privilege at rest; it is granted for a task and removed automatically.* **Industry term:** Zero Standing Privileges (ZSP) / JIT access **In the app:** `/portal` Standing privilege is an account that is permanently a member of an administrative group. It is convenient and it is the single largest source of lateral-movement risk, because compromising the user compromises the privilege permanently. Zero Standing Privileges inverts the default: the user is ordinary until an approved, time-bound grant elevates them, and they return to ordinary automatically. The modern shorthand for the three variables involved is TEA — Time, Entitlements, Approvals. Vaulting a shared credential is the first step towards this, brokering the session is the second, and time-limited approval is the third. PAM SIM's request workflow demonstrates all three together. --- ## Safe, platform or Master Policy — where does a rule live? *Three layers: who may touch it, how it is managed, and the rules that sit above both.* **Industry term:** Safe / Platform / Master Policy **In the app:** `/policies` This is one of the most reliable interview questions, because the answer separates people who have administered a vault from people who have read the datasheet. Three objects, three different questions. A safe answers who may touch this credential. It is the authorisation boundary: membership decides who can list, use, retrieve, add, manage or approve. If two teams need different access to the same kind of system, that is a safe problem. A platform answers how this credential is maintained. It is the technical policy for a class of account: rotation interval, password complexity, verification, reconciliation, which connection components may be used, how the plugin talks to that target type. If two accounts sit in the same business area but one is a Windows domain account and the other an Oracle database account, they need different platforms and can share a safe. The Master Policy sits above both, holding organisation-wide rules: require dual control, enforce exclusive access, one-time passwords, demand a reason or a ticket, mandate session recording. Exceptions are granted per platform. So the question 'how do you make this one system stricter?' is a Master Policy exception on its platform. A new safe would change who can reach it, which is a different question — and saying that distinction out loud is the answer. --- ## How is a privileged access platform automated? *A REST interface behind the portal — and the status code tells you which layer failed.* **Industry term:** PVWA REST API **In the app:** `/rest-api` Everything done by hand in the portal is available programmatically: creating accounts, safes and members, triggering rotations, pulling evidence. That is what makes onboarding at scale possible, and what makes a scheduled quarterly access review an extract rather than three days of clicking. The sequence is always the same shape. Authenticate and receive a session token, send that token in the Authorization header on every call, check the status code and the response body, log off. A script that authenticates in a loop and never logs off exhausts the session limit, and the resulting failure looks like an outage. The status codes are where the interview questions live, because each one sends you somewhere different. 400 the request was malformed. 401 you never got in. 403 you got in and are not allowed. 404 it does not exist, or exists and is invisible to you. 409 the state refuses it, usually a duplicate. 429 you are being throttled. 5xx the server failed and nothing you send will fix it. 401 against 403 is the one that gets asked. Troubleshooting safe permissions on a 401 wastes the first twenty minutes; regenerating a token on a 403 achieves nothing, because the token was never the problem. The worse habit is the usual fix for a repeated 403 — granting the automation identity administrative rights, which converts a permissions question into a standing privileged account with its credential in a config file. What makes automation safe rather than clever: a dedicated identity per integration so activity is attributable, the minimum permissions the workflow needs, the script fetching its own credential at runtime, re-runnability so a partial failure can be repeated, backoff on 429, a dry-run mode, a rollback path, and never writing a token or a secret into a log. --- ## Why read the target's event log as well as the vault's? *Two records of the same event, and the finding is usually in the gap between them.* **Industry term:** Windows Security log / event forwarding **In the app:** `/target-events` A Windows server has no idea that privileged access management exists. It records that DOMAIN\Administrator logged on from an address at a time. It does not know which human borrowed that identity, under what approval, for what stated reason — the vault holds that half, and neither log is complete on its own. The events worth knowing by heart are small in number. 4624 a logon succeeded, with the account, source address and logon type. 4625 a logon failed, with a status code saying why. 4672 that logon holds special privileges — the event that marks a session as administrative, and the efficient filter when you want privileged activity rather than all activity. Then 4740 a lockout, 4724 a password reset by somebody else, 4728 a group membership change, 1102 the log was cleared. Correlation is the actual skill. A 4624 with a matching vault retrieval is routine privileged work. A 4624 with no matching retrieval is a credential the vault never handed out — either obtained outside the platform, or reached by a network path that bypasses the session manager. That finding does not exist in either log alone, and it is the headline detection in privileged threat analytics for exactly that reason. The same logic runs the other way. A repeating 4625 from one host after a rotation is the stale dependency nobody mapped — a service, a scheduled task or an application pool still authenticating with the old password. A 4740 names the caller computer in the event, which is what you must fix before reconciling, or the lockout cycle simply restarts. The sentence that finishes the answer: an event ID is only evidence if the audit policy producing it was enabled, the log was large enough not to have wrapped, and the events were forwarded somewhere they survive the host. Before saying something did not happen, confirm you would have seen it if it had. --- ## How do the components interact? *The portal brokers people, the CPM manages credentials, the gateway brokers connections, the Vault holds truth.* **Industry term:** Vault + PVWA + CPM + PSM **In the app:** `/concepts` A user authenticates to the portal and asks for an account. The portal checks role permissions and safe membership, and if policy requires it, routes the request to an approver. Once authorised, the session gateway asks the Vault for the credential, injects it into a connection to the target, and records everything that follows. The user never sees the password. When the session ends, the credential manager may rotate the credential immediately, so the value that was briefly in memory becomes worthless. Every step in that chain writes to the audit trail, and the risk engine reads the trail back to score accounts, sessions and users. # Glossary > 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. 219 terms. Where a vendor uses a different name for the same thing, the definition says so. ## Security and identity — the discipline the platform belongs to - **PAM** (Privileged Access Management) — The discipline of securing, controlling and auditing accounts that hold elevated rights over systems and data. One of the three pillars of IAM, alongside IGA and AM. - **IAM** (Identity and Access Management) — The umbrella discipline, usually split three ways: IGA for the identity lifecycle, AM for authenticating ordinary users, and PAM for privileged credentials. At a bank each is normally a separate team, and PAM is a subset of IAM rather than a synonym for it. - **AM** (Access Management) — The authentication pillar: single sign-on, multi-factor, federation over SAML and OIDC, adaptive or risk-based access, and session management for ordinary users. AM decides whether you are who you say you are; PAM decides what you may do once you hold elevated rights. PAM SIM does not simulate AM — there is no sign-in at all, and the identity switcher is a demo convenience rather than authentication. - **IGA** (Identity Governance and Administration) — The lifecycle pillar: joiners, movers and leavers, provisioning and deprovisioning, access review campaigns, recertification and segregation-of-duties rules. IGA decides whether an identity should have access at all, and asks again periodically. A leaver process that fails to strip safe membership is an IGA failure that surfaces on the privileged side. - **SSO** (Single sign-on) — Authenticating once and reaching many applications without re-entering credentials. An AM function. Relevant to privileged access because the portal itself usually sits behind it — so an SSO outage stops privileged work even though the vault is healthy. - **MFA** (Multi-factor authentication) — Requiring more than one kind of evidence — something known, held or inherent. Delivered by AM rather than by the PAM platform, though privileged access policy commonly requires it and can refuse identities that have not enrolled. - **Federation** — Trusting another organisation's or service's authentication rather than holding your own credential for the user, carried over SAML or OIDC. It is how a workforce identity provider signs users into the privileged portal, and the same mechanism a CI pipeline uses to authenticate a workload without a stored secret. - **JIT** (Just-in-time access) — Granting privilege only for the moment it is needed and removing it automatically afterwards. - **ZSP** (Zero Standing Privileges) — A model in which no identity holds privileged entitlements at rest; all privilege is granted dynamically and expires. - **TEA** (Time, Entitlements, Approvals) — The three variables that bound a dynamic privilege grant: how long, over what, and authorised by whom. - **Least privilege** — Granting an identity the minimum rights required to perform its function, and no more. - **Standing privilege** — Permanent membership of a privileged group — convenient, and the main enabler of lateral movement after a compromise. - **Golden ticket** — A Kerberos ticket-granting ticket forged with the krbtgt account's key, letting an attacker mint credentials for any identity in the domain. Remediation is to reset krbtgt twice with replication allowed to finish in between — one reset leaves the previous key valid. - **Pass-the-hash** — Authenticating with a stolen NTLM hash without ever knowing the password. Over-pass-the-hash extends it by exchanging the hash for a Kerberos ticket, which is how a single compromised host becomes domain-wide access. - **Lateral movement** — Using access on one system to reach another, typically with credentials found in memory on the first. Rotating credentials and brokering sessions both exist to break this chain. - **Hardcoded credential** — A privileged password written into a config file, script or source repository. It never rotates, because rotating it breaks the application — so it is old, widely copied, and outside every control the vault provides. Removing these is what application credential management is for. - **Workload identity** — Proving what a non-human consumer is without giving it a secret first. The platform vouches: Kubernetes signs a service-account token, AWS confirms which role signed a request, an OIDC provider signs a token for one pipeline run. This is the answer to the bootstrapping problem. - **SIEM integration** — Forwarding privileged events and detections to the enterprise SIEM. The division of labour: the analytics component understands privileged context and detects, the SIEM correlates that with endpoint and network evidence. - **SoD** (Segregation of duties) — The requirement that no single person can both request and authorise the same privileged access. The control that makes dual control meaningful rather than procedural. - **Risk score** — A numeric summary of exposure, computed here from privilege level, password age, usage, session anomalies and policy violations. - **RBAC** (Role-Based Access Control) — Assigning permissions to roles and roles to users, rather than granting permissions to individuals directly. - **Session risk score** — A 1–100 score for a session or an individual command: 70–100 High, 30–69 Medium, 0–29 Low. A session takes the score of its riskiest activity. - **Tier 0** — The class of assets whose compromise means the whole environment is compromised: domain controllers, the identity provider, backup infrastructure, hypervisors — and the vault itself. Tier 0 systems are administered only from equally trusted hosts, which is why a privileged access workstation exists. - **4624** (An account was successfully logged on) — The Windows Security event recording a successful authentication, with the account, source address and logon type. What a brokered session produces on the target — and what it is missing is the point: the target sees the shared administrative identity, not the person. A 4624 with no matching vault retrieval is privileged access that bypassed the vault. - **4625** (An account failed to log on) — A failed authentication, carrying a status code that says why: bad password, disabled account, expired password. After a rotation, a repeating 4625 from one host is how you find the stale dependency nobody mapped. - **4672** (Special privileges assigned to new logon) — Written when a logon holds sensitive privileges such as SeDebugPrivilege or SeBackupPrivilege. It pairs with the 4624 immediately before it, and it is the efficient filter when you want administrative logons rather than all logons. - **4740** (A user account was locked out) — The lockout event, written on the domain controller that processed it. The caller computer name is the field that matters — it names the host still authenticating with the old password, which is what you must fix before reconciling, or the lockout cycle simply restarts. - **4724** (An attempt was made to reset an account's password) — A password reset performed by another account rather than changed by the account itself. What a CPM change or reconcile looks like from the target's side — and a 4724 against a managed account with no matching CPM job means someone reset it outside the platform and the vault is now out of sync. - **4728** (A member was added to a security-enabled global group) — Group membership changed; 4732 is the local-group equivalent and 4756 the universal one. This is how privilege is actually granted in Active Directory and how it quietly accumulates. An unexpected addition to Domain Admins is an incident until proven otherwise. - **4688** (A new process has been created) — Process creation, with the parent process and — where command-line auditing is enabled — the full command line. What turns 'someone had an administrative session' into 'here is what they ran'. Off by default, so its absence is a common gap between what an investigation needs and what exists. - **1102** (The audit log was cleared) — Somebody cleared the Security log. It cannot be suppressed and is written even when the rest of the log is gone. Close to self-evidently malicious on a production server — and much less effective than the person doing it expects, if sessions are recorded and logs are forwarded off-host. - **Logon type** — The field on a logon event saying how the authentication happened: 2 interactive at the console, 3 network (a service or a remote share), 10 RemoteInteractive (RDP). It is what separates a person at a keyboard from a service account authenticating in the background. - **Kerberos** — The default Windows domain authentication protocol. A domain controller issues a ticket-granting ticket at logon, which is exchanged for service tickets to reach individual services. PAM cares because the tickets and the signing keys are exactly what the well-known attacks steal. - **TGT** (Ticket-granting ticket) — The Kerberos ticket issued at logon and exchanged for service tickets. Forging one with the krbtgt key is the golden ticket attack, which is why krbtgt is the single most sensitive password in a domain. - **Kerberoasting** — Requesting a service ticket for an account with an SPN and cracking it offline. It needs no special privilege, so it is one of the first things an attacker with any domain foothold tries. Long random passwords, group managed service accounts and vaulting are the answers. - **NTLM** — The legacy Windows authentication protocol, still present as a fallback. Relay- and hash-replay-prone, which is what makes pass-the-hash possible. Where NTLM still fires, that exposure is live — so finding out where it is still used is a real piece of work. - **DCSync** — Abusing directory replication rights to ask a domain controller for password hashes, including krbtgt, without ever touching the box. It looks like legitimate replication traffic, which is why the detection is about who is asking rather than what is being asked. - **Silver ticket** — A forged service ticket signed with a single service account's key, granting access to that one service. Quieter than a golden ticket because it never contacts a domain controller — and correspondingly harder to spot. - **CIA triad** (Confidentiality, integrity, availability) — Prevent unauthorised disclosure, prevent unauthorised modification, keep systems and data there when needed. Privileged access mostly defends the first two — and the disaster recovery vault exists because the platform is itself an availability dependency. - **Tokenization** — Replacing a sensitive value with a non-sensitive stand-in mapped elsewhere. Together with masking — hiding part of a value for display — it shrinks where real data lives, and with it the scope an auditor has to test. - **Hashing** — A one-way transformation with no decryption, which is what separates it from encryption. Salting adds unique random data before hashing so identical passwords do not produce identical hashes and precomputed tables do not work. - **Encryption at rest** — Protecting stored data, as opposed to encryption in transit, which protects data crossing a network over TLS. Name both when asked how data is protected — answering with only one is the tell. - **PEDM** (Privilege Elevation and Delegation Management) — The category name for elevating specific actions rather than granting standing administrative rights. Vaulting protects shared credentials; this is what handles the everyday local-administrator problem. - **Authentication** — Establishing who you are. Distinct from authorisation, which is what you may do once that is settled. Signing in to the privileged portal is authentication; being permitted to reach the Windows production safe is authorisation — and naming which one a failure belongs to is half of diagnosing it. - **Authorisation** — Deciding what an authenticated identity may do. In privileged access it is expressed twice over: the role decides what kind of action is possible at all, and safe membership decides which resources it applies to. Both must permit. - **Phishing resistance** — The dividing line between factors, and it is not the form factor. Push and one-time codes are phishable: a relay proxy captures and replays them in real time, and a push approval carries no information about where the request came from. A hardware one-time-password fob is hardware and still phishable. Number matching mitigates blind approval without binding to origin. - **MFA fatigue** — Repeated push prompts until the user approves one out of irritation. Mitigated by number matching, rate-limiting prompts and alerting on repeated denials — and solved, for privileged identities, by moving them to phishing-resistant factors entirely. - **ABAC** (Attribute-Based Access Control) — Deciding access from attributes of the identity, resource, environment or context rather than from role alone. In practice enterprises combine the two: the role sets a baseline and context such as device, location, sensitivity or time modifies the final decision. - **Zero Trust** — Never trusting an identity merely because it is inside the corporate network: every access is authenticated and authorised on identity, context and policy. NIST SP 800-207 explicitly rejects implicit trust based on network location. - **Device posture** — What the endpoint attests about itself — disk encryption, patch level, endpoint agent present, certificate, domain membership — used alongside identity to grade access. It is a point-in-time attestation from the endpoint, so it complements controls on the target rather than replacing them. - **PASM** (Privileged Account and Session Management) — The vault half of the category: storing credentials, rotating them, and brokering, isolating and recording sessions. Most programmes that call themselves privileged access management are only this, which leaves the endpoint problem untouched. - **Enterprise Access Model** — The successor to the three-tier administration model, organising access by control plane, management plane and data plane across cloud and on-premises rather than by server tier. Same principle — credentials do not flow downwards — with a scope that includes the cloud control plane. - **ESAE** (Enhanced Security Administrative Environment) — The retired hardened-forest design, commonly called the red forest. It protected directory administration well and did nothing for the cloud control plane, which is where the most valuable access now sits — which is why it was retired and why knowing that distinguishes recent knowledge from knowledge learned once. - **LSASS** (Local Security Authority Subsystem Service) — The Windows process holding credential material in memory, and therefore the target of credential-dumping tools. Session brokering exists partly because of this: if the secret never reaches the user's endpoint, there is nothing on that endpoint to harvest. - **TGS** (Ticket Granting Service) — The Kerberos service that issues tickets for individual services once you hold a ticket-granting ticket. A ticket it issues for an account with a service principal name is what gets attacked offline in Kerberoasting. - **AS-REP roasting** — Attacking accounts that have Kerberos pre-authentication disabled: the authentication service response can be requested without credentials and cracked offline. The fix is to stop disabling pre-authentication, which is usually a legacy accommodation nobody revisited. - **NTLM relay** — Capturing a legacy authentication attempt and replaying it against another service rather than cracking it. Why finding where the legacy protocol still fires is real work rather than housekeeping. - **Pass-the-ticket** — Reusing a stolen Kerberos ticket rather than a password or hash. The sibling of pass-the-hash, and the reason session brokering matters — a ticket cannot be stolen from an endpoint that never held one. - **MITRE ATT&CK** — The public catalogue of adversary tactics and techniques. Useful for mapping an answer — credential access and lateral movement are the two tactics privileged access controls exist to interrupt — and best used to sharpen a point rather than as decoration. - **PBAC** (Policy-Based Access Control) — Deciding access from centrally expressed policy rather than from roles or raw attributes, so the rule lives in one reviewable place. The third model alongside role-based and attribute-based control, and the one that scales when the other two collide. ## Components — the moving parts of the platform and the estate around it - **SAML** (Security Assertion Markup Language) — The older of the two federation standards, XML-based, still dominant for enterprise workforce single sign-on. An AM concern rather than a PAM one, but the portal's own login usually depends on it. - **OIDC** (OpenID Connect) — The modern federation standard, built on OAuth 2.0 and issuing signed JSON tokens. Worth knowing on the privileged side too: it is how a CI pipeline proves what it is to a secrets manager without holding any credential. - **Vault** — Hardened, encrypted repository that stores privileged credentials and enforces authorisation and audit on every access. - **EPV** (Enterprise Password Vault) — The vault component itself. Runs on a hardened, single-purpose server with its own firewall and proprietary protocol, deliberately not domain-joined — so compromising the domain does not compromise the vault. Usually paired with a DR vault replicating from it. - **Server key** — The key protecting the vault's own key hierarchy, held outside the database. Without it the database files decrypt to nothing, which is why backup of the database alone is not a usable copy of the vault. - **PVWA** (Password Vault Web Access) — The web portal through which users search for accounts, request access, retrieve credentials and launch sessions. - **CPM** (Central Policy Manager) — The component that automatically changes, verifies and reconciles privileged credentials according to platform policy. - **PSM** (Privileged Session Manager) — A gateway that brokers privileged connections so they can be isolated from the endpoint, monitored live and recorded. Runs on Windows and is reached over RDP on 3389. - **PSMP** (Privileged Session Manager for SSH) — The SSH counterpart to the PSM, covering SSH, SCP, SFTP and Rsync. A transparent proxy rather than a jump server, so the native ssh client still works — you connect as ssh user@target-account#target-host@psmp-host. Runs on Linux, reached on port 22, and supports SSH key authentication. - **PTA** (Privileged Threat Analytics) — The analytics component that turns privileged activity into named detections — suspected credential theft, PSM bypass, golden ticket, over-pass-the-hash, unmanaged privileged account, irregular hours or source, excessive access. It combines vault records, session activity and directory telemetry, and can rotate a credential automatically on a severe detection. - **AAM** (Application Access Manager) — The answer to hardcoded credentials in application code and scripts. The application asks for its secret at runtime and is authenticated by its own properties — path, hash, OS user — rather than holding a password in a config file. - **CCP** (Central Credential Provider) — The agentless form of application credential retrieval: the application calls a REST endpoint instead of running a local provider. Useful where an agent cannot be installed — containers, appliances, hosts rebuilt from an image — at the cost of a network dependency on the retrieval path and identity that rests on a client certificate rather than process inspection. - **CP** (Credential Provider) — The agent form: installed on the application server, called locally, and able to inspect the calling process directly — OS user, executable path, executable hash. It caches, so a retrieval does not depend on the network being up, which is why it suits anything that must start during an outage. - **Secrets manager** — The consumer model for workloads rather than people or classic applications. Identity is borrowed from the platform, and secrets may be minted per request with an expiry rather than stored and rotated. Complements the vault rather than replacing it — a target that cannot mint credentials on demand stays static. - **authn-jwt** (JWT authenticator) — Authenticating a workload with a signed OIDC token. The issuer claim is the trust anchor, the subject identifies the workload — for a pipeline, the repository and branch — and the audience stops a token minted for one service being replayed against another. - **authn-k8s** (Kubernetes authenticator) — Identity from the pod's service-account token, checked against namespace, service account and cluster. The token is mounted by the kubelet and signed by the cluster, so nothing had to be distributed for it to work. - **Secretless** — An injection pattern where the application never receives the secret at all: a broker holds the credential, opens the connection, and the application talks to a local socket. There is nothing to leak, log or commit — the strongest answer to credentials appearing in stack traces and repositories. - **ISPSS** (Identity Security Platform Shared Services) — The unified multi-service portal model in which privileged access, identity administration, audit and intelligence are delivered as one platform. - **SIA** (Secure Infrastructure Access) — The component providing agentless, ZSP-oriented access to cloud and infrastructure targets. The Access space is the surface built on it — the two are not alternatives. - **Access space** — The part of the platform people use to reach assets, organised by target rather than by credential. Covers both vaulted and just-in-time access. - **DR Vault** (Disaster recovery vault) — A replica of the vault kept for failover. It matters more than it sounds: privileged access is an availability dependency, so losing the vault mid-incident makes every other recovery harder. Untested failover is the finding — the day you need it is the wrong day to discover the replica has been lagging for months. - **Vault protocol** — The vault's own proprietary protocol on TCP 1858. Naming the port is a small signal that the connectivity check you describe is a real one rather than a recited list. - **WEF** (Windows Event Forwarding) — Native collection of selected events from many hosts to a collector. Why it matters to privileged access: evidence that lives only on the host does not survive the host, and clearing a local log is an anti-forensic move that forwarding defeats. - **LDAP** (Lightweight Directory Access Protocol) — Directory lookups on 389, or 636 for the TLS-protected form, LDAPS. The vault, the identity provider and the network access layer all lean on the directory, which is why a directory problem shows up first as three unrelated-looking failures. - **REST API** — The programmatic interface to the platform, exposed through the web portal's application. Everything done by hand in the portal — creating accounts, safes and members, triggering rotations, extracting evidence — can be done through it, which is what makes onboarding at scale and scheduled reporting possible. - **SIEM** (Security Information and Event Management) — Centralised collection of security logs, with correlation, alerting, investigation and historical search. Splunk, Microsoft Sentinel and QRadar are the names to recognise. Privileged events are forwarded there for two reasons: correlation with endpoint and network telemetry, and retention beyond what the platform holds natively. - **CEF** (Common Event Format) — A structured log format widely used to ship security events into a SIEM, usually over syslog. What 'forward the vault events to Splunk' concretely means. - **DLP** (Data Loss Prevention) — Controls detecting and preventing sensitive information leaving approved environments — email, cloud storage, removable media, web uploads and the endpoint itself. Adjacent to privileged access rather than part of it, and expected knowledge for a role with 'data security' in the title. - **EPM** (Endpoint Privilege Manager) — Removes standing local administrator rights from workstations and elevates per application instead, with application control and credential-theft protection alongside. The endpoint half of privileged access — the problem vaulting alone never touches. - **Conjur** — The secrets manager for containers and pipelines: policy as code, machine identity, and short-lived secrets fetched at runtime instead of held statically. Named separately from the vault because the model differs — identity is borrowed from the platform, and many secrets are minted per request. - **Privilege Cloud** — The hosted deployment model, as opposed to self-hosted. It removes the vault infrastructure, high-availability and upgrade burden, and in exchange gives up control over upgrade timing, network placement and data residency — which regulated banks often want and sometimes need. - **OAuth 2.0** — Delegated authorisation: it issues an access token letting an application act on a resource on your behalf. It is not an identity protocol, and the classic mistake is using it alone for login — an access token proves access was granted, not who the person is. Relevant to privileged access because newer deployments accept it for API authentication. - **SCIM** (System for Cross-domain Identity Management) — The provisioning standard: pushing identity and group lifecycle between systems, deprovisioning included. Preferred over just-in-time provisioning wherever an application supports it, precisely because it covers the removal half. - **FIDO2** — Public-key authentication where the private key never leaves the device and the credential is bound to the origin, so it will not sign for a lookalike domain. That origin binding is what makes it genuinely phishing-resistant rather than merely strong, and it is why privileged populations are moved to it first. - **PingID** — A multi-factor service common in banks, partly because its federation component can run on-premises and hybrid. Methods span mobile push, time-based codes, FIDO2 keys and biometrics, desktop login, RADIUS for legacy infrastructure, and SMS and voice — which rank last, because of SIM swap and interception. - **RADIUS** — The protocol by which multi-factor authentication gets in front of legacy infrastructure — VPN concentrators, network devices — that cannot speak modern federation. The standard answer to "how do you put MFA in front of an old VPN?". - **Entra ID** — Microsoft's cloud identity service, named alongside privileged access tooling in most bank stacks. The chain worth holding: directory roles, resource-level access control, Conditional Access, MFA, privileged identity management, service principals and managed identities, then the sign-in and audit logs. - **PIM** (Privileged Identity Management) — Time-bound, eligible-rather-than-active assignment of cloud administrative roles, with activation optionally requiring justification, approval and multi-factor. The cloud expression of reducing standing privilege — and a complement to governance, not a substitute for it. - **ZTNA** (Zero Trust Network Access) — Brokering a user to one specific application rather than placing them on a network. Connectors beside the application dial outward, so there is no inbound rule and nothing internet-facing to scan — which removes by design the lateral movement a VPN grants by design. - **PACLI** (Privileged Account Command Line Interface) — The scripting interface to the vault, older than the REST API and still present. Where you meet it in practice is legacy automation somebody wrote years ago that nobody has migrated. - **ASCP** (Application Server Credential Provider) — The third form of application credential retrieval, plugging into Java application servers so a connection pool obtains its credential from the vault rather than from a datasource configuration file. Named alongside the agent and agentless providers because the three cover different deployment shapes. - **PAReplicate** — The vault's backup utility. Backup is a dedicated tool rather than a file copy, because the encrypted store is not something you preserve by copying a directory — and a copy without the server key decrypts to nothing regardless. - **PARestore** — The vault's restore utility, and the half people never exercise. A backup that has never been restored is a belief; the recovery path is the control, not the backup job. - **Distributed vault** — A satellite vault serving a geographically separate part of the estate, so credential retrieval does not cross a continent to complete. Distinct from a disaster recovery replica, which exists for failover rather than for locality. - **Password Upload Utility** — The bulk-import tool for onboarding accounts from a file. One of three routes alongside manual onboarding and the API — and at any real scale, onboarding rules plus the API is the only sustainable choice. - **CIEM** (Cloud Infrastructure Entitlement Management) — Managing permission sprawl in cloud estates, where the unit of privilege is a role that can be assumed rather than an account with a password. The fourth part of the category alongside account and session management, endpoint elevation, and secrets management. - **ITDR** (Identity Threat Detection and Response) — Detecting and responding to attacks on the identity infrastructure itself — the directory, the identity provider, the tokens — rather than on endpoints or networks. The analytics end of the maturity arc. - **DSPM** (Data Security Posture Management) — Discovering and classifying sensitive data at rest so access decisions have something factual behind them. Adjacent to privileged access rather than part of it, and expected vocabulary for a role with data security in the title. - **CI/CD** (Continuous Integration and Continuous Delivery) — The build and deployment pipelines that hold their own privileged secrets — deployment credentials, registry tokens, cloud roles. A pipeline is a privileged identity, and treating it as infrastructure rather than as an identity is how secrets end up in build logs. - **PAW** (Privileged Access Workstation) — A hardened, single-purpose machine used only for administration — no email, no general browsing — so Tier 0 credentials are never typed on a machine exposed to the usual initial-access routes. Also written SAW, for secure admin workstation. - **Jump host** — A controlled intermediate machine through which administrative sessions to a target estate are made, so the target is not reachable directly. A session gateway is a jump host with credential injection and recording built in — which is why brokering and tiering are the same argument rather than two. - **WebAuthn** (Web Authentication) — The browser-facing half of the modern authentication standard, paired with the client-to-authenticator protocol that talks to the device. Together they are what makes a security key origin-bound and therefore phishing-resistant. - **U2F** (Universal 2nd Factor) — The earlier second-factor standard that preceded the current one. Still supported by most keys, and worth recognising as the ancestor rather than a competitor. - **OATH** (Initiative for Open Authentication) — The body behind the open one-time-password algorithms, which is why tokens from different vendors interoperate. Not to be confused with OAuth, which is a delegated authorisation protocol and entirely unrelated — the near-collision of names is itself a small interview hazard. - **TOTP** (Time-based One-Time Password) — A rotating code derived from a shared seed and the current time, which is why clock drift matters. Stronger than a code delivered by message and still phishable, because a relay can capture and replay it inside its validity window. - **HOTP** (HMAC-based One-Time Password) — The counter-based sibling of the time-based algorithm: the code advances when used rather than with the clock. Its failure mode is counter desynchronisation rather than clock drift. - **SecurID** — The classic hardware one-time-password fob. A seed record shared at manufacture, a rotating code, and a passcode formed from a PIN plus that code. The operational details that come up are clock drift and next-tokencode mode — and that despite being hardware, it is still phishable. - **PIV** (Personal Identity Verification) — The certificate-based smart card standard, with the defence equivalent known as the common access card. The card holds the private key and a PIN unlocks it, and it brings a full certificate lifecycle with it — issuance, renewal, revocation, and a certificate authority that is itself Tier 0. - **SASE** (Secure Access Service Edge) — The convergence of networking and security delivered from the cloud rather than from appliances in a data centre. Appears constantly in job descriptions, so being unable to expand it is a small avoidable stumble. - **SSE** (Security Service Edge) — The security half of that convergence on its own: secure web gateway, cloud application broker, zero trust network access and data loss prevention. The distinction from the full convergence is that this half omits the networking. - **SWG** (Secure Web Gateway) — The proxy that filters and inspects outbound web traffic — URL filtering, encrypted traffic inspection, sandboxing. The outbound counterpart to zero trust access, which handles inbound to private applications. - **CASB** (Cloud Access Security Broker) — Visibility and control over how cloud applications are used, including what data leaves through them. Often delivered as part of the outbound gateway rather than as a separate product. - **App Connector** — The component deployed beside a private application that dials outward to the access service. Because both sides dial out and are stitched together in the middle, there is no listening port and nothing inbound to allow — and what a connector can reach defines what can be published, making its placement an access-control decision. ## Objects — the things the platform manages - **Safe** — Logical container inside the Vault that groups accounts and carries the permission grants for them. - **Account** — A managed privileged credential, identified by username, target address and platform. - **AppID** (Application identity) — The registered identity an application presents when asking for a credential. On its own it is only a claim; the authentication rules attached to it are what turn the claim into proof. - **Application dependency** — Something that will break when a credential rotates. In this simulator an application registration is a dependency: before rotating a service account, you check what is provisioned against it. - **Lease** — The record of an issued dynamic secret and its expiry. The unit of management: you do not rotate a dynamic secret, you let its lease expire — and to contain an incident you revoke it, because there is no stored value to change. - **Safe member** — A user granted a specific permission level on a safe: Use, Manage, Approve, Audit or Full. - **Service account** — A non-human account used by an application or service, typically with a long-lived password and wide dependencies — a classic rotation challenge. - **Reconciliation account** — A highly privileged account used solely to reset other credentials that have drifted out of sync with the Vault. - **Password version** — A previous value of a managed credential, kept so a failed change can be rolled back, history depth enforced, and an investigator can establish which value was live when. - **Temporary version** — The intermediate value a reconcile sets with the reconciliation account before settling on the final one. Usually hidden from the version list. - **Logon account** — A second account used to open the door when the managed account cannot log in to change its own password — common on Unix, where the target account may not be permitted to SSH in directly. It establishes the session; the managed account's password is then changed inside it. Distinct from a reconciliation account, which is for recovery rather than routine change. - **SPN** (Service principal name) — The identifier that maps a service to the account running it, so clients can request a ticket for it. A service account with an SPN is Kerberoastable: any domain user can request a ticket encrypted with that account's password and attack it offline — which makes service-account password strength a real control, not a formality. - **gMSA** (Group managed service account) — A service account whose password Active Directory generates and rotates by itself, with authorised hosts retrieving it as needed. The modern answer to the service-account problem where the application supports it — no dependency mapping, because nothing is holding a copy. - **Privileged group** — Domain Admins, Enterprise Admins, Schema Admins, the local Administrators group and the operator groups. Membership must be minimal, monitored and alerted on. Nesting is where privilege accumulates unnoticed — a shadow administrator is usually two group memberships deep. - **Bearer token** — The session token returned by authentication and sent in the Authorization header on every subsequent call. Anyone holding it is the caller, which is why it belongs in memory rather than in a log, a config file or a URL. - **krbtgt** — The account whose key signs every Kerberos ticket in a domain, and therefore the most sensitive password in it. Compromise yields a golden ticket. Remediation is to reset it twice with replication allowed to complete in between — one reset leaves the previous key valid. - **SYSDBA** — Oracle's highest database privilege, able to start, stop and recover the instance and to act regardless of ordinary permissions. One of the privileged account classes people forget to inventory because it is not in the directory. - **sa** (system administrator) — SQL Server's built-in administrative login. Frequently shared, frequently ancient, and frequently the account an application connects with — which makes it a rotation dependency problem as much as a privilege problem. - **root** — The Unix superuser, which bypasses permission checks entirely. Often cannot log in directly by policy, which is exactly why a logon account exists for changing its password. - **sudo** (superuser do) — Delegated, command-level elevation on Unix — the native form of privilege elevation rather than credential vaulting. Its configuration is where over-broad grants hide, because a rule permitting a shell is a rule permitting everything. ## Workflows — the sequences people and the platform perform - **Change** — A CPM job that replaces a privileged password with a new policy-compliant random value and stores it in the Vault. - **Verify** — A CPM job that confirms the password held in the Vault still authenticates against the target, detecting drift. - **Reconcile** — A CPM job that uses a separate privileged reconciliation account to forcibly reset a credential that is out of sync with the Vault. - **Dual control** — A requirement that a second authorised person confirms a request before privileged access is granted. - **Break glass** — Emergency access to a last-resort privileged account, wrapped in compensating controls such as mandatory recording and automatic post-use rotation. - **Discovery** — Scanning targets and directories for privileged accounts that are not yet under management. What it finds is the gap between the accounts you know about and the accounts that actually exist. - **Dynamic secret** — A credential generated when it is requested and destroyed when its lease ends: a short-lived STS token, a database user created with the right grants and dropped afterwards. Nothing exists between uses, so there is no rotation to schedule and nothing standing for an attacker to find. - **Policy as code** — Defining workloads, secrets and grants declaratively in version control rather than through a console. Access changes become reviewable commits, the estate is diffable, and rebuilding an environment is a load rather than an afternoon of clicking. - **Vault synchronisation** — Replicating static secrets between the vault and the secrets manager so one credential has one source of truth across the classic and cloud-native estates. Without it the same password drifts in two places. - **Session recording** — Capture of a privileged session as a replayable and searchable timeline of commands, window activity and statements. - **Onboarding** — Bringing a discovered privileged account under vault management: assigning it to a safe and a platform, and taking over its credential. - **Credential retrieval** — The audited act of obtaining a privileged secret from the Vault. In mature deployments it is replaced by session brokering so the human never sees the value. - **Vaulted access** — A stored, long-lived credential is injected into the connection. The control surface is the vault: rotation, approval, recording. - **JIT access** (Just-in-time access) — No standing credential exists; an entitlement is created for the session and removed when it ends. There is nothing to rotate and nothing to steal in between. - **Request Timeframe** — The explicit from/to window a requester asks for, rather than only a duration — so access can be requested ahead of a scheduled change. - **Multiple access** — A request option allowing repeated connections within the approved window, as opposed to a single one-time connection. - **Monitor** — Opening a copy of a live session to watch it or take co-control. Distinct from suspend and terminate: it observes rather than intervenes, and the owner is notified. - **Onboarding rule** — A rule that automatically brings discovered accounts matching stated criteria under management, assigning safe and platform without a human doing it one at a time. At any real scale, rules plus the API are the only workable route. - **Account lockout** — Locked, expired and disabled are three different states with three different fixes. Locked means too many bad passwords — find the source before unlocking, or you restart the cycle. Expired means the password aged out. Disabled means somebody turned it off, and why matters before you turn it back on. - **400** (Bad Request) — The request itself is wrong: malformed JSON, a missing required field, an invalid value, a filter the API cannot parse. Nothing on the server will change this, so retrying unchanged is pointless. Compare the payload against the schema field by field. - **401** (Unauthorized) — Authentication failed, or the token is missing, expired or invalid. You never got in. Do not troubleshoot safe permissions on a 401 — that is the mistake this status exists to catch, and it costs the first twenty minutes of an incident. - **403** (Forbidden) — Authenticated and not authorised: the caller lacks the vault authority or safe permission the endpoint requires. Regenerating the token achieves nothing, because the token was fine. And do not fix it by making the automation identity an administrator. - **404** (Not Found) — The endpoint or the object does not exist — or it exists and is invisible to this caller, which in a permission-scoped API looks identical. If an administrator can see the object and you cannot, it is a visibility problem wearing a 404. - **409** (Conflict) — A well-formed request the current state refuses, usually a duplicate. For a re-runnable onboarding script this is a success case, not a failure — and generating a new name to get past it is how estates end up with svc-app01, svc-app01-2 and svc-app01-new. - **429** (Too Many Requests) — Throttling. Bulk jobs reach it long before anything else breaks. Back off exponentially and honour Retry-After; retrying immediately extends the window you are being throttled in. - **5xx** (Server error) — A server-side failure that nothing in your request will fix. Correlate the timestamp with the component and server logs, retry with bounded backoff, and stop — a component that is already failing does not need your loop on top of it. - **Idempotency** — The property that running an operation twice leaves the same result as running it once. It is what makes a bulk onboarding script safe to re-run after a partial failure, and the reason a 409 on create should usually be treated as success. - **Pagination** — Returning results in pages with a cursor or offset rather than all at once. The difference between a script that works on a demo estate and one that works on forty thousand accounts — a caller that reads the first page and stops silently reports a fraction of the truth. - **Test of design** — Would this control work if it ran? Answered by inspecting configuration: safe permissions, Master Policy settings, platform rotation schedules. A design failure is rare and severe, because everything downstream of it is invalid. - **Test of operating effectiveness** — Did the control actually operate throughout the period? Answered by sampling, sized to how often the control runs: rotation logs across the year, a recording for a selected session, sign-offs for each quarterly review. The common finding is a control that passes design and fails here — the policy was right, and rotation had been failing on thirty accounts for four months. - **Access review** — Periodic recertification: does everyone who can reach a privileged credential still need to? Deliberately boring work whose value is what it catches — leavers who still hold membership, people who moved teams two years ago, and temporary grants nobody removed. It depends entirely on being able to enumerate the population. - **Change control** — Privileged changes ride an approved, scheduled, validated and evidenced process. Emergency access is a designed exception with alarms, tickets and post-use review — never an undocumented bypass. The distinction is what keeps break glass from quietly becoming routine. - **SPL** (Search Processing Language) — Splunk's query language. The working set is search, stats, tstats, where, eval, bin, dedup, table and sort. Prefer statistical aggregation to transaction where you can; tstats is the faster route over indexed fields and accelerated data models. - **Clock skew** — Disagreement between the clocks on the systems you are correlating. It matters more than it sounds: one skewed source can invert a timeline and make the response look like the cause. Normalise to UTC and verify before drawing conclusions from ordering. - **Incident response lifecycle** — Preparation, detection and identification, containment, eradication, recovery, lessons learned. For a privileged credential the middle expands: contain access, preserve evidence before cleaning anything, rotate or reconcile, review sessions and authentication activity, determine scope, remediate, monitor for recurrence. - **Vendor access** — Third-party privileged access without a VPN or an agent on their device. A common real requirement and a frequent audit finding, because the default answer in most estates is a shared account somebody emailed. - **JIT provisioning** — An application creating a user's account at their first successful single sign-on, from attributes in the assertion. Convenient, and it only ever creates — nothing tells the application somebody has left, so the account stays. That hits two audit controls at once: termination timeliness, and the access review you cannot run on a population you cannot enumerate. Do not confuse it with JIT elevation, which grants temporary privilege; provisioning creates lasting access, elevation grants temporary access. - **STAR** (Situation, Task, Action, Result) — The structure behind a competency answer. Worth extending with two more beats for a security role: the risks you considered and mitigated, and how you validated or communicated the outcome. That extension is what separates a story from evidence of judgement. - **Upgrade order** — Vault first, then the portal, then the credential manager, then the session managers, with cross-component version compatibility checked. Validate behaviourally afterwards — run a rotation to completion and open a brokered session. An upgrade that leaves rotation silently failing is worse than no upgrade, because nothing alerts. - **JML** (Joiner, Mover, Leaver) — The identity lifecycle, and the governance pillar's core process. The leaver half is the one that produces findings: access that should have been removed and was not shows up on the privileged side as membership of a safe nobody withdrew. - **Log streaming** — Pushing access-service events into the enterprise security monitoring platform. Those logs are evidence: who reached which application, when, from what device — the network half of the record that the vault's audit trail completes. ## Policy — the rules above the workflows - **Connection component** — The driver that actually establishes a brokered session for a given protocol — PSM-RDP, PSM-SSH, PSM-WinSCP, PSM-SQLPlus and so on. A platform lists the ones its accounts may use, which is what makes a policy executable rather than aspirational. - **Platform** — Policy template that defines password complexity, rotation intervals, verification, reconciliation, connection method and session rules for a class of accounts. - **TTL** (Time to live) — How long an issued credential remains valid. Short enough that a leaked value is stale before it is useful, long enough that the workload is not re-authenticating constantly. A max TTL caps how far a renewal can extend it. - **Compliance status** — Whether an account currently satisfies its platform policy, principally the password change and verification intervals. - **Master Policy** — The organisation-wide rules that sit above every platform: require dual control, enforce exclusive access, one-time passwords, demand a reason or a ticket, mandate session recording. Exceptions are granted per platform — which is why 'make this one system stricter' is usually a platform exception rather than a new safe. - **Exclusive access** — Check-out and check-in: only one person may hold a credential at a time, and it rotates on check-in. This is what turns a shared administrative account into an individually attributable one, and it is close to mandatory on shared privileged accounts in a bank. - **One-time password** — A credential rotated immediately after a single use, so the value a person saw is dead before they could reuse it. The strongest form of exclusive access, and the reason a retrieval does not become a standing credential. - **Use without Retrieve** — The safe permission combination that lets someone connect through the session manager without ever seeing the password. The goal state for most users, and one of the fastest ways to demonstrate you have actually administered a vault rather than read about one. - **Audit policy** — The Windows settings that decide which security events are recorded at all. Advanced audit policy subcategories are the modern form. The nuance worth saying out loud: an event ID only helps if the policy producing it was enabled and the log retained — 'we were not recording that' and 'it did not happen' produce identical empty searches. - **Group Policy** — How password policy, lockout thresholds, audit policy and user rights actually reach machines. When an account behaves differently on one host, a Group Policy scoping difference is the standard suspect. - **Rate limiting** — The server refusing calls beyond a rate, answering 429. Any automation touching thousands of objects needs backoff and paging designed in from the start, because discovering this in production looks exactly like an outage. - **SOX** (Sarbanes-Oxley Act) — The US law behind financial-reporting controls. Section 404 is the one that reaches IT: management and auditors must assess the controls over financial reporting, and the systems that hold financial data inherit that scrutiny. In a bank, privileged access is not a security preference — it is the control set behind an audit domain. - **ITGC** (IT General Controls) — The control domains an IT audit is grouped into by convention: Access to Programs and Data, Program Changes, Program Development, and Computer Operations. Worth phrasing as audit practice rather than statute — the law does not legislate the domains. - **Access to Programs and Data** — The ITGC domain privileged access lives in. Its controls: authorised provisioning with approval, periodic access review and recertification, termination timeliness, segregation of duties, privileged and generic account management, authentication configuration, and logging of privileged activity. Privileged access is the highest-risk slice, because one account can alter financial data and its own audit trail. - **IPE** (Information Produced by the Entity) — Any report you hand an auditor is itself evidence whose completeness and accuracy you must be able to prove. A screenshot with no provenance is not evidence. Keep the source system, the query or report logic, the parameters, the timestamp and the reconciliation alongside the output. - **Termination timeliness** — The control that access is removed within a defined window of somebody leaving. Measured, sampled and commonly failed. It is an IGA responsibility that surfaces on the privileged side as membership of a safe that should have been stripped. - **Control deficiency** — The first rung of the ladder: a control that does not operate as intended. It escalates to a significant deficiency and then to a material weakness according to the likelihood and potential magnitude of a misstatement. Remediation fixes the deficiency going forward — it does not by itself reclassify what already happened. - **Material weakness** — The top of the deficiency ladder: a reasonable possibility that a material misstatement would not be prevented or detected in time. Effective compensating controls can lower where a gap lands, which is why they are documented in advance rather than discovered during the assessment. - **Compensating control** — A different control reducing the same risk to an acceptable level where the intended one cannot be implemented — an application that cannot rotate, compensated by exclusive access, brokered sessions, tighter monitoring and alerting on every use, recorded as accepted risk with a named owner and a review date. - **Preventive control** — Stops the bad thing happening: vaulting, rotation, dual control, Use without Retrieve, session isolation, MFA. The auditor's question is 'could it have happened?'. - **Detective control** — Finds it afterwards, fast enough to matter: session recording, analytics detections, SIEM correlation, access reviews, reconciliation reports. The auditor's question is 'would you have known?'. - **PCI DSS** (Payment Card Industry Data Security Standard) — The card-data standard. Requirements 7 and 8 are the privileged access ones — restricting access by business need to know, and identifying and authenticating every user, including the rule that shared and generic accounts must be individually attributable. That last one is exactly what exclusive access delivers. - **GLBA** (Gramm-Leach-Bliley Act) — The US financial privacy law. Section 501(b) reaches banks through the Interagency Guidelines Establishing Information Security Standards, enforced by the banking agencies — not through the FTC Safeguards Rule, which covers non-bank financial institutions. Getting that distinction right is a small credibility marker in a bank interview. - **FFIEC** (Federal Financial Institutions Examination Council) — Publishes the IT Examination Handbook that US bank examiners work from, including risk-based layered security and authentication commensurate with risk. Its Cybersecurity Assessment Tool was sunset on 31 August 2025, so cite that as history rather than as current practice. - **OCC** (Office of the Comptroller of the Currency) — The regulator of national banks, whose heightened standards set governance and risk-management expectations for large institutions. Relevant because it is one of the bodies whose examiners ask to see the evidence a privileged access programme produces. - **NIST SP 800-53** — The US federal control catalogue, and the vocabulary most control language borrows from. AC-6 is the least-privilege family — including the requirement to log the use of privileged functions — and the AU family covers audit and accountability. - **Data classification** — Public, internal, confidential, personal, financial. It drives which controls apply, and an access decision made without it is a guess. Pairs with ownership: somebody has to answer for the data and approve access to it. - **Step-up authentication** — Challenging again at the moment of privilege — retrieving a Tier 0 credential, launching an administrative session — with a stronger factor than the one used at login, not a repeat of it. The principle: a sensitive operation deserves its own gate, not just the front door. - **Adaptive authentication** — Policy evaluating signals — geovelocity, address reputation, new device, network zone, device posture — and stepping challenges up or waiving them accordingly, so friction is proportional to risk. For privileged identities, set a floor rather than letting a low risk score waive the challenge. - **Bypass code** — A temporary credential issued when somebody cannot use their enrolled factor. A legitimate necessity and a standing risk, so it needs single use, short expiry, alerting on issue and use, out-of-band identity verification before issuing, and review of who uses them — repeat users mean the process has become a workaround. - **Conditional Access** — The policy engine evaluating signals and deciding whether access is granted, blocked or challenged. The sign-in log exposes which policy applied and why — which is where you look when a privileged user says multi-factor is blocking them, rather than reaching for an exclusion. - **AAL** (Authenticator Assurance Level) — How strongly the authenticator proves possession, on a three-level scale. The top level effectively requires a hardware authenticator, which is the standards-based way to justify buying security keys for privileged users. Its companions are identity assurance, for how strongly the person was proofed, and federation assurance, for how strongly an assertion is protected. - **COSO** (Committee of Sponsoring Organizations of the Treadway Commission) — The internal-control framework financial-reporting controls are assessed against. Worth recognising as the framework behind the audit rather than something you work with directly. - **PCAOB** (Public Company Accounting Oversight Board) — The body regulating the external auditors of public companies, and therefore the reason those auditors test what they test and how. When an audit approach seems oddly specific, this is usually why. - **CIS Controls** (Center for Internet Security Controls) — A prioritised set of safeguards, of which account management and access control management are the two that bear directly on privileged access. The same body publishes the hardening benchmarks estates are measured against. # What each part of PAM SIM is called in the industry > 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. PAM SIM names its screens plainly. A real deployment names them differently, and an interview will use the industry name. This is the translation, and it is the fastest way to check whether an answer is using the vocabulary a practitioner would recognise. | In PAM SIM | Industry term | What it is | Route | | --- | --- | --- | --- | | The whole simulator | PAM — one of the three IAM pillars | IGA governs the identity lifecycle, AM authenticates ordinary users (SSO, MFA, federation), PAM governs privileged credentials. Only the third is simulated here. | `/concepts` | | Secure Vault | Credential vault / EPV | Encrypted repository holding every privileged credential, with a layered key hierarchy. | `/vault` | | Access Portal | PVWA | Web front door where users search accounts, request access and launch sessions. | `/portal` | | Credential Management | CPM | Automated change, verify and reconcile of privileged credentials. | `/cpm` | | Session Manager | PSM | Gateway that brokers, isolates, monitors and records privileged sessions. | `/sessions` | | SSH session brokering | PSMP / PSM for SSH | The same brokering for SSH, SCP, SFTP and Rsync, as a transparent proxy so the native ssh client still works. A separate component on Linux, reached on port 22. | `/platforms` | | Security Events | PTA (Privileged Threat Analytics) | Named detections over privileged activity — credential theft, PSM bypass, golden ticket, unmanaged accounts — with automatic credential rotation on the severe ones. | `/alerts` | | Application Access | AAM / Credential Provider / CCP | Applications retrieve credentials at runtime instead of holding them in config files. The provider authenticates the application by host, OS user, executable path and hash, or client certificate. | `/applications` | | Secrets Manager | Conjur / Secrets Manager | Cloud-native consumers. Identity comes from the platform (Kubernetes, IAM, OIDC) and many secrets are minted per request with a TTL, so the unit of management is a lease rather than a password. | `/secrets` | | Leases | Dynamic secret leases | A credential issued on demand that expires on its own. Revoking the lease is the containment action, because there is no stored value to change. | `/secrets?tab=leases` | | View as policy | Policy as code | The workload and secret registry expressed declaratively, reviewed in version control rather than clicked together. | `/secrets` | | REST API | PVWA REST API | The automation surface. The status code names the layer that failed: 401 authentication, 403 authorisation, 400 the request, 404 the object, 409 the state, 429 throttling, 5xx the server. | `/rest-api` | | Target Event Log | Windows Security log | What the target recorded — 4624, 4625, 4672 and the rest — against what the vault recorded. A privileged logon with no matching retrieval is the finding neither log shows on its own. | `/target-events` | | Policies | Master Policy | Organisation-wide rules above every platform: dual control, exclusive access, one-time passwords, reason or ticket required, session recording. Exceptions are granted per platform. | `/policies` | | Safe | Safe | Logical container grouping accounts and carrying the permission grants. | `/safes` | | Platform | Platform | Policy template defining how a class of accounts is managed and connected to. | `/platforms` | | Privileged Account | Account | A managed credential: username + target address + platform. | `/accounts` | | Access Request | Dual control access workflow | Justified, time-limited request that a second person must confirm. | `/portal` | | Incoming Requests | Incoming Requests | The approver's queue of requests awaiting authorization. | `/requests/incoming` | | My Requests | My Requests | The requester's view of their own pending and decided requests. | `/requests/mine` | | Session Recording | PSM recording | Replayable, risk-scored timeline of everything done in a session. | `/recordings` | | Rotation job | CPM change / verify / reconcile | A unit of credential work executed against a target system. | `/cpm` | | Risk Center | Identity Security Intelligence | Behavioural and posture risk scoring over accounts, sessions and users. | `/risk` | | Audit | Audit service | Complete, attributable record of privileged actions across the platform. | `/audit` | | Roles | Identity Administration roles | Role-based permission sets governing what each identity may do. | `/roles` | | Break Glass workflow | Emergency / break glass access | Last-resort access with mandatory recording and automatic post-use rotation. | `/portal` | | Time-limited grant | JIT access / Zero Standing Privileges | Privilege that exists only for an approved window and expires by itself. | `/portal` | | Spaces and services | Navigator / service picker | The platform is split into spaces — Privileged Access, Access, Audit and Reports, Intelligence — switched from the header. | — | | Access space | Access space (built on SIA) | Where people go to reach a target, whether by a vaulted credential or a just-in-time entitlement. | `/access/infrastructure` | | Platform Sessions view | Audit and Reports › Sessions | Cross-service session record with Service and Access method columns, distinct from Privileged Access Monitoring. | `/platform-sessions` | | Versions tab | Account Versions | Every value the CPM has set on a target, including the temporary ones a reconcile leaves behind. | `/accounts` | | Saved views | Saved and Recent views | A named search on the accounts list. Favorites is the default filter rather than the full inventory. | `/accounts` | | Monitor session | Monitor | Open a copy of a live session to watch it or take co-control — the fourth action beside suspend, resume and terminate. | `/sessions` | # Risk scoring and threat detection > 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. ## How risk is scored Risk here is additive and explainable rather than a black box: 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. Every point of a score can be traced to the factor that contributed it. That is a deliberate teaching choice — a score nobody can explain is a score nobody acts on. ### Account risk bands | Band | Range | What to do about it | | --- | --- | --- | | Low | 0–39 | Within policy. Routine monitoring only. | | Medium | 40–59 | Watch. Usually an ageing credential or rising usage. | | High | 60–79 | Act this week. Rotate, tighten membership, or review sessions. | | Critical | 80–100 | Act now. Highly privileged, non-compliant or showing anomalous activity. | ### Session risk bands | Band | Range | What to do about it | | --- | --- | --- | | High risk | 70–100 | Review now. Contains activity that would concern a security team on its own. | | Medium risk | 30–69 | Worth a look. Elevated activity, or an unusual time or target. | | Low risk | 0–29 | Routine. Sampled during periodic review rather than investigated. | ## The detection catalogue Each of these is raised against real activity in the simulator rather than scripted, so the signal and the evidence stay consistent with each other. ### Suspected credential theft **Signal.** Session activity consistent with harvesting credential material — reading the SAM or LSASS, copying a registry hive, dumping the NTDS database — or a privileged authentication with no matching vault retrieval. **Why it matters.** The vault knows every credential it handed out. A privileged logon it cannot account for means the credential came from somewhere else, which is the definition of theft rather than use. **Response.** Rotate the credential immediately so what was taken is already worthless, terminate the session, and preserve the recording as evidence before anything is cleaned up. **Automatic remediation.** Available — the platform can rotate the affected credential without waiting for a human, on the reasoning that a credential changed within seconds of a theft signal is already worthless to whoever took it. ### PSM bypass / suspicious password change **Signal.** A privileged account authenticating directly against a target, or its password changing on the target, without the session gateway or the credential manager being involved. **Why it matters.** The whole control model assumes the gateway is the only path. A connection that avoided it is either a misconfiguration that leaves a blind spot, or someone deliberately working around the recording. **Response.** Establish whether a direct network path exists that should not, and close it. An account that can be reached around the gateway is not really under management. **Automatic remediation.** None. This one needs a decision before an action. ### Golden ticket **Signal.** A Kerberos ticket-granting ticket with anomalous properties — an implausible lifetime, a missing or forged PAC, encryption that does not match the domain's configuration. **Why it matters.** It means the krbtgt account's hash is compromised, so an attacker can mint tickets for any identity in the domain. It is the most severe finding in an Active Directory environment. **Response.** Reset the krbtgt password twice, deliberately, with replication allowed to complete in between — one reset alone leaves the previous key valid. **Automatic remediation.** None. This one needs a decision before an action. ### Over-pass-the-hash **Signal.** A Kerberos ticket requested using an NTLM hash rather than an interactive logon, often surfacing as authentication from a host the identity has never used. **Why it matters.** It shows a stolen hash being upgraded into full Kerberos access — the lateral movement step between compromising one machine and reaching the domain. **Response.** Rotate the affected credential, isolate the source host, and check where else that identity authenticated in the same window. **Automatic remediation.** Available — the platform can rotate the affected credential without waiting for a human, on the reasoning that a credential changed within seconds of a theft signal is already worthless to whoever took it. ### Unmanaged privileged account **Signal.** An account with privileged rights on a target that does not exist in any safe. **Why it matters.** It is privilege with no rotation, no approval and no recording. These accumulate quietly through project work and are the usual gap between what a compliance report claims and what is actually true. **Response.** Onboard it, or prove it is not needed and remove it. Discovery finds these; the work is deciding which of the two applies. **Automatic remediation.** None. This one needs a decision before an action. ### Access at irregular hours **Signal.** Privileged use well outside the pattern established for that identity or that account. **Why it matters.** Weak on its own and valuable in combination. Attackers work when nobody is watching, so this is the signal that turns a low-severity finding into an investigation. **Response.** Correlate with a change record. Legitimate out-of-hours work almost always has one; if it does not, ask the person directly. **Automatic remediation.** None. This one needs a decision before an action. ### Access from an irregular source **Signal.** A privileged connection from an address, subnet or geography the identity has not used before. **Why it matters.** Privileged work usually comes from a small, stable set of admin workstations. A new source is either a change nobody recorded or an account being used by someone else. **Response.** Confirm the source is an approved administrative host. If it is not, treat the credential as exposed. **Automatic remediation.** None. This one needs a decision before an action. ### Excessive access requests **Signal.** One identity raising far more requests, across more safes, than its peers or its own history. **Why it matters.** Either someone is doing work they should not be doing, or an entitlement is genuinely missing and they are compensating with requests. Both are worth knowing, and the second is the more common. **Response.** Review what was requested against the role. The fix is often an entitlement change, not an investigation. **Automatic remediation.** None. This one needs a decision before an action. ### Policy violation **Signal.** Activity that breaches a stated control — a session without required recording, an approval that bypassed dual control, MFA absent where policy demands it. **Why it matters.** These are the findings an auditor will ask about by name, because each is a control that was defined and then not enforced. **Response.** Close the gap in configuration rather than in process. A control that depends on people remembering is not a control. **Automatic remediation.** None. This one needs a decision before an action. ### Compliance drift **Signal.** Credentials past their change interval, verification failing, rotation failing repeatedly. **Why it matters.** Not an attack, and still the finding most likely to fail an audit. A password that has not changed in 118 days against a 60-day policy is a control that has stopped working. **Response.** Diagnose the cause before rotating. A repeatedly failing rotation is usually a permission or dependency problem that reconciliation fixes, and rotating blindly will just fail again. **Automatic remediation.** Available — the platform can rotate the affected credential without waiting for a human, on the reasoning that a credential changed within seconds of a theft signal is already worthless to whoever took it. # Guided walkthroughs > 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. 30 walkthroughs of the running application, one document each. Within a track they are ordered by the study material's own priority ranking: work through the *essential* ones first. ## Foundations Architecture, where PAM sits inside IAM, the vault, safes and platforms. | Guide | Priority | Minutes | Goal | Read it | | --- | --- | --- | --- | --- | | Find your way around | essential | 9 | Learn the shape of a privileged access platform: which component does what, where PAM sits inside IAM, and what breaks when each piece is down. | https://pamsim.com/llms/guides/orientation.md | | The stack — where each piece sits | essential | 9 | Answer the opening question: how network access, multi-factor, the authenticator and privileged access fit together, and why they are not competing tools. | https://pamsim.com/llms/guides/the-stack.md | | Blast radius — why this discipline exists | essential | 11 | Walk an attack chain and say which control breaks which link, name every class of privileged account, and describe the complete control set. | https://pamsim.com/llms/guides/why-pam-exists.md | | Inside the Vault | essential | 10 | Understand the component everything else depends on: how it protects secrets, why it is Tier 0, what the server key means, and what you do on the day it is unavailable. | https://pamsim.com/llms/guides/vault-operations.md | | Tiering the administrative plane | high | 9 | Understand why a Tier 0 credential must never be typed on an ordinary workstation, and what the model that follows from that actually looks like. | https://pamsim.com/llms/guides/admin-tiering.md | | Authenticators and hard tokens | high | 10 | Rank the factors by what actually resists attack rather than by form factor, and handle the lifecycle question that produces audit findings. | https://pamsim.com/llms/guides/authenticators.md | | Zero trust network access, precisely | high | 10 | Separate the two products people both call "the VPN", explain why connectors mean no inbound rules, and say how this layers with privileged access. | https://pamsim.com/llms/guides/zero-trust-access.md | ## Operations Day-to-day running: rotation, requests, sessions, service accounts, and the troubleshooting that goes with them. | Guide | Priority | Minutes | Goal | Read it | | --- | --- | --- | --- | --- | | Discover and onboard an account | essential | 14 | Run the whole sequence a real onboarding follows — find privilege nobody is managing, decide what should happen to it, and take the ones that matter under management. | https://pamsim.com/llms/guides/onboard-account.md | | Design and run a safe | essential | 10 | Work the authorisation boundary end to end: why safes exist, how to structure them, how membership actually grants access, and what a safe looks like at review time. | https://pamsim.com/llms/guides/safe-design.md | | Platforms and the Master Policy | essential | 10 | Work the policy layer end to end: what a platform controls, how to tune one safely, and where organisation-wide rules and their exceptions actually live. | https://pamsim.com/llms/guides/platform-policy.md | | Verify, change, reconcile | essential | 9 | Run all three CPM job types and be able to say precisely what each one asks and when you would use it. | https://pamsim.com/llms/guides/verify-change-reconcile.md | | Troubleshoot a failed rotation | essential | 11 | Work the most common ticket in a PAM team using a systematic ladder rather than guesswork. | https://pamsim.com/llms/guides/failed-rotation.md | | The portal, end to end | essential | 10 | Follow one privileged access from search to expiry through the web front door, and understand why the portal being the only path is what makes every other control real. | https://pamsim.com/llms/guides/pvwa-portal.md | | A privileged session from click to recording | essential | 10 | Follow the session path end to end — what the gateway does, the three separate controls it provides, and what happens after the session closes. | https://pamsim.com/llms/guides/psm-session.md | | The password works but the session fails | essential | 8 | Diagnose the session path without touching the credential — and know why rotating would be the wrong move. | https://pamsim.com/llms/guides/session-troubleshooting.md | | Take a hardcoded credential out of an application | essential | 11 | Use the credential provider: register an application, understand how it is authenticated, diagnose a refusal, and know when a remediation is only half done. | https://pamsim.com/llms/guides/application-credentials.md | | Secrets for workloads, not people | high | 12 | Understand the cloud-native model: identity borrowed from the platform, secrets minted on demand with an expiry, and access defined as policy in version control. | https://pamsim.com/llms/guides/workload-secrets.md | | Service accounts and their dependencies | essential | 9 | Understand why a successful rotation can still cause an outage, and how to onboard a service account without one. | https://pamsim.com/llms/guides/service-accounts.md | | Use without Retrieve, and access triage | essential | 8 | Grant the right level of access, and diagnose the two complaints you will hear constantly: cannot see it, or can see it but cannot connect. | https://pamsim.com/llms/guides/permissions-triage.md | | Automate it, and read the status code | high | 12 | Work the REST interface end to end — authenticate, call, and produce every status code that matters — so 401 against 403 is something you have done rather than something you memorised. | https://pamsim.com/llms/guides/rest-api.md | | Reduce standing privilege without breaking the business | high | 10 | Run the programme play rather than the technical one: measure first, cut the safe tranche, make the replacement fast enough that nobody routes around it. | https://pamsim.com/llms/guides/reduce-standing-privilege.md | | Run the platform — upgrades, resilience and cost | high | 11 | Handle the half of the job that is not access engineering: keeping the platform available, upgrading it safely, and arguing for the budget to expand it. | https://pamsim.com/llms/guides/platform-operations.md | ## Investigation Reading the evidence: audit trails, session recordings, the target's own event log, and the detections raised over them. | Guide | Priority | Minutes | Goal | Read it | | --- | --- | --- | --- | --- | | Triage a PTA detection | essential | 10 | Work the Privileged Threat Analytics queue: know the named detections, tell an analytics finding from a workflow event, and take the right first action on each. | https://pamsim.com/llms/guides/pta-triage.md | | Review a suspicious session | high | 10 | Investigate recorded privileged activity and know the order of operations when a credential may be compromised. | https://pamsim.com/llms/guides/session-review.md | | Read the target's event log | essential | 11 | Work the other half of the record: the Windows Security events privileged activity produces, what each one means, and why the finding usually lives in the gap between the two logs. | https://pamsim.com/llms/guides/windows-events.md | ## Compliance Policy, access reviews, reporting, and the evidence an auditor actually asks for. | Guide | Priority | Minutes | Goal | Read it | | --- | --- | --- | --- | --- | | When an administrator leaves | essential | 10 | Walk the termination chain control by control, across all three identity pillars, and know the step almost everyone forgets. | https://pamsim.com/llms/guides/leaver-controls.md | | Maturity, metrics and the standards behind them | high | 10 | Frame a roadmap answer, quantify a programme with numbers an auditor and an executive both accept, and name which document each requirement comes from. | https://pamsim.com/llms/guides/maturity-and-metrics.md | | Pull the reports an audit asks for | essential | 10 | Run the reporting surface end to end: which report answers which question, how to generate and export one, and what has to travel with it for it to count as evidence. | https://pamsim.com/llms/guides/pull-reports.md | | Produce evidence for an audit | high | 9 | Answer what an auditor actually asks for, in the three layers they ask for it, and know why a screenshot is not evidence. | https://pamsim.com/llms/guides/sox-evidence.md | | Dual control and access approval | high | 8 | Work both halves of the approval workflow and understand where time-bound access fits the Zero Standing Privileges argument. | https://pamsim.com/llms/guides/dual-control.md | # Find your way around > 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. *Learn the shape of a privileged access platform: which component does what, where PAM sits inside IAM, and what breaks when each piece is down.* **Track:** Foundations **Priority:** essential **Time:** about 9 minutes **Topics:** Architecture, IAM, IGA, AM, Vault, PVWA, CPM, PSM **Walk it in the app:** https://pamsim.com/guides — guide id `orientation` ## The walkthrough A click-by-click walkthrough of the running application. Read as prose it still works: the steps carry the explanation, not just the navigation. ### Step 1 — Four components, one job *On page `/`.* Every architecture question comes back to four parts. The Vault stores credentials and enforces authorisation. The PVWA is the web portal people use. The CPM changes passwords automatically. The PSM brokers and records sessions. Learn to draw it: User → PVWA → PSM → target, with CPM ↔ Vault and CPM ↔ target running alongside. Being able to sketch that on a whiteboard in fifteen seconds is worth more than any definition. **What an interviewer is testing.** Expect “walk me through the architecture” early. Answer in the order store, access, manage, monitor — and say that only the Vault holds secrets. ### Step 2 — Where PAM sits inside IAM *On page `/`.* PAM is one of three pillars, and at a bank each is usually a separate team. IGA — Identity Governance and Administration — owns joiners, movers and leavers, provisioning, access reviews and segregation of duties. AM — Access Management — owns authentication for ordinary users: single sign-on, multi-factor, federation over SAML and OIDC, adaptive or risk-based access, and session management. PAM owns privileged credentials: the vault, rotation, session brokering and the recording. The line worth having ready: AM decides whether you are who you say you are. PAM decides what you may do once you hold elevated rights, and records it. IGA decides whether you should have had that access in the first place, and asks again every quarter. They meet constantly. You authenticate to the portal through AM, so an MFA outage stops privileged access even though nothing in PAM has failed. IGA's leaver process is what should strip safe membership — and when it does not, PAM is where the orphaned access shows up. **What an interviewer is testing.** “What is the difference between IAM and PAM?” is close to guaranteed, and it is really asking whether you know PAM is a subset. Answer with the three pillars and one concrete interaction between them. Saying “PAM is IAM for admins” is not wrong, but it is the answer of someone who has not worked next to an AM team. ### Step 3 — What this simulator does not cover *On page `/concepts`.* PAM SIM teaches the PAM pillar and does not simulate the other two. There is no identity provider here, no MFA challenge, no federation, no access review campaign — and there is no sign-in either, because a public demo that asks who you are before it shows you anything is a demo nobody opens. The identity switcher in the profile menu is a convenience, not authentication, and is documented as one. Know that boundary before an interview rather than during it. “I have hands-on privileged access and I have read about the access management side” is a respectable answer. Being caught improvising about a product you have never opened is not. **What an interviewer is testing.** If asked about SAML or Entra ID conditional access, say what you actually know and where the edge is. Interviewers ask precisely because the honest answer is rarer than the bluffed one. ### Step 4 — Spaces and services *On page `/`, element `header:spaces`.* The platform is not one product. Privileged Access administers credentials; Access is where people go to reach a target; Audit and Reports is the cross-service record; Identity Security Intelligence scores risk. Users and roles are administered in a separate Identity Administration service, not inside Privileged Access. That detail separates candidates who have used it from candidates who have read about it. **Do this.** Open the service picker and look at the spaces. Notice which services are listed but not simulated here. ### Step 5 — The Vault is Tier 0 *On page `/vault`.* Hardened, no standard OS services, not domain-joined, its own firewall, and a proprietary protocol on port 1858. Encryption is hierarchical: each object has its own key, protected by a safe key, then a vault key, then a server key held outside the database. If you are asked what happens when the server key is lost with no backup: the vault is unrecoverable. Say it plainly — that bluntness is the point of the question. **What an interviewer is testing.** Follow-up to expect: “where does the server key live?” Offline in physical custody or an HSM, with a documented chain of custody. And vault administrators are separate people from domain administrators. ### Step 6 — Safes are the unit of authorisation *On page `/safes`, element `nav:/safes`.* Permissions are granted on the safe, never on the individual account. That is what makes access control scale — a handful of container grants instead of an N-users × M-accounts matrix. A safe should map to one team's scope of duty. Common designs: by application, by business unit, or by platform team. **What an interviewer is testing.** Near-guaranteed: “Safe versus Platform?” Safe answers who may touch this credential. Platform answers how it is maintained. Never blur them. ### Step 7 — Platforms are the policy template *On page `/platforms`.* A platform defines rotation schedule, verification interval, complexity, connection components and CPM plugin behaviour. Accounts inherit all of it. When a system has unusual requirements you duplicate the closest platform and tune the copy. You never force an account onto a platform that does not match its technology. **Do this.** Click any platform to open its policy and read the change and verify intervals. ### Step 8 — Policy sits above platforms *On page `/policies`.* The organisation-wide rules — dual control, exclusive access, one-time passwords, mandatory reason, mandatory session recording — apply across the estate. A platform may tighten them but not weaken them. This is the Master Policy idea. To make one system stricter you add an exception on its platform; you do not create a new safe. Creating a safe changes who has access, which is a different question entirely. **What an interviewer is testing.** A favourite trap: “Team X needs stricter rules on these servers — what do you do?” The answer is a policy exception on the platform, not a new safe. ### Step 9 — The CPM does the work nobody sees *On page `/cpm`.* Three job types, and they answer three different questions. Verify asks whether the stored password still authenticates. Change asks the CPM to rotate the target and sync the new value. Reconcile asks a separately authorised identity to force a new known password when the stored one no longer works. Rotation triggers are platform-configurable: on a schedule, on check-in when exclusive access is released, on release after a session ends, or on demand after suspected exposure. **What an interviewer is testing.** Confusing change with reconcile is the single most common way to sound inexperienced. Change is routine. Reconcile is recovery — and drift always deserves an investigation, not just a fix. ### Step 10 — The PSM is three controls, not one *On page `/sessions`.* Isolation is preventive: the credential never lands on the user's endpoint. Recording is detective: video plus searchable command text. Live monitoring lets an administrator watch, suspend or terminate. Auditors test isolation and recording as two separate controls, so treat them as two separate answers. ### Step 11 — Where to go next *On page `/guides`.* That is the map. The operations walkthroughs take one task each and make you perform it — the nine-step onboarding, the CPM troubleshooting ladder, the session-failure checklist, service account dependencies. Do those in order, then use the Labs to test whether you actually retained it. ## What this prepares you to answer **Q. Walk me through the platform architecture.** Vault stores and enforces authorisation; PVWA is the web front door; CPM automates the credential lifecycle; PSM brokers, isolates and records sessions. Only the Vault holds secrets. Losing the CPM stops rotation but not access; losing the PSM stops brokered sessions but not the vault. **Q. What is the difference between IAM and PAM?** PAM is a subset of IAM. IAM splits into three pillars: IGA governs the lifecycle — joiners, movers, leavers, provisioning, access reviews and segregation of duties. AM handles authentication for ordinary users — single sign-on, MFA, federation over SAML and OIDC, adaptive access, session management. PAM governs privileged credentials — vaulting, rotation, session brokering and recording. AM decides whether you are who you say you are; PAM decides what you may do with elevated rights and records it; IGA decides whether you should have had the access at all. **Q. How do PAM and Access Management interact day to day?** You authenticate to the privileged portal through AM, so an MFA or federation outage stops privileged access even though nothing in PAM has failed — worth saying because it is a real incident pattern people miss. In the other direction, IGA's leaver process should strip safe membership, and PAM is where it shows up when it does not: a disabled identity still holding access is a joiners-movers-leavers failure surfaced by the privileged side. **Q. What is the difference between a Safe and a Platform?** A safe is the authorisation container — who may list, use, retrieve or manage these accounts. A platform is the policy template — rotation schedule, complexity, connection components, plugin behaviour. Different audience needing different access means another safe; different target technology means another platform. **Q. How is the Vault protected, and what if you lose the server key?** Tier 0: hardened host, no standard OS services, not domain-joined, own firewall, proprietary protocol, hierarchical encryption. High availability plus a tested DR replica, and vault admins separate from domain admins. Lose the server key with no backup and the vault is unrecoverable — it lives offline in physical custody or an HSM with a documented custody chain. **Q. Why use PSM instead of letting people retrieve passwords?** Retrieval puts the secret on the endpoint. Brokering keeps it in the platform, gives one control point for monitoring and recording, and makes rotation safe because nobody is holding a copy. Retrieval stays legitimate for specific workflows, gated by reason and ticket. # The stack — where each piece sits > 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. *Answer the opening question: how network access, multi-factor, the authenticator and privileged access fit together, and why they are not competing tools.* **Track:** Foundations **Priority:** essential **Time:** about 9 minutes **Topics:** Architecture, ZTNA, MFA, Authenticators, Defence in depth **Walk it in the app:** https://pamsim.com/guides — guide id `the-stack` ## The walkthrough A click-by-click walkthrough of the running application. Read as prose it still works: the steps carry the explanation, not just the navigation. ### Step 1 — Four products, four different questions *On page `/concepts`, element `concept:the-stack`.* This comes up early and it is testing whether you see these as alternatives. They are not. Each answers a different question in the same sentence, and the sentence only works with all four. Can you reach it? Are you really you? How strongly can you prove it? What can you do once you are in? **Do this.** Read the stack card. **What an interviewer is testing.** If a job description names four products, the first question is usually how they relate. Answering with four definitions is a miss; answering with one sentence that contains all four is the point. ### Step 2 — Can you reach it? *On page `/concepts`, element `concept:zero-trust-access`.* Network access brokers the connection. Zero trust access replaces the VPN: you are granted a path to one specific application, never placed on a network. Connectors beside the application dial outward, so there is nothing inbound to allow and nothing internet-facing to scan. The consequence that matters to privileged access: it removes by design the lateral movement a VPN grants by design. Blast radius shrinks before privilege is involved at all. **Do this.** Read the zero trust card. ### Step 3 — Are you really you? *On page `/concepts`, element `concept:ping-portfolio`.* The multi-factor service proves the human behind the credential, and raises or lowers friction according to risk signals — impossible travel, a new device, address reputation, device posture. It sits inside a larger portfolio, and the federation server underneath it is the component most likely to be in the login path of everything. Which is why an outage there stops privileged work while the vault is perfectly healthy — the incident pattern people miss. **Do this.** Read the portfolio card. ### Step 4 — How strongly can you prove it? *On page `/concepts`, element `concept:authenticators`.* The authenticator itself. A security key is phishing-resistant because the credential is bound to the origin and will not sign for a lookalike domain. A push notification is not, because approving it carries no information about where the request came from. That is why privileged users get hardware and everybody else gets an app. Not because hardware is inherently stronger — a one-time-password fob is hardware and still phishable — but because origin binding is the property that defeats the actual attack. **Do this.** Read the authenticator card. ### Step 5 — What can you do once you are in? *On page `/portal`, element `portal:search`.* Everything above got you to this page. From here the privileged access platform takes over: the credential is vaulted, rotated, brokered through a recorded session, and never handed to you. Notice what the first three layers cannot do. They can prove who you are and control what you reach — they have no opinion at all about what you then do as an administrator, or any record of it. That gap is the entire reason this fourth layer exists. ### Step 6 — Where the evidence is produced *On page `/sessions`, element `sessions:table`.* And the last clause of the sentence: with audit evidence produced at every step. Network access logs who reached which application from what device. The identity layer logs which factor was used and which policy applied. This layer logs which named person borrowed which shared identity, under which approval, and what they did with it. An auditor asking about administrative access will want all three. Being the person who knows which system holds which half is worth more than knowing any one of them deeply. ### Step 7 — The sentence, and why each layer fails safe *On page `/concepts`, element `concept:the-stack`.* Network access decides whether you reach the system, the factor and the token prove who you are, and privileged access management controls what you can do as an administrator once you are there — with audit evidence produced at every step. Defence in depth means each layer fails safe rather than failing open. Stolen credentials alone do not get an attacker to the jump host, because they also need an enrolled identity and a device that passes posture. An enrolled identity on a compliant device still cannot use the administrative account without going through the vault. And if all of that is defeated, the session was recorded. **What an interviewer is testing.** Deliver the sentence, then name one cross-layer failure — a federation outage stopping privileged access while the vault is healthy. That second part is what shows you have operated it rather than drawn it. ## What this prepares you to answer **Q. How do these products fit together?** Each answers a different question. Network access decides whether you can reach the system at all, brokering you to one application rather than putting you on a network. The multi-factor service proves the human behind the credential. The authenticator decides how strongly — a security key is origin-bound and phishing-resistant, a push is not. And privileged access management controls what you can do as an administrator once you are there: vaulted, rotated, brokered through a recorded session. With audit evidence at every step. Defence in depth, where each layer fails safe. **Q. Why is a hardware token not automatically the strongest option?** Because phishing resistance is the dividing line, not the form factor. A one-time-password fob is hardware and still phishable — a relay captures and replays the code inside its validity window. A security key resists phishing because the private key never leaves the device and the credential is bound to the origin, so it will not sign for a lookalike domain. Number matching on push helps against blind approval but does not bind to origin. **Q. How do zero trust network access and privileged access complement each other?** They control different halves of the sentence. Network access decides whether you can reach the administrative plane at all — per application, with identity and posture as inputs, exposing nothing inbound — so it shrinks blast radius before privilege is involved. Privileged access decides what you may do once there: vaulted credential, brokered and recorded session, time-boxed elevation, evidence. Layered, stolen credentials alone are not enough; the attacker also needs an enrolled identity and a device that passes posture. **Q. What is the difference between OAuth and OIDC?** OAuth 2.0 is delegated authorisation — it issues an access token letting an application act on a resource on your behalf. OpenID Connect is a thin identity layer on top that adds an ID token telling you who the user is. The classic mistake is using OAuth alone for login: an access token proves access was granted, not who the person is. Relevant on the privileged side too, because newer deployments accept OAuth for API authentication and OIDC is how a pipeline proves what it is to a secrets manager without holding a credential. **Q. Which layer would you fix first in an estate with all four deployed badly?** Discovery, because it is the denominator for everything else — you cannot prioritise an estate you have not inventoried. Then the privileged layer's coverage, because it is the one with the largest blast radius per failure. But say what would change that: if administrative access is still over a VPN with no per-application brokering, closing that removes lateral movement wholesale and is often the cheaper win. # Blast radius — why this discipline exists > 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. *Walk an attack chain and say which control breaks which link, name every class of privileged account, and describe the complete control set.* **Track:** Foundations **Priority:** essential **Time:** about 11 minutes **Topics:** Attack chain, Lateral movement, Taxonomy, Control set, PASM, PEDM **Walk it in the app:** https://pamsim.com/guides — guide id `why-pam-exists` ## The walkthrough A click-by-click walkthrough of the running application. Read as prose it still works: the steps carry the explanation, not just the navigation. ### Step 1 — Not password hygiene *On page `/concepts`, element `concept:blast-radius`.* The framing that separates a good answer from a textbook one: this is blast-radius containment. One compromised administrator credential allows lateral movement, data theft, configuration changes, new accounts, and the disabling of the controls that would have caught any of it. So the answer to "why does this matter" is never "passwords should be rotated". It is what one credential can reach, and what it can erase on the way out. **Do this.** Read the blast radius card. ### Step 2 — Walk the chain, name the control *On page `/concepts`, element `concept:blast-radius`.* Initial access, credential theft, lateral movement, privilege escalation, domain dominance, persistence. Being able to recite that is table stakes; being able to say which control breaks which link is the answer. Vaulting removes the shared secret people know. Rotation makes a stolen credential expire on its own. Brokering keeps the secret off the endpoint so it cannot be harvested from memory. Recording makes what happened reconstructable. Just-in-time elevation removes the standing membership that made escalation worth attempting in the first place. **What an interviewer is testing.** The named techniques are worth recognising — pass-the-hash, pass-the-ticket, Kerberoasting, AS-REP roasting, directory replication abuse, golden and silver tickets, relay, token impersonation, harvesting from process memory. Recognising them is enough; reciting the whole catalogue unprompted is not. ### Step 3 — The techniques, defined *On page `/glossary`.* Search the glossary for the ones you are least sure of. Kerberoasting needs no privilege at all, which is why it is one of the first things tried. A golden ticket means the key that signs every ticket is compromised. Directory replication abuse pulls hashes without touching a domain controller interactively. The point of knowing them is not trivia. Each one tells you which control would have stopped it, and that is the shape of a good answer. **Do this.** Search for Kerberoasting, DCSync and Silver ticket. ### Step 4 — The taxonomy, and why forgetting a class matters *On page `/accounts`, element `accounts:filters`.* Filter by account type. Each class here has its own failure mode: a domain administrator is a blast-radius problem, a service account is a dependency problem, a break-glass account is a governance problem. The classes that get forgotten are the ones that hurt. Hypervisor and backup-system accounts are effectively Tier 0 — whoever holds the backups holds the data — and are routinely left out. SSH keys are usually the largest unmanaged population in an estate. API keys, tokens, certificates and pipeline secrets belong on the list too. **Do this.** Filter the account list by type and see how many classes exist. ### Step 5 — Non-human identity outnumbers human identity *On page `/secrets`, element `secrets:filters`.* This is the sentence that lands, and it is not rhetoric: there are more machine identities than people in a modern estate, and they are the harder half of the job. People can be asked to justify themselves. A container cannot. It is also why the discipline extends past the vault. A workload that appears and disappears faster than any rotation schedule needs a different model, and pretending otherwise is how pipeline secrets end up in source control. ### Step 6 — The complete control set *On page `/concepts`, element `concept:blast-radius`.* What a mature programme actually deploys, and worth being able to list: vaulting; rotation with verification and reconciliation; enforced uniqueness and complexity; credential injection so no human sees the secret; session proxying, isolation, recording, live monitoring and termination; just-in-time elevation, ephemeral credentials and zero standing privilege; approval workflows, dual control and time-boxed access; endpoint least privilege and application control; discovery and automated onboarding; secrets management for applications and pipelines; threat analytics; and tamper-evident audit trails. Reading that list, notice how much of it is not the vault. That is the point of the next step. ### Step 7 — Most "PAM" is only a quarter of PAM *On page `/concepts`, element `concept:blast-radius`.* The analyst-firm split is into four: account and session management, privilege elevation and delegation on endpoints, secrets management for applications and pipelines, and cloud entitlement management. Most programmes that call themselves privileged access management are only the first. That leaves standing local administrator rights on every workstation untouched — and the workstation is where credential theft usually starts. Saying that out loud reframes you from someone who operates a vault to someone who understands the category. **What an interviewer is testing.** "What is the difference between account-and-session management and privilege elevation?" — the first is the vault side: store, rotate, broker, record. The second is the endpoint side: remove standing local admin and elevate per application instead. ### Step 8 — Which is what the risk score is trying to express *On page `/risk`.* The scoring here is an attempt to rank blast radius: what the account can do, how stale its credential is, how often it is used, whether its sessions have looked anomalous, and what policy it is breaching. A risk score nobody can decompose is a number nobody acts on. The useful question is never whether this is an 82 or a 74 — it is which of these five things you fix first. ## What this prepares you to answer **Q. What is PAM and why does it matter?** It protects, controls, monitors and audits access to privileged accounts so credentials cannot be stolen, shared or abused. It matters because of blast radius: one compromised administrator credential allows lateral movement, data theft, creation of new accounts, and disabling of the controls that would catch all of that. So we vault the credentials, rotate them, broker and record the sessions, and keep evidence of every use. **Q. Walk me through an attack chain and where PAM breaks it.** Initial access, credential theft, lateral movement, privilege escalation, domain dominance, persistence. Vaulting removes the shared secret people know. Rotation makes a stolen credential expire by itself. Brokering keeps the secret off the endpoint so it cannot be harvested from memory. Recording makes the activity reconstructable. Just-in-time elevation removes the standing group membership that made escalation worth attempting. **Q. What classes of privileged account would you inventory?** Local, domain, enterprise and schema administrators; service and application accounts including hardcoded credentials; break-glass and shared accounts; Unix root and sudo; database privileged accounts; network device enable accounts; hypervisor and backup-system accounts, which are effectively Tier 0 and routinely forgotten; SSH keys, usually the largest unmanaged population; API keys, tokens and certificates; pipeline secrets; and cloud privileged identities with their entitlement sprawl. Non-human identity now outnumbers human identity, which is the hardest part. **Q. What is the difference between PASM and PEDM?** The two halves of the category. Account and session management is the vault side — store credentials, rotate them, broker, isolate and record sessions. Privilege elevation and delegation is the endpoint side — remove standing local administrator rights and elevate per application or command, with application control. Most programmes calling themselves PAM are only the first, which leaves the workstation problem untouched, and the workstation is where credential theft usually starts. # Inside the Vault > 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. *Understand the component everything else depends on: how it protects secrets, why it is Tier 0, what the server key means, and what you do on the day it is unavailable.* **Track:** Foundations **Priority:** essential **Time:** about 10 minutes **Topics:** Vault, EPV, Encryption, Tier 0, DR, Availability **Walk it in the app:** https://pamsim.com/guides — guide id `vault-operations` ## The walkthrough A click-by-click walkthrough of the running application. Read as prose it still works: the steps carry the explanation, not just the navigation. ### Step 1 — What the vault actually is *On page `/vault`.* Not a database with a password column. The vault is a hardened, single-purpose server: no standard operating system services, its own firewall, deliberately not joined to the domain, reached only through a proprietary protocol on TCP 1858. The not-domain-joined part is the one worth saying out loud. If the vault were a domain member, compromising the domain would compromise the vault — and the vault is what you need in order to recover from a compromised domain. Its independence is the whole design. **What an interviewer is testing.** "Tell me about the vault" is checking whether you know it is an appliance-like Tier 0 asset rather than a piece of software you install on a file server. ### Step 2 — The key hierarchy *On page `/vault`, element `vault:encryption`.* Every stored object is encrypted with its own key. Those object keys are protected by a safe key. The safe keys are protected by a vault key. And the vault key is protected by a server key that lives outside the database entirely. The consequence is the point: a stolen copy of the database decrypts to nothing. Backup of the data files alone is not a usable copy of the vault, which is a thing people discover at the worst possible moment. **Do this.** Read the encryption panel, and note where the server key is said to be held. ### Step 3 — The server key question *On page `/vault`, element `vault:encryption`.* Lose the server key with no backup and the vault is unrecoverable. Say that plainly in an interview, because it is precisely what the question is testing — a candidate who hedges here has not thought about it. Which is why the key lives offline in physical custody or in a hardware security module, with a documented chain of custody and a recovery procedure that has actually been rehearsed. **What an interviewer is testing.** Two things worth adding unprompted: server-key backup and DR failover testing are the first two things you would verify in an environment you had just inherited. ### Step 4 — Health, and what silence means *On page `/vault`, element `vault:health`.* Each component reports its own state. The failure that matters here is not the loud one — it is a credential manager that has quietly stopped, because nothing breaks visibly. Access still works, sessions still broker, and passwords simply stop rotating. Four months later that is an audit finding covering every account the component was responsible for. Operational monitoring of the platform is therefore a control, not just hygiene. **Do this.** Check each component's state and read what the detail line says about it. ### Step 5 — Replication and the recovery path *On page `/vault`, element `vault:replication`.* A vault is only as available as its recovery path. The standard architecture is a high-availability pair plus a disaster recovery replica in a second site, with the replication lag monitored. The finding auditors and examiners actually raise is untested failover. A replica that has never been promoted is a belief, not a control — and the day you need it is the wrong day to discover the last three months of replication silently failed. **Do this.** Look at the replication targets and how current each one is. ### Step 6 — Nothing enters or leaves unaudited *On page `/vault`, element `vault:activity`.* This is what separates a vault from storage. Every retrieval is an authenticated identity, an authorisation check against the safe, and an audit record — and refusals are recorded just as carefully as successes. Retrieval is the single most important event in the trail, because it is the moment a human gained the ability to act as a privileged identity. It is also the event you want to see less of over time, as brokered sessions replace it. **Do this.** Read the recent credential activity, including any denied entries. ### Step 7 — The day the vault is unavailable *On page `/vault`.* The answer is not technical first. Establish scope — one component, one site, or the vault itself — then follow the documented incident runbook and the DR architecture, escalate, and make no uncontrolled changes while privileged access is degraded. Restoring it safely is the priority because every other recovery depends on it. This is also the cleanest explanation of why break glass exists and why it is tested on a schedule: the credentials that recover the platform cannot themselves depend on the platform. **What an interviewer is testing.** This question is testing whether you treat the privileged access platform as a Tier 0 availability dependency rather than as a security tool that happens to be down. ## What this prepares you to answer **Q. How is the vault itself protected?** It is a Tier 0 asset: a hardened server with no standard OS services, not domain-joined, with its own firewall and a proprietary protocol on 1858. Encryption is hierarchical — object keys protected by safe keys, protected by a vault key, protected by a server key held outside the database. Access is only through authenticated components, with HA, a DR replica and tested failover, and the vault administrator population kept separate from ordinary domain admins. **Q. What happens if you lose the server key?** With no backup, the vault is unrecoverable — the database alone decrypts to nothing. That is the point of the question, so say it plainly. It is why the key is held offline in physical custody or an HSM, with a documented custody chain and a rehearsed recovery procedure. **Q. Why is the vault deliberately not domain-joined?** Because it must survive the compromise of the domain. If domain administrators could authenticate to the vault by virtue of being domain administrators, a domain compromise would take the vault with it — and the vault is what you need to recover. Its authentication and its administrator population are kept independent on purpose. **Q. The vault is down. What do you do?** Scope it first — one component, one site or the vault itself — then follow the documented runbook and DR architecture, escalate, and make no uncontrolled changes while privileged access is degraded. Restoring it is the priority because every other recovery depends on it, and this is exactly why break glass credentials are held outside the platform and tested on a schedule. **Q. What would you check first in a vault environment you had just inherited?** Server key backup and custody, and whether DR failover has actually been tested rather than merely configured. After that, replication lag monitoring and whether component health — particularly the credential manager — is alerted on, because a silently stopped CPM becomes an audit finding months later. # Tiering the administrative plane > 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. *Understand why a Tier 0 credential must never be typed on an ordinary workstation, and what the model that follows from that actually looks like.* **Track:** Foundations **Priority:** high **Time:** about 9 minutes **Topics:** Tier 0, Enterprise Access Model, PAW, Jump hosts, Break glass **Walk it in the app:** https://pamsim.com/guides — guide id `admin-tiering` ## The walkthrough A click-by-click walkthrough of the running application. Read as prose it still works: the steps carry the explanation, not just the navigation. ### Step 1 — Credentials do not flow downwards *On page `/concepts`, element `concept:admin-tiering`.* The whole model comes from one observation: typing a credential on a machine exposes it to whatever has already compromised that machine. So a credential that can reach everything must never be typed on a machine that browses the internet and opens email. Tier 0 is anything that controls identity itself — domain controllers, the identity provider, the vault, backup systems, hypervisors. Tier 1 is servers and applications. Tier 2 is user workstations. The rule is directional: a Tier 0 credential is never used on a Tier 1 or Tier 2 machine. **Do this.** Read the tiering card. ### Step 2 — Two names for it, and one that is retired *On page `/concepts`, element `concept:admin-tiering`.* The tiered model is the older framing. The enterprise access model is its successor, broadening the same idea to control, management and data planes across cloud and on-premises rather than three server tiers. Know both names; the principle did not change. The separate hardened forest design — the red forest — is retired. Knowing why is a small credibility marker: it protected identity administration well and did nothing for the cloud control plane, which is now where the crown jewels sit. It still gets asked, and it distinguishes people who learned this recently from people who learned it once. ### Step 3 — The workstation is the control *On page `/concepts`, element `concept:admin-tiering`.* The practical expression is a privileged access workstation: hardened, single-purpose, used only for administration, with no email and no general browsing. That is where Tier 0 work happens. A jump or bastion host does a related job for a specific estate. And the session gateway you have been using is a jump host with credential handling and recording built in — which is why brokering and tiering are the same argument rather than two. ### Step 4 — The vault is itself Tier 0 *On page `/vault`, element `vault:health`.* Not a slogan. It is what drives the hardening, the lack of domain membership, the high availability pair, the disaster recovery replica, and a recovery path somebody has actually tested. It also drives who administers it. The vault administrator population is kept separate from ordinary domain administrators, because otherwise compromising the domain compromises the thing you need in order to recover from compromising the domain. ### Step 5 — Find the Tier 0 accounts here *On page `/accounts`, element `accounts:filters`.* Domain administrators, the vault's own accounts, backup and hypervisor accounts. These are the ones that get the tightest policy: shortest change interval, one-time passwords, dual control, mandatory recording. The tiering question in an interview is often really a prioritisation question. Asked where you would start with an unmanaged estate, the answer is Tier 0 first — largest blast radius per account, and the smallest number of accounts to get the first win. **Do this.** Filter to the highest-privilege accounts and look at what policy applies to them. ### Step 6 — Break glass, done properly *On page `/portal`.* The credential of last resort is a Tier 0 problem by definition, because it exists for the day the normal path has failed. A small number of named accounts, credentials sealed in the vault with a protected offline copy so they survive the failure they exist to recover, excluded from any policy that could lock them out, alarmed on use with an automatic ticket, rotated immediately after every use, and reviewed afterwards. The trade-off worth naming out loud: a credential that depends on the failed platform cannot perform the recovery, and one kept entirely outside the controls creates its own risk. Either way it needs compensating controls. **What an interviewer is testing.** The real question is the second half — how do you know it still works? You test on a schedule. An unrehearsed break-glass is a theory, and the day you need it is the worst possible time to discover the password is stale. ## What this prepares you to answer **Q. What is the tiered administration model and why does it exist?** It splits administration by what an identity controls. Tier 0 is anything controlling identity itself — domain controllers, the identity provider, the vault, backups, hypervisors. Tier 1 is servers and applications, Tier 2 is workstations. Credentials never flow downwards, because typing a credential on a machine exposes it to whatever has compromised that machine. Its successor framing is the enterprise access model, which extends the same idea to control, management and data planes including cloud. **Q. What is a privileged access workstation?** A hardened, single-purpose machine used only for administration, with no email and no general browsing, so that Tier 0 credentials are never typed on a machine exposed to the usual initial-access routes. A jump or bastion host is the same idea for a specific target estate, and a session gateway is a jump host with credential injection and recording built in. **Q. Why was the red forest design retired?** It protected identity administration in Active Directory well, and it did nothing for the cloud control plane, which is now where the most valuable access sits. The replacement — the enterprise access model — covers control, management and data planes across both. It still gets asked because knowing it is retired distinguishes recent knowledge from knowledge learned once. **Q. How do you design break glass, and how do you prove it still works?** A small number of named emergency identities, a defined trigger and approval path, credentials sealed in the vault with a protected offline copy so they survive the failure they exist to recover, excluded from any lockout policy, alarmed on access with an automatic ticket, no routine use, rotated immediately after every use and reviewed afterwards. Proving it works is the real question: you test on a schedule, because an unrehearsed break-glass is a theory. And name the trade-off — a credential depending on the failed platform cannot recover it, but one kept outside the controls carries its own risk. # Authenticators and hard tokens > 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. *Rank the factors by what actually resists attack rather than by form factor, and handle the lifecycle question that produces audit findings.* **Track:** Foundations **Priority:** high **Time:** about 10 minutes **Topics:** FIDO2, Phishing resistance, Hard tokens, Smart cards, Lifecycle **Walk it in the app:** https://pamsim.com/guides — guide id `authenticators` ## The walkthrough A click-by-click walkthrough of the running application. Read as prose it still works: the steps carry the explanation, not just the navigation. ### Step 1 — Form factor is not the answer *On page `/concepts`, element `concept:authenticators`.* The instinct that hardware is automatically strongest is wrong, and correcting it is the answer. A one-time-password fob is hardware and still phishable — a relay captures and replays the code inside its validity window. Phishing resistance is the dividing line. A security key resists phishing because the private key never leaves the device and the credential is bound to the origin, so it will not sign for a lookalike domain. A user pushed to a convincing replica simply cannot complete the ceremony. **Do this.** Read the authenticator card. **What an interviewer is testing.** "Which is stronger, a hardware token or an app?" is a trap that rewards the precise answer: it depends entirely on whether the protocol binds to origin. ### Step 2 — The three device families *On page `/concepts`, element `concept:authenticators`.* Security keys implementing the modern web authentication standard: public-key, origin-bound, with a PIN or biometric as the second factor, and discoverable credentials enabling passwordless sign-in entirely. One-time-password hardware — the classic fob and the open-standard time-based and counter-based tokens. A seed shared at manufacture, a rotating code. The operational details that come up: clock drift, next-tokencode mode, and a passcode formed from a PIN plus the displayed code. Certificate-based smart cards, backed by a public-key infrastructure: the card holds the private key, a PIN unlocks it. Common in government and heavily regulated estates, and they bring a whole certificate lifecycle with them — issuance, renewal, revocation, and a certificate authority that is itself Tier 0. ### Step 3 — Why one device covers a mixed estate *On page `/concepts`, element `concept:authenticators`.* Multi-protocol keys can act as a modern web authenticator, a smart card, a time-based token and a code generator simultaneously. That is why they suit privileged users specifically: administrators still meet legacy systems that cannot speak the modern protocol. It is also a practical procurement answer. One device, one enrolment, one return-on-termination process, rather than a drawer of incompatible tokens. ### Step 4 — Where the factor meets privileged access *On page `/users`.* Identities here carry whether multi-factor is enrolled. In a real deployment that flag is a policy input: privileged access can be refused to an identity that has not enrolled, and a step-up challenge can be demanded at the moment of privilege rather than only at login. Step-up is the concept worth naming — challenge again when retrieving a Tier 0 credential or launching an administrative session, with a stronger factor than the one used at login rather than a repeat of it. A sensitive operation deserves its own gate, not just the front door. **Do this.** Look at which identities have multi-factor enrolled. ### Step 5 — The lifecycle is where findings come from *On page `/concepts`, element `concept:authenticators`.* Procurement and inventory, enrolment to a named user, distribution with a chain of custody, replacement for lost or broken devices, revocation on loss, and return on termination. An unreturned token from a leaver is an audit finding. An untracked spare is worse, because nobody can say who holds it. This is the part of a hardware programme that is unglamorous and gets audited, and having a number for unreturned tokens is the sign you have run one. ### Step 6 — "I left it at home" *On page `/concepts`, element `concept:authenticators`.* Every deployment needs an answer, and this answer is the control most likely to decay into a routine workaround. Verify identity out of band before issuing anything — the lost-token call is a social-engineering target, so that step is a control rather than paperwork. Prefer a second registered key to a bypass code. If a code is issued, make it single-use and short-lived, alert on issue and on use, and review who is using them and how often. Repeat users mean the process has become the process. **What an interviewer is testing.** The policy sentence: hardware for privileged and high-risk populations, software authenticators for everyone else. The standards-based justification is that the highest authenticator assurance level effectively requires hardware. ## What this prepares you to answer **Q. When would you issue a hard token rather than an authenticator app?** For privileged and high-risk populations, and where a phone is unsuitable or unavailable. The reasoning is not that hardware is inherently stronger — a one-time-password fob is hardware and still phishable — but that a security key keeps the private key off a general-purpose device and binds the credential to the origin, which defeats the relay attack outright. The highest authenticator assurance level in the federal guidelines effectively requires hardware, which is how you justify the cost. **Q. Explain how a security key resists phishing at a protocol level.** The credential is bound to the origin it was registered for. When the browser asks the key to sign, it passes the origin; if that origin does not match, the key will not produce a signature. So a user on a convincing replica cannot complete the ceremony at all — there is nothing to relay, because the assertion the attacker needs was never created. The private key also never leaves the device, so endpoint malware cannot extract it. **Q. Walk me through the hard-token lifecycle.** Procurement and inventory, enrolment and registration to a named user, distribution with a chain of custody, replacement for lost or broken devices, revocation on loss, and return on termination. The audit-visible numbers are tokens issued, returned on termination, and unreturned — an unreturned token from a leaver is a finding, and an untracked spare is worse because nobody can say who holds it. **Q. How do you handle a lost token without creating a bypass everyone uses?** Verify identity out of band before issuing anything, because the lost-token call is a helpdesk social-engineering target — that step is a control, not paperwork. Prefer a second registered key to a bypass code. Where a code is issued, make it single-use with a short expiry, alert on issue and on use, and review bypass usage as a metric: repeat users mean the exception has become the process. # Zero trust network access, precisely > 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. *Separate the two products people both call "the VPN", explain why connectors mean no inbound rules, and say how this layers with privileged access.* **Track:** Foundations **Priority:** high **Time:** about 10 minutes **Topics:** ZTNA, SASE, SSE, TLS inspection, Device posture **Walk it in the app:** https://pamsim.com/guides — guide id `zero-trust-access` ## The walkthrough A click-by-click walkthrough of the running application. Read as prose it still works: the steps carry the explanation, not just the navigation. ### Step 1 — Two products, opposite directions *On page `/concepts`, element `concept:zero-trust-access`.* Precision is the filter here. The private-access product is a zero trust replacement for the VPN — inbound to your private applications. The internet-access product is a cloud secure web gateway — outbound to the internet. They are licensed, configured and logged separately. One protects applications from users; the other protects users from the internet. Calling both of them "the VPN" is the answer that ends the topic early. **Do this.** Read the zero trust card. ### Step 2 — Why there are no inbound firewall rules *On page `/concepts`, element `concept:zero-trust-access`.* This is the mechanism worth being able to draw. A connector sits beside the application and dials outward to the cloud service. The user's client also dials outward. When the user requests the application, the broker stitches the two outbound connections together in the middle. So there is no listening port on the application side, nothing inbound to allow, and nothing internet-facing to scan or attack. Connector placement then becomes an access-control decision as much as a network one — what a connector can reach is what can be published. ### Step 3 — Against a VPN, in one comparison *On page `/concepts`, element `concept:zero-trust-access`.* A VPN authenticates once, at connection, and drops you onto a network segment where everything reachable is reachable. Zero trust access authenticates per application, continuously, with identity and device posture as inputs. The exposure differs too: a VPN concentrator is an inbound listener; connectors expose nothing. And lateral movement is granted by design in one and removed by design in the other. **What an interviewer is testing.** That four-row comparison — authentication, what you get, exposure, lateral movement — is a complete answer on its own and takes twenty seconds. ### Step 4 — Inspecting encrypted traffic, and what it costs *On page `/concepts`, element `concept:zero-trust-access`.* It is necessary because that is how threats arrive. It is also consequential, and a good answer includes the cost: a trusted root certificate on every endpoint, and bypass lists for banking, healthcare and certificate-pinned applications that will simply break. Privacy, legal and works-council considerations belong in the answer rather than as an afterthought. Saying so is what makes it sound like it came from a deployment rather than a datasheet. ### Step 5 — Posture, and what it is not *On page `/users`.* Device posture reports patch level, disk encryption, whether an endpoint detection agent is present, a certificate, domain membership — and policy grades access accordingly. A compliant corporate laptop gets the administrative application; a non-compliant one gets read-only or nothing. The caveat that shows judgement: posture is a point-in-time attestation from the endpoint itself. It complements controls on the target rather than replacing them, which is exactly why the privileged layer still exists behind it. ### Step 6 — How the two layers combine *On page `/sessions`, element `sessions:table`.* The design worth describing: network access to a privileged workstation or the session gateway, the gateway onward to the target, and neither layer trusting the network. Stolen credentials alone then do not get an attacker to the jump host — they also need an enrolled identity and a device that passes posture. And the administrative account is not usable without going through the vault. Two independent failures required rather than one. ### Step 7 — The acronyms that appear in every job description *On page `/glossary`.* The convergence of networking and security delivered from the cloud, and the security half of it on its own — the secure web gateway, the cloud application broker, zero trust access and data loss prevention. Search the glossary for them. They come up constantly in postings for this kind of role, and being unable to expand one is a small avoidable stumble. **Do this.** Search for SASE, SSE, SWG and CASB. ## What this prepares you to answer **Q. What is the difference between the private-access and internet-access products?** Direction and purpose. Internet access is outbound: a cloud secure web gateway and proxy — URL filtering, encrypted traffic inspection, cloud firewall, sandboxing, cloud application visibility and data loss prevention — reached through an endpoint agent, proxy configuration or branch tunnels. Private access is inbound to private applications: zero trust access brokering a user to one specific internal application through connectors, replacing the VPN. One protects users from the internet, the other protects applications from users, and they are licensed, configured and logged separately. **Q. Why does the connector design mean no inbound firewall rules?** Both sides dial out. The user's connection and the connector's connection are stitched together in the provider's cloud, so there is no listening port on the application side — nothing inbound to allow, and nothing internet-facing to scan or attack. It also makes connector placement an access-control decision: what a connector can reach is what can be published. **Q. Why is inspecting encrypted traffic necessary, and what are the downsides?** Necessary because most threats now arrive over encrypted transport, so not inspecting it means not seeing them. The costs are real: a trusted root certificate must be distributed to every endpoint, certificate-pinned applications break and need bypass lists, and banking and healthcare traffic raises privacy and legal constraints that belong in the design rather than being discovered later. **Q. How does device posture fit an access decision?** It supplies signals — patch level, disk encryption, an endpoint detection agent, a certificate, domain membership — alongside identity and application sensitivity, so outcomes are graded rather than binary: a compliant corporate laptop reaches the administrative application, a non-compliant one gets read-only or nothing. The caveat worth adding is that posture is a point-in-time attestation from the endpoint, so it complements controls on the target rather than replacing them. # Discover and onboard an account > 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. *Run the whole sequence a real onboarding follows — find privilege nobody is managing, decide what should happen to it, and take the ones that matter under management.* **Track:** Operations **Priority:** essential **Time:** about 14 minutes **Topics:** Discovery, Triage, Onboarding, Safe, Platform, Verify **Walk it in the app:** https://pamsim.com/guides — guide id `onboard-account` ## The walkthrough A click-by-click walkthrough of the running application. Read as prose it still works: the steps carry the explanation, not just the navigation. ### Step 1 — Onboarding starts before onboarding *On page `/discovery`.* Every PAM programme begins with discovery: scanning the estate for privileged accounts, then comparing what is found against what is actually in a safe. Whatever is left over is privilege that rotates on nobody's schedule, appears in no approval workflow and is recorded nowhere. The gap is always larger than anyone expects. This queue is what a first scan turns up on a small estate — and the oldest credential in it has not changed in over three years. **What an interviewer is testing.** 'Where would you start with a new PAM deployment?' The answer is discovery, and the reason is that you cannot protect what you have not enumerated. Candidates who start at 'onboard the domain admins' have skipped the part that finds the ones nobody remembered. ### Step 2 — Read the evidence, not the name *On page `/discovery`, element `discovery:findings`.* Each finding says why the scan considers it privileged. `toor` is UID 0 under a different name — root wearing a hat, created outside any change record. `backup_op` is in Backup Operators, which confers the ability to read any file on a domain controller regardless of its permissions: a Tier 0 privilege that does not look like one. Watch for the ones whose password age is unknown. That is worse than old, not better — it means the target cannot say when the password last changed, so nobody can prove it ever has. **Do this.** Open two or three findings and read the severity reasoning. ### Step 3 — Triage: onboard, or remove *On page `/discovery`.* The wrong instinct is to onboard everything. An account nothing needs should be removed from the host, not brought under management — onboarding it means rotating and reviewing a credential forever that should not exist. Onboard when something genuinely depends on it. Remove when it is a leftover: a migration account from a project that finished, an administrator for a decommissioned application, a second root nobody can explain. Removal is not a PAM action — you raise it with whoever owns the host and record the decision here. **What an interviewer is testing.** Saying 'it depends on whether anything uses it' unprompted is the answer. It shows you have done this rather than read about it, because the temptation in the moment is always to vault everything and move on. ### Step 4 — A dismissal is an audit artefact *On page `/discovery`.* Leaving a finding unmanaged is a legitimate outcome and the reason is mandatory, because an auditor sampling dismissed findings is looking for the ones that say nothing. 'Not needed', recorded by someone who has since left, is indistinguishable from nobody having looked. Look at the two already dismissed in this queue. Each says what makes it acceptable and what is being done instead. That is the standard. **Do this.** Filter to Dismissed and read both reasons. ### Step 5 — Onboarding takes over the credential *On page `/discovery`.* Onboard one of the findings. Note what the dialog warns you about: the password changes on the target at that moment, so anything still holding a copy — a config file, a scheduled task, a script — stops working immediately. That is why step 8 exists in the sequence below, and why service accounts are onboarded carefully rather than in bulk. **Do this.** Onboard a finding, choosing a safe and a platform. ### Step 6 — The nine steps, in order *On page `/accounts`.* Identify the account, owner and target. Choose the account type and matching platform. Choose the safe and its permissions. Configure logon and reconcile accounts if the platform needs them. Add the credential and verify. Enable CPM management and run a test rotation. Test the PSM connection. Confirm dependent services still authenticate. Confirm logging and document ownership. Nine steps. Interviewers ask this as an open question and listen for whether you stop at step five. **What an interviewer is testing.** The tell is steps 8 and 9. Anyone can add an account; a Level 2 analyst confirms the dependencies survived it and writes down who owns it. ### Step 7 — Where onboarded accounts end up *On page `/accounts`, element `accounts:scopes`.* This list opens on Favorites rather than the whole inventory, because an operator works with a handful of accounts repeatedly. Switch to All accounts for a review or a discovery sweep. At scale you do not onboard one at a time: onboarding rules auto-vault discovered accounts matching criteria, and the Password Upload Utility or REST API handle bulk. Manual onboarding through the portal is for one-offs. **Do this.** Click All accounts, then come back to Favorites. ### Step 8 — Steps 1 and 2 — identify, then pick the platform *On page `/accounts`, element `accounts:add`.* The account name, the target address and the account type decide which platform fits. A Windows domain account and a Unix service account need different platforms because the mechanics of changing the password differ. Notice the form never asks for a password. In a real onboarding you either supply the current one so the CPM can take it over, or you reconcile so the first managed value is one no human has ever seen. The second is stronger. **Do this.** Click Add account. Use a service account so the later steps make sense — something like CORP\svc_reporting on prod-app-02.corp.pamsim.local. ### Step 9 — Step 3 — the safe decides who can use it *On page `/accounts`, element `accounts:add`.* The safe you choose silently decides which people can use this credential, for as long as it exists. Putting a service account into a broad safe is the most common onboarding mistake, and it is invisible in normal operation. Pick the safe owned by the team who owns the system, not the team who happens to be doing the onboarding. **Do this.** Choose a safe and a platform, then submit the form. ### Step 10 — Step 4 — logon and reconcile accounts *On page `/lookup?account=svc_backup_agent`, element `account:tabs`.* Some platforms need a separate logon account, because the managed account cannot log in to change its own password — common on Unix. Others need a reconcile account, used when the stored password no longer works at all. They are different things. The logon account runs during healthy changes; the reconcile account only during recovery, using its own elevated rights to set a new password. **What an interviewer is testing.** Knowing why both exist is described as a strong signal. PAM SIM does not model them separately — say so if asked, and describe the distinction anyway. ### Step 11 — Step 5 — verify before you rotate *On page `/lookup?account=svc_backup_agent`, element `account:verify`.* Verification proves the value in the vault actually authenticates against the target. Doing it first means that if a later change fails, you already know it is not because the starting credential was wrong. Rotating before verifying is a named mistake. It throws away the one piece of diagnostic information you had for free. **Do this.** Run Verify from the Last verified pane. Do the same on the account you just created. ### Step 12 — Step 6 — a test rotation, deliberately *On page `/lookup?account=svc_backup_agent`, element `account:compliance-actions`.* Run one change in a controlled window while someone who owns the application is watching. You are not testing the platform; you are testing whether anything downstream breaks. Watch the step sequence: connect, authenticate, generate, change on target, verify new credential, update Vault. Verifying before writing to the vault is what stops the vault holding a value the target will not accept. **Do this.** Run Change from the Compliance status pane and watch the sequence complete. ### Step 13 — Step 7 — test the session path *On page `/lookup?account=svc_backup_agent`, element `account:connect`.* Credential management and session brokering are two different paths. A working rotation tells you nothing about whether the PSM can reach the target. Test the connection separately, and remember which path you are testing when something fails later. **Do this.** Click Connect and open a session, then terminate it. ### Step 14 — Steps 8 and 9 — dependencies, logging, ownership *On page `/lookup?account=svc_backup_agent`, element `account:tabs`.* Confirm the dependent services still authenticate — this is where onboarding goes wrong for service accounts, and it has its own walkthrough. Then confirm the activity is being logged, and write down who owns the account. An account with no named owner cannot be reviewed, recertified or safely rotated. **Do this.** Open the Activities tab and confirm the onboarding, verification and rotation are all recorded. **What an interviewer is testing.** “What could go wrong during onboarding?” Safe selection, an unmapped dependency, and no named owner. Those three cover almost every real incident. ## What this prepares you to answer **Q. How would you onboard a new privileged account?** Identify account, owner and target; choose account type and matching platform; choose the safe and permissions; configure logon/reconcile accounts if needed; add credential and verify; enable CPM management and run a controlled test rotation; test the PSM connection; confirm dependent services still authenticate; confirm logging and document ownership. **Q. How do you onboard at scale rather than one at a time?** Onboarding rules auto-vault discovered accounts matching criteria, and the Password Upload Utility or REST API handle bulk loads. Manual portal onboarding is for one-offs. At scale, rules plus API is the only maintainable approach. **Q. What is the difference between a logon account and a reconcile account?** A logon account establishes the session when the managed account cannot log in to change its own password — common on Unix. A reconcile account is used when the stored password no longer works, and uses its own elevated rights to force a new one. One runs during healthy changes, the other during recovery. **Q. What could go wrong during onboarding?** Choosing too broad a safe, which silently grants access to the wrong people; missing a service account dependency, which causes an outage at the first rotation; and leaving the account without a named owner, which makes it unreviewable. # Design and run a safe > 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. *Work the authorisation boundary end to end: why safes exist, how to structure them, how membership actually grants access, and what a safe looks like at review time.* **Track:** Operations **Priority:** essential **Time:** about 10 minutes **Topics:** Safe, Authorisation, Permissions, Access review, Design **Walk it in the app:** https://pamsim.com/guides — guide id `safe-design` ## The walkthrough A click-by-click walkthrough of the running application. Read as prose it still works: the steps carry the explanation, not just the navigation. ### Step 1 — The safe is the unit of authorisation *On page `/safes`.* Permissions are granted on a safe, not on an account. That single design decision is what makes access control scale with the number of teams rather than the number of credentials — which matters when the estate has four hundred accounts and eleven teams. So the question a safe answers is always the same one: who may touch what is inside this? Not how it is managed, and not what policy applies. Just who. ### Step 2 — Too few, and too many *On page `/safes`.* One safe called All Passwords means every permission grant on it is automatically over-broad — everybody who needs anything can see everything. That is the failure at one end. A safe per account is the failure at the other: administration collapses, nobody can answer who has access to what, and access reviews become impossible because there are two thousand of them. The workable patterns are by application, by business unit, or by platform team. A good safe maps to a single scope of duty — one team, one environment, one class of system. **What an interviewer is testing.** Naming both failure modes rather than one is what makes this sound like experience. Anyone can say 'least privilege'. ### Step 3 — Read the existing structure *On page `/safes`.* Look at how these are named and what each contains. The naming carries meaning: environment, system class, owning team. A safe you cannot infer the audience of from its name is a safe nobody will review properly. Note the risk level on each. It is not decoration — it drives which policy exceptions apply and how closely the contents are watched. **Do this.** Open a safe from the list and look at what is in it. ### Step 4 — Accounts, members, activity *On page `/safes/1`, element `safe:tabs`.* Three views of the same container. Accounts is what is protected. Members is who may touch it and at what level. Activity is what has actually happened — the evidence that the first two are working. The members tab is the one an auditor asks for by name, because it is the access review artefact. **Do this.** Move through the tabs on this safe. ### Step 5 — The permission ladder *On page `/safes/1`, element `safe:tabs`.* List, use, retrieve, add, update, initiate rotation, manage, authorise requests. They are separate on purpose, and the separation is what least privilege is actually expressed in. The important pairing is Use without Retrieve: the member can connect through the session manager but can never reveal the password. That is the goal state for most people, and being able to say it unprompted is one of the clearest signals that you have administered a vault rather than read about one. **What an interviewer is testing.** If asked how to let someone connect but never see the credential: safe membership with Use and not Retrieve, then check for any object-level permission that overrides it. ### Step 6 — When to create another one *On page `/safes`, element `safes:create`.* The trigger is a different audience needing different access. Not a different technology — that is a platform decision, and confusing the two is the single most common mix-up in this area. Two accounts in the same business area may need different platforms because the target technologies differ. Two teams needing different access to the same technology need different safes. Same estate, two different objects. **Do this.** Open the create dialogue and read what it asks for: name, description, owner, managing credential manager, risk level. ### Step 7 — The safe at review time *On page `/safes/1`, element `safe:tabs`.* Once or twice a year somebody has to confirm that everybody who can reach these credentials still needs to. The membership list is the artefact for that conversation — one row per grant, with the person, their role and the permission level. What it catches is unglamorous and valuable: leavers who still hold membership, people who moved teams two years ago, and temporary grants nobody removed. If a leaver still appears here, that is an identity governance failure that has surfaced on the privileged side. ## What this prepares you to answer **Q. What is the difference between a safe and a platform?** A safe is the authorisation and storage boundary: who can list, use, retrieve or manage the accounts inside. A platform is the technical policy for a class of account: rotation schedule, complexity, verification, connection components, plugin behaviour. Two teams needing different access is a safe problem; two different target technologies is a platform problem. **Q. How would you structure safes for a new estate?** By scope of duty — application, business unit or platform team — so each safe has one identifiable audience. Avoid both failure modes: one safe for everything makes every grant over-broad, and a safe per account makes administration and access review impossible. The test is whether you can infer the audience from the name. **Q. How do you let someone connect to a target but never see the password?** Grant Use on the safe without Retrieve. They can launch a brokered session where the credential is injected, and the reveal action is simply not available to them. If they can currently reveal it, remove Retrieve at the safe level and then check for object-level permissions that override the safe. **Q. What does an access review of a safe actually involve?** Producing the membership as one row per grant — person, role, permission level — and having the owner confirm each is still required. It depends entirely on being able to enumerate the population, which is why applications that create accounts on first login and never remove them are an audit problem. What it catches is leavers, movers and temporary grants that were never withdrawn. # Platforms and the Master Policy > 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. *Work the policy layer end to end: what a platform controls, how to tune one safely, and where organisation-wide rules and their exceptions actually live.* **Track:** Operations **Priority:** essential **Time:** about 10 minutes **Topics:** Platform, Master Policy, Rotation, Connection components, Exceptions **Walk it in the app:** https://pamsim.com/guides — guide id `platform-policy` ## The walkthrough A click-by-click walkthrough of the running application. Read as prose it still works: the steps carry the explanation, not just the navigation. ### Step 1 — A platform is the policy template *On page `/platforms`, element `platforms:list`.* Every managed account inherits its behaviour from a platform: how long the password may live, how complex it must be, whether it is verified, whether a failure auto-reconciles, how a session connects to that target type, and how the plugin talks to it. There is one per class of target system — Windows domain accounts, Unix by SSH, Oracle, a network device family. That is the unit, and it is why a policy change lands on hundreds of accounts at once. **Do this.** Look at the platforms in the list and note how they map to system types. ### Step 2 — The change interval is the consequential setting *On page `/platforms`, element `platform:password-policy`.* Open a platform and look at the change interval. It is the setting that decides, for every account using this platform, whether they are compliant or not — compliance is measured against policy, so 'old' is relative rather than absolute. Length matters more than symbols. Length defeats offline cracking; symbol requirements mostly generate passwords that some target rejects, which then shows up as a rotation failure nobody can explain. **Do this.** Open a platform from the list and read its password policy. ### Step 3 — Verification and reconciliation behaviour *On page `/platforms`, element `platform:password-policy`.* Verification is the platform asking, on a schedule, whether the stored credential still works. Without it, drift is invisible until somebody tries to use the account. Automatic reconciliation on failure decides what happens when a change fails: use the reconciliation account to force the credential back to a known state, or stop and raise it for a human. Both are defensible — automatic keeps the estate healthy, manual makes sure somebody investigates why it drifted. Knowing that it is a trade-off rather than a best practice is the answer. ### Step 4 — Connection components make policy executable *On page `/platforms`, element `platform:connection`.* This is the part that turns configuration into an actual session: which component drives RDP, which drives SSH, which launches a database client or a web console. The platform lists the ones its accounts may use. A missing or failing connection component is the standard cause of 'I can see the account but I cannot connect'. Learning that this lives on the platform rather than on the account or the safe saves an hour on that ticket. **Do this.** Read the connection components on this platform. ### Step 5 — Duplicate and tune, do not bend the original *On page `/platforms`, element `platforms:list`.* One system with unusual requirements — a legacy appliance that rejects symbols, a database that needs a longer interval — is handled by duplicating the platform and tuning the copy. That is the normal administrative move, not a workaround. The alternative, loosening the shared platform so one awkward system passes, silently weakens every account that uses it. That is how an estate ends up with a 180-day interval nobody chose. ### Step 6 — The Master Policy sits above all of it *On page `/policies`, element `policy:access`.* Organisation-wide rules layered over every platform: require dual control, enforce exclusive access, one-time passwords, demand a reason or a ticket, mandate session recording. These are not per-account settings and they are not per-safe settings. They are the rules the organisation has decided apply everywhere unless somebody explicitly agreed otherwise. **Do this.** Read the access policy rules. ### Step 7 — Exceptions are granted per platform *On page `/policies`, element `policy:emergency`.* So the question 'how do you make this one system stricter?' is a Master Policy exception on its platform. A new safe would change who can reach it — a different question entirely. Saying that distinction out loud is the answer to one of the most reliable interview questions in this area. Safe: who may touch it. Platform: how it is managed. Master Policy: the rules above both, with exceptions applied at the platform. **What an interviewer is testing.** Expect this as "how do safes, platforms and the Master Policy relate?". The trap is answering with definitions and never saying which one you would change. ## What this prepares you to answer **Q. How do safes, platforms and the Master Policy relate?** A safe is the access boundary — who can list, use, retrieve or manage what is inside. A platform is the technical policy for a class of account — rotation schedule, verification, complexity, plugin behaviour, connection components. The Master Policy sits above both with organisation-wide rules: dual control, exclusive access, one-time passwords, reason or ticket required, session recording. To make one system stricter you add a Master Policy exception on its platform. **Q. A legacy system cannot accept the standard password complexity. What do you do?** Duplicate the platform and tune the copy for that system, rather than loosening the shared platform and weakening every account that uses it. Record why, and keep the exception visible — an undocumented relaxed platform is how an estate acquires settings nobody chose. **Q. What does a platform actually control?** Password length, complexity and change interval; whether and how often the credential is verified; whether a failed change auto-reconciles; which connection components may broker sessions for these accounts; and the plugin behaviour used to talk to that target type. Accounts inherit all of it, which is why a platform change re-evaluates every account using it. **Q. Why does 'I can see the account but cannot connect' point at the platform?** Because the connection component is assigned through the platform. Visibility is safe membership plus List; connecting needs Use plus a working connection component, a healthy session manager and a reachable target. A missing or failing connection component is the standard cause, and it lives on the platform rather than on the account or the safe. # Verify, change, reconcile > 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. *Run all three CPM job types and be able to say precisely what each one asks and when you would use it.* **Track:** Operations **Priority:** essential **Time:** about 9 minutes **Topics:** CPM, Verify, Change, Reconcile, Drift **Walk it in the app:** https://pamsim.com/guides — guide id `verify-change-reconcile` ## The walkthrough A click-by-click walkthrough of the running application. Read as prose it still works: the steps carry the explanation, not just the navigation. ### Step 1 — Three jobs, three different questions *On page `/cpm`.* Verify asks: does the password stored in the vault still authenticate to the target? Change asks: using the current valid credential, can the CPM rotate the target and sync the new value back? Reconcile asks: the vault's credential does not work — can a separately authorised identity forcibly establish a new known password? Phrase them as questions in the interview. Definitions sound memorised; questions sound like you have run them. **What an interviewer is testing.** This is one of the most reliably asked PAM questions. Getting change and reconcile the wrong way round is the classic error. ### Step 2 — The management cycle decision tree *On page `/cpm`, element `cpm:queue`.* An account comes due. Does the stored credential verify? If yes, run a normal change, update the vault, verify the new password, record the audit entry. If no, investigate the mismatch and the target's state. Is a reconcile account available and authorised? If yes, reconcile, update the vault, verify. If no, escalate to controlled recovery. Notice that reconcile is never the first move and never the automatic one. ### Step 3 — Run a verify on a healthy account *On page `/accounts?rotation=ok`.* Verification is cheap and non-destructive. It is the right first action in almost every diagnostic, and it is what the platform runs on its own verify interval to catch drift before a change fails. **Do this.** Open any compliant account, go to Overview, and run Verify from the Last verified pane. ### Step 4 — Run a change on an overdue account *On page `/accounts?rotation=overdue`.* A change generates a new policy-compliant password, sets it on the target, verifies it works, and only then writes it to the vault. That order matters. Writing to the vault first is how a vault ends up holding a value nothing will accept. **Do this.** Open an overdue account and run Change from the Compliance status pane. Watch the six steps. ### Step 5 — Now find an account where change fails *On page `/cpm?tab=failed`.* Three accounts in this environment carry a genuine fault condition. Look at the failed jobs and note which step each one died on — the step tells you more than the message. **Do this.** Open a failed job and read the failing step and cause. ### Step 6 — Verify still succeeds — that is the clue *On page `/lookup?account=svc_sql_backup`, element `account:verify`.* On svc_sql_backup, verification passes but change fails. The host is reachable and the stored password is correct, so this is not drift. That leaves permissions or the target's own password policy. Here it is permissions: the CPM's account lacks ALTER ANY LOGIN on that SQL Server. **Do this.** Open svc_sql_backup and run Verify. Confirm it succeeds. **What an interviewer is testing.** “Verify succeeds but change fails — what does that tell you?” It rules out drift and reachability and points straight at rights or policy. Say that reasoning out loud; it is what they are listening for. ### Step 7 — Reconcile repairs it *On page `/lookup?account=svc_sql_backup`, element `account:compliance-actions`.* The reconcile account has rights the CPM account does not, so it can force a new known value. Run it, then run a change to confirm the account is healthy again. Then fix the cause: grant the CPM account the missing right. Repairing one account is a ticket; stopping it recurring is the job. **Do this.** Run Reconcile, wait for it to finish, then run Change and confirm it now succeeds. ### Step 8 — And where reconcile cannot help *On page `/lookup?account=svc_exchange`.* svc_exchange fails at the first step: the CPM cannot open a connection to the host at all. Reconcile fails the same way, because it needs the same network path. Nothing in the platform fixes an unreachable target. That is a network or host problem, and saying so confidently is better than trying things. **Do this.** Run Reconcile on svc_exchange and watch it fail at the connect step. ### Step 9 — Rotation triggers *On page `/cpm`.* Four, and they are platform-configurable: on a schedule every N days; on check-in when exclusive access is released; on release immediately after a session ends; and on demand after suspected exposure. One-time passwords are the on-release case: the value is rotated the moment the session finishes, so a retrieved credential is worthless afterwards. ## What this prepares you to answer **Q. What is the difference between verify, change and reconcile?** Verify asks whether the stored password still authenticates. Change rotates the target using the current valid credential and syncs the new value. Reconcile is recovery — a separately authorised identity forces a new known password when the stored one no longer works. **Q. When would you reconcile rather than change?** When the vault's copy no longer works on the target, or when the CPM's own account lacks the rights to change it. Reconcile is not automatic and not the first move — it forces synchronisation but does not explain why synchronisation was lost. **Q. Verify succeeds but change fails. What does that tell you?** Reachability and the stored credential are both fine, so it is not drift. It is the CPM account's permissions on the target, or the target rejecting the generated password on complexity grounds. **Q. What triggers a rotation?** A schedule, check-in after exclusive access is released, release immediately after a session ends, or on demand after suspected exposure. All configured on the platform. # Troubleshoot a failed rotation > 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. *Work the most common ticket in a PAM team using a systematic ladder rather than guesswork.* **Track:** Operations **Priority:** essential **Time:** about 11 minutes **Topics:** CPM, Troubleshooting, Diagnosis, Root cause **Walk it in the app:** https://pamsim.com/guides — guide id `failed-rotation` ## The walkthrough A click-by-click walkthrough of the running application. Read as prose it still works: the steps carry the explanation, not just the navigation. ### Step 1 — Scope it before you touch it *On page `/cpm`.* One account, one platform, one CPM, or enterprise-wide? The answer changes everything you do next. One account failing while its platform-mates succeed is an account or target problem. Every account on one platform failing is a plugin or platform-configuration problem. Every account on one CPM failing is a service, connectivity or vault-communication problem. **What an interviewer is testing.** Starting with scope is the single easiest way to sound systematic. Candidates who jump straight to a cause sound like they are guessing, because they are. ### Step 2 — Two paths, and they fail differently *On page `/cpm`, element `cpm:queue`.* Management path: CPM → target. Session path: user → PVWA → PSM → target. Before anything else, decide which path is broken. Rotation problems live on the management path; connection problems live on the session path; and the fix for one is almost never the fix for the other. ### Step 3 — Read the failing step *On page `/cpm?tab=failed`, element `cpm:job-tabs`.* Every failed job records the step it died on. Connect step means reachability. Authenticate step means drift or a wrong stored credential. Change step means permissions or the target's password policy. Name the step before the cause. It is how you avoid diagnosing the wrong half of the problem. **Do this.** Open each failed job in turn and note the step and the cause. ### Step 4 — The ladder, in order *On page `/cpm?tab=failed`.* Scope. Account and platform configuration — right platform, management actually enabled. Safe permissions. CPM health. Network and DNS from the CPM to the target. Target authentication and account condition. Password-policy compatibility. Reconcile account condition. Dependent service behaviour. Logs. Then validate that verification passes and the next management cycle is healthy. DNS deserves its own mention: resolution failures masquerade as authentication failures, and people lose hours to that. **What an interviewer is testing.** You will not be asked to recite eleven steps. You will be asked to sound like someone who has one. Give the first four in order and say you would work down from there. ### Step 5 — Logs, in the right order *On page `/audit?category=rotation`, element `audit:filters`.* In a real deployment: the portal error first, then the CPM console and trace logs, then increased platform debugging under an approved procedure. Not the other way round — you do not start by turning on debug logging. Here, the audit trail is the equivalent. Filter to the rotation category and read the failures in sequence. **Do this.** Filter the audit log by category Rotation and result Failure. ### Step 6 — Repeat failures become an alert *On page `/alerts`.* One failure is an event. Three consecutive failures on the same account is a control failure, and it should page someone. Notice that the security event carries how many failures there have been and how old the credential now is. That framing — the control is not operating — is what turns an ops ticket into an audit finding. ### Step 7 — Fix the cause, not the symptom *On page `/cpm`.* Grant the CPM account the right it was missing. Relax the symbol requirement the target rejects. Fix the network path. Then confirm the next scheduled cycle succeeds without anyone intervening. The named anti-patterns are worth avoiding out loud: do not say you would reset everything, do not treat a failed rotation as an inconvenience, do not skip scope or logs, and do not blame the platform first — most failures are environmental. ## What this prepares you to answer **Q. A CPM rotation is failing. Walk me through your diagnosis.** Scope it first — one account, one platform, one CPM, or everything. Then check account and platform configuration, safe permissions, CPM health, network and DNS to the target, target authentication and account state, password policy compatibility, and the reconcile account. Read the portal error before the CPM logs. Validate by confirming verification passes and the next cycle is clean. **Q. Every account on one platform is failing but others are fine. Where do you look?** The platform, its plugin and its policy — not global CPM health. Scope tells you that immediately, which is why scope comes first. **Q. A managed account keeps locking out. Do you reconcile?** Not automatically. Reconciliation fixes synchronisation, not the cause of the lockout. Find the source of the bad-password attempts first or you simply restart the lockout cycle. **Q. Why is a failed rotation an audit issue?** The control is “privileged passwords rotate every N days”. A failing account is evidence the control is not operating, and it ages further out of policy every day. That is a design-passes, operating-effectiveness-fails finding. # The portal, end to end > 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. *Follow one privileged access from search to expiry through the web front door, and understand why the portal being the only path is what makes every other control real.* **Track:** Operations **Priority:** essential **Time:** about 10 minutes **Topics:** PVWA, Portal, Retrieval, Justification, JIT **Walk it in the app:** https://pamsim.com/guides — guide id `pvwa-portal` ## The walkthrough A click-by-click walkthrough of the running application. Read as prose it still works: the steps carry the explanation, not just the navigation. ### Step 1 — The portal is the only front door *On page `/portal`.* The web access layer is where people search for accounts, justify why they need them, receive time-limited access, and launch sessions. It is also where administrators onboard accounts and where the REST endpoints for automation are exposed. The design principle is the important part: if a user can reach a privileged credential by any other route, then every control behind the portal — approval, recording, rotation, audit — is optional in practice. The portal being the only path is what makes the rest of it enforceable rather than aspirational. ### Step 2 — Find the account, not the password *On page `/portal`, element `portal:search`.* Search by name, target address, safe or platform. What comes back is scoped to you — an account in a safe you are not a member of does not appear, which means invisible and non-existent look identical from here. That is worth remembering when somebody says an account is missing. The first question is not 'was it deleted', it is 'are you a member of the safe, and do you hold List on it'. **Do this.** Search for an account and select one. ### Step 3 — What policy demands of this one *On page `/portal`.* Before anything is granted, the portal shows what this account's policy requires: whether a reason is mandatory, whether a ticket must be supplied, whether dual control applies, whether access is exclusive, how long a grant may last. Those requirements come from the platform and the Master Policy above it — not from the account itself. This screen is where an abstract policy layer becomes something a person actually experiences. ### Step 4 — Justification is evidence, not paperwork *On page `/portal`, element `portal:request`.* The reason written here is carried into the audit trail and is what makes a later session review meaningful. Reviewing a recording without knowing what the person said they were going to do tells you very little. Where ticket integration exists, the platform validates the ticket before releasing access — which turns 'who accessed this and why' into evidence an auditor accepts without anybody assembling it by hand. **Do this.** Fill in a request: a real justification, a time window, and a ticket reference if the policy asks for one. **What an interviewer is testing.** The point to make: the justification is not bureaucracy, it is the control that makes attribution useful rather than merely present. ### Step 5 — Retrieve or connect — and why it matters which *On page `/portal`.* Two different things happen behind two different buttons. Retrieval reveals the secret to a person, and from that moment it exists on their endpoint and in their memory. Connecting brokers a session in which the credential is injected and never shown. Prefer connecting wherever the workflow supports it. Retrieval stays legitimate — some tooling genuinely needs the value — but it is the more audited, more constrained path for a reason, and reducing how often it happens is a measurable programme goal. **What an interviewer is testing.** "Why use session brokering instead of just showing the password?" — because retrieval puts the secret on the endpoint, removes the single control point for monitoring and recording, and means rotation now has to chase a copy somebody is holding. ### Step 6 — The grant expires by itself *On page `/portal`.* An approved request creates a grant with a hard expiry. When the window ends the grant lapses without anybody remembering to revoke it — which is the difference between time-bound access and access somebody intended to remove. This is the mechanism underneath just-in-time access and zero standing privilege. The user holds nothing at rest, acquires privilege for a task, and returns to ordinary automatically. ### Step 7 — What the journey left behind *On page `/audit`, element `audit:filters`.* Every step wrote a record: the request, the decision, the retrieval or the session, the expiry. Filter the trail to the access category and read it as a sequence rather than as rows. That sequence is what a bank means by attribution. The target system only ever saw a shared administrative identity log on; the platform is what knows which person borrowed it, under which approval, for which stated reason. **Do this.** Filter the audit trail to the access category. ## What this prepares you to answer **Q. What is the PVWA and what is it for?** The web access layer — the portal where users search for privileged accounts, request access, retrieve credentials and launch sessions, where administrators onboard accounts and manage safes and platforms, and where the REST API is exposed. The design principle is that it is the only front door: if a credential is reachable any other way, the controls behind the portal are optional in practice. **Q. Walk me through requesting privileged access.** Search for the specific account, see what its policy demands — reason, ticket, dual control, exclusivity, maximum duration — and raise a request with a real justification and a time window. If dual control applies, a second person authorises it. The approval creates a grant with a hard expiry, and you connect through the session manager rather than retrieving the password where the workflow allows. Every step is audited, and the grant lapses on its own. **Q. When is retrieving a password legitimate rather than connecting?** When the workflow genuinely cannot use a brokered session — some tooling and some automation need the value itself. It stays available and is gated harder: reason or ticket required, more heavily audited, and often one-time so the credential rotates immediately afterwards. From a least-privilege and audit standpoint, brokered access is preferred wherever the use case supports it. **Q. A user says an account is missing from the portal. Where do you start?** Visibility is safe membership plus the List permission, so start there rather than assuming deletion. Are they authenticated to the right environment, are they a member of the safe directly or through a group that has actually synchronised, do they hold List, is the account really in the safe everybody assumes, and did a recent access review or recertification remove something. # A privileged session from click to recording > 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. *Follow the session path end to end — what the gateway does, the three separate controls it provides, and what happens after the session closes.* **Track:** Operations **Priority:** essential **Time:** about 10 minutes **Topics:** PSM, PSMP, Isolation, Recording, Monitoring **Walk it in the app:** https://pamsim.com/guides — guide id `psm-session` ## The walkthrough A click-by-click walkthrough of the running application. Read as prose it still works: the steps carry the explanation, not just the navigation. ### Step 1 — Three controls, not one *On page `/sessions`.* People collapse the session gateway into 'it records things'. It is three separable controls, and an auditor tests them separately. Isolation is preventive: the session runs from the gateway host, so the credential never lands on the user's endpoint and malware there cannot harvest it. Recording is detective: a replayable, searchable record for reconstruction and deterrence. Live monitoring and termination is responsive: somebody can watch an active session and cut it. They come apart. Isolating without recording leaves no evidence. Recording without isolation still exposes the credential. That is why they are three answers rather than one. **What an interviewer is testing.** "What is the difference between session isolation and session recording?" is a rapid-fire favourite precisely because the sloppy answer merges them. ### Step 2 — Start from an account you may use *On page `/accounts`, element `accounts:filters`.* The connect action appears where you hold Use on the safe. Notice that it does not require Retrieve — connecting and revealing are different permissions, and most people should have the first without the second. Find an account with a session-capable platform. The platform is what decides which connection components are available, so an account whose platform has none cannot broker a session no matter what your permissions say. **Do this.** Open an account you have access to. ### Step 3 — What happens when you click connect *On page `/accounts/1`, element `account:connect`.* Four steps, worth being able to recite. The request goes through the portal. The connection is redirected to the session gateway. The gateway retrieves the credential from the vault on your behalf. The gateway opens the connection to the target using the native protocol. You never hold the credential at any point. That is what makes the session controllable, monitorable and recordable — and it is why rotation is safe, because nobody is holding a copy that rotation would invalidate. **Do this.** Launch a session from the account. ### Step 4 — The live session view *On page `/sessions`, element `sessions:table`.* Active sessions with their user, account, target, protocol, source address and risk score. This is the operational picture — and the risk score updates as the session runs, because activity is scored as it happens rather than afterwards. A session that started as routine maintenance and turned into credential dumping raises its score while it is still open. That is the difference between monitoring and reporting. **Do this.** Look at the active sessions and their risk scores. ### Step 5 — Monitor, suspend, terminate *On page `/sessions`, element `sessions:table`.* Four actions, and they are not the same thing. Monitor opens a copy of the session to watch or take co-control, and the owner is notified. Suspend freezes it. Resume releases it. Terminate ends it. The judgement call worth having a view on: terminating a live session during an incident destroys what the person was about to do next. Sometimes watching for ninety seconds is worth more than cutting immediately — and sometimes it absolutely is not. Having a position on that trade-off is what the question is looking for. ### Step 6 — The recording is a searchable timeline *On page `/recordings`, element `recordings:search`.* Not just a video file. Individual activities are indexed and scored — commands typed in a shell, window titles in a desktop session, statements issued against a database — so a reviewer jumps to the interesting moment instead of watching an hour of idle desktop. Searchable command text matters more than video for audit purposes, and it is worth saying so: an auditor sampling a session wants to know what was executed, not to watch a screen recording. **Do this.** Search the recordings for a command rather than for a session. ### Step 7 — What happens after the session ends *On page `/cpm`, element `cpm:queue`.* Where the policy demands it, the credential rotates as soon as the session closes. Any value that was briefly in memory becomes worthless, and a one-time password model means the retrieval never becomes a standing credential. Look for post-session rotation jobs in the queue. This is the loop closing: broker the session, record it, rotate behind it. **Do this.** Find a job with a post-session trigger. ### Step 8 — PSM and PSMP — one idea, two components *On page `/platforms`, element `platform:connection`.* The Windows session manager is a jump server: your RDP client connects to it, and it runs the session for you on a Windows host, reached on 3389. The SSH one is a transparent proxy: you use your normal ssh client, it authenticates you, fetches the credential, opens the real session and records it, on port 22. They are separately deployed, separately hardened and separately capacity-planned — one on Windows, one on Linux. The SSH proxy covers SSH, SCP, SFTP and Rsync, and supports key authentication as well as passwords. The trap in an interview is treating them as one product with two names. The tell that you know better is the port: 3389 one way, 22 the other. ## What this prepares you to answer **Q. Walk me through what happens when a user connects through the session manager.** The user initiates access through the portal; the connection is redirected through the session gateway; the gateway retrieves the required credential from the vault; and the gateway connects to the target using the native protocol. The user never sees or holds the credential, which is what enables isolation, live monitoring and recording — and what makes rotation safe, because nobody is holding a copy. **Q. What is the difference between session isolation and session recording?** Isolation is preventive — the session runs from the gateway host so the credential never lands on the user's endpoint and malware there cannot harvest it. Recording is detective — a replayable, searchable record for forensic reconstruction and deterrence. They are separable: isolating without recording leaves no evidence, recording without isolation still exposes the credential, which is why an auditor tests them as two controls. **Q. How does the SSH session manager differ from the Windows one?** Same principle, different shape. The Windows one is a jump server — your RDP client connects to it and the session runs on a Windows host on 3389. The SSH one is a transparent proxy on port 22 — you use your native ssh client, and it authenticates you, fetches the credential, opens the session and records it. It runs on Linux, covers SSH, SCP, SFTP and Rsync, and supports key authentication. Separate components, separately deployed and hardened. **Q. You see a high-risk live session. Do you terminate it?** Not reflexively. Terminating destroys what the person was about to do next, which may be the evidence you need. Monitor first if the risk allows it, preserve the recording, and terminate when the activity is clearly damaging or the account is clearly compromised. Having a position on that trade-off — rather than a rule — is the answer. # The password works but the session fails > 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. *Diagnose the session path without touching the credential — and know why rotating would be the wrong move.* **Track:** Operations **Priority:** essential **Time:** about 8 minutes **Topics:** PSM, Troubleshooting, Session path **Walk it in the app:** https://pamsim.com/guides — guide id `session-troubleshooting` ## The walkthrough A click-by-click walkthrough of the running application. Read as prose it still works: the steps carry the explanation, not just the navigation. ### Step 1 — First: do not rotate *On page `/sessions`.* Retrieval works, so the credential is fine. Rotating it changes nothing about the session path and destroys the only known-good thing you had. This is a set-piece interview question precisely because the wrong instinct is so common. **What an interviewer is testing.** “Password retrieval works but PSM fails — which path is broken, and what do you NOT do?” The session path, and you do not rotate the password. ### Step 2 — Walk the session path in order *On page `/sessions`, element `sessions:table`.* User authentication and the Use permission. Then the portal — does it show the account, and does the connect action launch? Then the PSM service itself, plus any hardening or application-control rule blocking the connector, and the assigned connection component. Then target reachability from the PSM host — not from your laptop. DNS, firewall, and whether RDP or SSH is actually running. Then the target account's state. ### Step 3 — Connection components live on the platform *On page `/platforms`.* The platform decides which session types the gateway can broker. If the connection component for a protocol is not assigned, the connect action will not offer it — and that looks like a failure when it is configuration. **Do this.** Open a platform and look at its connection components. ### Step 4 — Where the break can be *On page `/lookup?account=linux-root-prod`, element `account:connect`.* Four places, and naming which one is the whole job: before credential retrieval, during connector launch, in network transport, or at target authentication. In a real deployment you correlate the PSM console log with the per-session connection-component and recorder logs, and with the target's own authentication log. **Do this.** Open an account and click Connect. Notice the dialog offers only the protocols its platform supports. ### Step 5 — PSM works to Windows but fails to Linux *On page `/sessions`.* A common variant. That points at protocol, connector, the SSH target itself, or network and host configuration — not at anything shared, because the shared parts are evidently working. PSM for SSH is a distinct component, usually written PSMP, and it covers SSH, SCP, SFTP and Rsync. ### Step 6 — Ports worth knowing cold *On page `/sessions`, element `sessions:table`.* 22 SSH and PSMP. 53 DNS — resolution failures masquerade as authentication failures. 80 and 443 for the portal and REST. 88 Kerberos. 389 and 636 LDAP and LDAPS. 445 SMB, used by the CPM for Windows changes. 1858 the vault's proprietary protocol. 3389 RDP and PSM. Being able to say “the CPM changes Windows passwords over SMB on 445” is a small detail that lands well. ## What this prepares you to answer **Q. Retrieval works but the PSM session fails. What do you check, and what do you avoid?** Avoid rotating the password — the credential is demonstrably fine. Check user authentication and the Use permission, then the portal, then PSM service health and any hardening rule blocking the connector, then the assigned connection component, then reachability from the PSM host, then the target account state. Correlate the PSM console, connector and recorder logs with the target's auth log. **Q. Sessions to Windows work but Linux fails. Where do you look?** Protocol, connector, the SSH target and its network path. The shared components are evidently working, so the fault is in the parts that differ. PSM for SSH is a separate component. **Q. Which ports matter in a PAM deployment?** 22 for SSH and PSMP, 53 DNS, 80/443 for PVWA and REST, 88 Kerberos, 389/636 LDAP and LDAPS, 445 SMB for Windows password changes, 1858 for the vault's proprietary protocol, 3389 for RDP. # Take a hardcoded credential out of an application > 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. *Use the credential provider: register an application, understand how it is authenticated, diagnose a refusal, and know when a remediation is only half done.* **Track:** Operations **Priority:** essential **Time:** about 11 minutes **Topics:** AAM, Credential Provider, CCP, Hardcoded credentials, Dependencies **Walk it in the app:** https://pamsim.com/guides — guide id `application-credentials` ## The walkthrough A click-by-click walkthrough of the running application. Read as prose it still works: the steps carry the explanation, not just the navigation. ### Step 1 — The other half of privileged access *On page `/applications`.* Everything else in the platform assumes a human who can be shown a portal and asked to justify themselves. Applications cannot do that, and they need privileged credentials constantly — a database password, a service account for a scheduled task. Left alone those live in config files and deployment scripts, where they never rotate, because rotating them breaks something. That is the single largest population of privileged credentials in most banks, and the one an interviewer will ask how you would fix. **What an interviewer is testing.** Candidates describe the human workflow well and then stop. Bringing up application credentials unprompted marks you out immediately. ### Step 2 — Read the estate *On page `/applications`, element `applications:filters`.* Five registrations, and the authentication column is the thing to look at. It rates how hard each one is to impersonate, derived from the rules attached to it. PaymentsGateway-Prod is strong: host, OS user, path and executable hash. LegacyReporting is weak: address only. Both took their password out of a config file — only one of them actually finished the job. **Do this.** Filter by weak authentication. ### Step 3 — Why address-only is barely a control *On page `/applications?app=LegacyReporting`, element `application:rules`.* Open LegacyReporting. Its single rule says the request must come from app-rpt-01. Every process on that host presents the same address, so any of them can ask for the credential — including whatever an attacker runs after landing there. The credential moved from a config file to the vault, which is real progress: it can rotate now, and every retrieval is audited. But the thing protecting it is a foothold on one server. **What an interviewer is testing.** This is the nuance that separates someone who has deployed it from someone who has read about it. The answer is not 'AAM fixes hardcoded credentials'; it is 'AAM fixes them if the application identity is actually hard to forge'. ### Step 4 — The rules, weakest to strongest *On page `/applications?app=PaymentsGateway-Prod`, element `application:rules`.* Machine address narrows an attacker to anyone on that host. OS user helps only if the account is dedicated to the application. Executable path stops a copy of the binary dropped in a temp directory. Executable hash is the strong one — an attacker running as the right user from the right place still cannot produce a matching binary. Hash also breaks on every legitimate release, which is why teams quietly remove it. Worth asking, in a real job, whether it is still enabled on the registrations that claim it. **Do this.** Open an application and read its rules. ### Step 5 — Make a request as the application *On page `/applications?app=PaymentsGateway-Prod`.* Open PaymentsGateway-Prod and choose Request a credential. The form is prefilled with what a correct caller looks like, so the first send succeeds. Send it and read the rule-by-rule result. Now change one thing — the OS user, or a character of the hash — and send again. The provider names the rule that failed and shows what was presented against what was expected. That output is the whole reason this component generates support tickets, and reading it is the job. **Do this.** Send a correct request, then break one property and send again. ### Step 6 — Two different refusals *On page `/applications?app=PaymentsGateway-Prod`.* In the object list, choose the entry for an account the application is not provisioned for. The refusal is different in kind: authentication passed, and the application was never granted that object. That distinction is the first question to answer on any provider ticket. 'We do not believe you are who you say' is a rules problem on the host. 'We believe you and you were never given this' is safe membership — the AppID must be a member of the safe with Retrieve, exactly like a person. **What an interviewer is testing.** Being able to split the two before touching anything is what makes the triage fast, and it is a very natural thing for an interviewer to probe. ### Step 7 — Diagnose the one that is actually broken *On page `/applications`.* Open MonitoringCollector. Eighty-four refusals in seven days, and no successes: it now calls from mon-02 while its registration still names mon-01. The host moved during a datacentre migration and nobody updated the registration. This is the commonest real failure by a distance, and it is worth noticing that it presents as an application outage, not a security event — the team whose collector stopped working raises the ticket. Fix it by correcting the machine rule, then use the simulator to confirm before you close it. **Do this.** Fix the machine rule, then test the request without recording it. ### Step 8 — The registration is also the off switch *On page `/applications`.* DecommissionedETL is disabled rather than deleted. It refuses every request while keeping its retrieval history for the audit — which is what you want when an application is retired, since the question 'what did it access, and when did it stop' still has to be answerable. Disabling is also the fastest containment when an application identity is suspected: it cuts the credential off without touching the account that other things depend on. ### Step 9 — Now look from the account's side *On page `/lookup?account=svc_sql_backup`, element `account:tabs`.* A service account's applications are its dependency list. Before rotating one, that list is what tells you what might break — and after a rotation that caused an outage, it is where you look first. This is the connection between the two halves. An application registered with the provider does not break on rotation, because it fetches the new value on its next call. Anything still holding a copy does. **What an interviewer is testing.** 'How do you rotate a service account safely?' The answer is: know its dependencies, move them onto runtime retrieval so there is nothing to break, and only then shorten the interval. ## What this prepares you to answer **Q. How do you get a hardcoded credential out of an application?** Register the application with the credential provider, provision it against the account, and change the application to request the secret at runtime instead of reading a config file. Because it then holds nothing, the credential becomes free to rotate — which is the actual goal; removing the string from the file is only the visible part. **Q. How does the provider know the caller really is that application?** By properties of the calling process, checked against the registration: the machine it runs on, the OS account it runs as, the full path of the executable, a cryptographic hash of the executable, or a client certificate for the agentless path. Combine them — hash plus OS user plus path is genuinely hard to forge, and any one alone is not. **Q. What is the difference between CP and CCP?** CP is an agent on the application server: local call, direct inspection of the calling process, and it caches so retrieval survives a network outage. CCP is agentless — an HTTPS call to a REST endpoint — which is the only option for containers, appliances and hosts rebuilt from an image, at the cost of a network dependency and identity that rests on a client certificate rather than process inspection. Choose CP where you control the host and uptime matters; CCP where you cannot install anything. **Q. An application identified only by its IP address — what is wrong with that?** Every process on that host presents the same address, so anything running there can impersonate the application and retrieve the credential. The password moved out of the config file, which is real progress, but it is now protected by nothing stronger than a foothold on one server. Add a path and an executable hash. **Q. An application suddenly cannot get its credential. How do you triage?** First split authentication from provisioning: did the provider refuse to believe the caller, or believe it and find no grant? Authentication failures are almost always a property that changed on the host — most often the machine, after a migration or a rebuild, and after that a hash following a release. Provisioning failures are safe membership. Test the fix before closing, and do it without writing to the retrieval history you are reading. **Q. Why is the credential provider relevant to rotation?** Because it removes the reason not to rotate. A service account whose consumers all fetch at runtime can be rotated on a short interval with nothing to co-ordinate; one with a copy in a config file cannot be rotated at all without a change window. The registrations against an account are its dependency list, and shortening the interval before that list is empty is how a successful rotation still causes an outage. # Secrets for workloads, not people > 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. *Understand the cloud-native model: identity borrowed from the platform, secrets minted on demand with an expiry, and access defined as policy in version control.* **Track:** Operations **Priority:** high **Time:** about 12 minutes **Topics:** Secrets Manager, Dynamic secrets, Workload identity, Kubernetes, Policy as code **Walk it in the app:** https://pamsim.com/guides — guide id `workload-secrets` ## The walkthrough A click-by-click walkthrough of the running application. Read as prose it still works: the steps carry the explanation, not just the navigation. ### Step 1 — A different model, not a second vault *On page `/secrets`.* The vault assumes a credential that exists between uses: stored, rotated, and controlled by how often you change it. That is right for a domain administrator and a network switch, and it fits badly around containers and pipelines that appear and disappear faster than any rotation schedule. Two things change here. Identity comes from the platform the workload already runs on. And many secrets are minted per request with an expiry, so there is nothing stored and nothing to rotate. **What an interviewer is testing.** The trap is describing this as 'a vault for the cloud'. Naming the two actual differences — platform identity and dynamic secrets — is what shows you understand why it exists. ### Step 2 — How a workload proves what it is *On page `/secrets`, element `secrets:filters`.* Look at the authenticator column. The bootstrapping problem is that to fetch a secret you must authenticate, and if that needs a credential you have only moved the problem. Every authenticator except the last solves it by borrowing an identity something else already established. Kubernetes signs a service-account token the kubelet mounts into the pod. AWS confirms which role signed the request. An OIDC provider signs a token for one pipeline run. Nothing had to be placed on the host for any of these. **Do this.** Filter to the long-lived key workload and read why it is the odd one out. **What an interviewer is testing.** 'How does a pod authenticate without a secret?' Answer with the claim and who vouches for it — the cluster signs the token, the authenticator trusts the cluster. ### Step 3 — Claims are the policy *On page `/secrets?workload=prod/payments-api`, element `workload:claims`.* Open the payments API. Its policy requires a namespace, a service account and a cluster. The service account is the real identity; namespace and cluster are the boundaries that stop a workload in development presenting the same name as production. A trailing asterisk makes a claim a prefix match, which is how a pipeline rule covers every branch under a path without listing them — and also how a rule written carelessly ends up covering forks. ### Step 4 — Secretless — the application never sees it *On page `/secrets?workload=prod/payments-api`.* This workload's injection method is the Secretless broker. The pod holds no credential at all: the broker opens the database connection and the application talks to a local socket. Worth contrasting with the alternatives on the other workloads. A sidecar refreshes the secret so rotation needs no restart, but the value does reach the application's memory. Summon injects environment variables, which anything reading the process table can see. An init container fetches once, so a rotated secret waits for the next restart. Secretless is the only one where there is nothing to leak, log or commit. **What an interviewer is testing.** Being able to rank the injection methods by what they expose — and say which you would pick for a service handling card data — is a strong, specific answer. ### Step 5 — Fetch a dynamic secret and watch it expire *On page `/secrets?workload=ci/deploy-pipeline`.* Open the deployment pipeline and choose Authenticate and fetch. It is permitted on the AWS deployment role, which is dynamic: nothing is stored, so the fetch mints a credential and starts a clock. The result shows a lease identifier and a live countdown. That identifier is what you would search AWS's own logs for. When the countdown reaches zero the credential is gone — no rotation was scheduled, and nothing was left behind. **Do this.** Fetch the deployment role and watch the countdown. ### Step 6 — The lease is the unit of management *On page `/secrets?tab=leases`, element `secrets:leases`.* Every issued dynamic secret appears here with its own expiry. Most have already expired on their own, which is the normal state of affairs and the point of the model. Revoking is the containment action. If a pipeline run is compromised you do not change a password, because there is no password — you invalidate the credential that was minted, and everything else keeps working. **Do this.** Revoke a live lease and watch it drop out of the active count. **What an interviewer is testing.** 'A build server is compromised, and it had cloud credentials. What do you do?' If those credentials were dynamic, the answer is short: revoke the leases and the exposure ends. That contrast is exactly why the model exists. ### Step 7 — Diagnose the one that is failing *On page `/secrets?workload=staging/payments-api`.* The staging copy has been refused for a week. It was redeployed into a renamed namespace during a cluster upgrade, and the policy still names the old one — so every token it presents fails on the namespace claim. This is the commonest real failure in this model, and it is the same shape as the credential provider's migrated host: the workload moved and the policy did not. It presents as an application outage, not a security event. **Do this.** Use the fetch simulator to reproduce the refusal, then correct the claim. ### Step 8 — Authentication versus authorisation, again *On page `/secrets?workload=prod/payments-api`.* In the simulator, pick a secret from the 'not permitted' group. Every claim passes and the request is still refused — the platform vouched for the workload, and policy simply grants it nothing on that variable. Same split as everywhere else in privileged access. One is 'we do not believe you are what you say', the other is 'we believe you and you were never given this'. They send you to different files, and telling them apart before touching anything is what makes the triage quick. ### Step 9 — It is all policy in version control *On page `/secrets`, element `secrets:policy`.* Choose View as policy. The same workloads, secrets and grants expressed declaratively — hosts with their claims, variables with their TTLs, and permit statements joining them. In a real deployment this file is the source rather than a report: granting a workload access to a secret is a commit, reviewed like any other code. That is what makes 'who can read this secret' answerable with grep instead of a screenshot, and what makes rebuilding an environment a load rather than an afternoon of clicking. **Do this.** Open the policy view and find the permit block for the payments API. **What an interviewer is testing.** Policy as code is the answer to the audit question 'show me everyone who can read the production database password'. A console cannot answer it well; a repository can. ### Step 10 — Why the vault does not go away *On page `/secrets?tab=secrets`.* One secret here is marked as synced from the vault, and links to the account it mirrors. A target has to support minting and destroying credentials for a dynamic secret to be possible — a mainframe or a network switch cannot, so those stay static and stay in the vault. Real estates run both and synchronise the static ones so a credential has a single source of truth. Claiming the secrets manager replaces the vault is a wrong answer with a confident tone. ## What this prepares you to answer **Q. How is a secrets manager different from a vault?** Two things. Identity comes from the platform the workload runs on rather than from a credential you place there — a Kubernetes service-account token, an IAM role, a signed OIDC token — which solves the bootstrapping problem. And many secrets are dynamic: minted per request with a TTL and destroyed at the end of the lease, so nothing exists between uses. It complements the vault rather than replacing it, because a target that cannot mint credentials on demand has to stay static. **Q. How does a pod authenticate without already having a secret?** The kubelet mounts a service-account token signed by the cluster. The authenticator trusts the cluster and reads the claims: namespace, service account, and which cluster vouched. Nothing had to be distributed, which is the whole point — the alternative is a bootstrap credential in an image, which is the problem you were trying to solve. **Q. What is a dynamic secret and why does it matter?** A credential generated when it is asked for and destroyed when its lease expires — a short-lived STS credential, or a database user created with the right grants and dropped afterwards. There is no rotation to schedule and no standing credential to steal, and a leaked build log is worthless by the time anyone reads it. What you manage is the lease. **Q. A build server is compromised and it held cloud credentials. What do you do?** If they were dynamic, revoke the leases — the credentials become invalid immediately and there is no password to change. Then check what was minted while the compromise was live, using the lease identifiers to search the cloud provider's own logs. If they were static and long-lived, the answer is much longer, and that contrast is the argument for the model. **Q. What is Secretless and when would you use it?** An injection pattern where the application never receives the secret: a broker holds the credential, opens the connection, and the application talks to a local socket. Nothing can be leaked, logged or committed because the process never has it. It is the strongest of the injection options, and the one to reach for on anything handling regulated data — as against a sidecar, which refreshes on rotation but does put the value in the application's memory, or Summon, which exposes it in environment variables. **Q. Why does policy as code matter here?** Because access becomes a reviewable commit rather than a console click, the whole estate is diffable, and rebuilding an environment is a load. It also makes the audit question answerable: 'show me everyone who can read the production database password' is a grep against a repository rather than a screenshot of a permissions dialog. # Service accounts and their dependencies > 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. *Understand why a successful rotation can still cause an outage, and how to onboard a service account without one.* **Track:** Operations **Priority:** essential **Time:** about 9 minutes **Topics:** Service accounts, Dependencies, Change control, Discovery **Walk it in the app:** https://pamsim.com/guides — guide id `service-accounts` ## The walkthrough A click-by-click walkthrough of the running application. Read as prose it still works: the steps carry the explanation, not just the navigation. ### Step 1 — The problem in one sentence *On page `/safes`.* A service account's password is not only a secret — it is a dependency. It is embedded in Windows services, scheduled tasks, IIS application pools, COM+ components, scripts, database connection strings and application config files. The vault updates successfully, and every unmapped dependency keeps presenting the old password until something locks out or falls over. **What an interviewer is testing.** “The rotation succeeded but the application broke — what happened?” Almost always a service account with an unmapped dependency. Then: do not rotate again. ### Step 2 — Look at the service accounts here *On page `/accounts?type=Service+Account`.* Notice how they cluster: the longest password ages, the most rotation failures, and the notes describing downstream consumers. That is not an accident of the demo data — it is what service accounts look like in every estate. **Do this.** Filter the accounts list to Service Account and sort by password age. ### Step 3 — Read the Dependents pane *On page `/lookup?account=svc_exchange`, element `account:tabs`.* On the Overview tab, Dependents shows other managed accounts sharing the same target. Real dependency mapping goes much further — every place the credential is cached — but the principle is the same: know what breaks before you change it. **Do this.** Open a service account and read its Dependents pane and its notes. ### Step 4 — What must exist before automatic rotation is enabled *On page `/accounts?type=Service+Account`.* A named owner. A complete inventory of every location where the credential is cached or stored. Documented expected authentication behaviour per dependency. A defined recovery procedure. And a testing plan that has actually been executed. If any of those is missing, the account is not ready for automatic management — it is ready for monitoring. ### Step 5 — The phased rollout *On page `/cpm`.* Import without rotation first, and monitor. Then a pilot rotation in a scheduled change window with the owner watching. Only then scheduled automatic management. The reason is political as much as technical: an owner who has watched PAM cause an outage will never trust the platform again, and you will spend two years getting that system back. **What an interviewer is testing.** “Do not bulk-import” is described as the opening of a strong answer. Say it, then give the three phases. ### Step 6 — A vault success is not a rotation success *On page `/cpm`, element `cpm:queue`.* After rotating, confirm the dependent services restarted and re-authenticated, watch for the next health check or heartbeat, and check the target's authentication log for lingering failures with the old password. Close the incident only when you have evidence the new credential is actually in use. ### Step 7 — When an application genuinely cannot rotate *On page `/accounts?type=Service+Account`.* Vault it anyway. Lengthen the interval, enable exclusive access, force brokered sessions, tighten monitoring and alert on every use. Record it as an accepted risk with a named owner and a review date. Never let “cannot rotate” quietly become “not managed”. That sentence is worth memorising. **What an interviewer is testing.** This is the compensating-control question. The structure of the answer — vault, compensate, document, review — matters more than the specific controls you list. ### Step 8 — The Active Directory angle *On page `/accounts?type=Service+Account`.* Service accounts with SPNs are Kerberoastable, so password strength matters more than usual. Delegation settings are worth checking. Password ages are frequently measured in years. And the modern fix is worth naming: group managed service accounts rotate themselves. ### Step 9 — Two hundred accounts nobody owns *On page `/discovery`, element `discovery:findings`.* This is the scenario, and the first instinct is the wrong one. Do not disable them. That is the outage, and it is the instinct that gets privileged access programmes shut down — because the one you disable will be the one holding a payment batch together. Inventory and classify instead: by privilege, and by what each one touches. Then use authentication logs to separate live from dormant, which is the split that decides everything after it. **Do this.** Read the findings and note what evidence each carries about actual use. ### Step 10 — Dormant, live, and the intake fix *On page `/discovery`, element `discovery:filters`.* Dormant with no activity over a defined window: disable with a rollback window, then delete. The rollback window is the part that makes it safe — you are not deleting, you are proving nothing breaks first. Live but unowned: trace the systems it authenticates to in order to find the owning application, assign a named owner, then vault and onboard. Tracing authentication is how ownership is actually discovered, because nobody will volunteer. Then fix the intake, or you will do this again in two years: no new service account without a named owner, a stated purpose and a review date. **What an interviewer is testing.** The answer has three beats — do not disable, classify by live against dormant using authentication logs, and fix the intake. Candidates who only do the middle one have solved today's problem and none of next year's. ## What this prepares you to answer **Q. You find 200 service accounts nobody owns. What now?** Do not disable them — that is the outage, and the instinct that gets programmes shut down. Inventory and classify by privilege and by what they touch. Use authentication logs to separate live from dormant. Trace the systems they authenticate to in order to find owners. Dormant with no activity over a defined window: disable with a rollback window, then delete. Live but unowned: identify the owning application, assign a named owner, vault and onboard. Then fix the intake — no new service account without a named owner, purpose and review date. **Q. A password rotated successfully but the application broke. What happened and what do you do?** A service account with a dependency nobody mapped — a service, scheduled task, app pool, connection string or config file still presenting the old password. Do not rotate again. Establish whether the new password works on the target, identify the dependency state, restore service under change control, then map dependencies before re-enabling automatic rotation. **Q. How do you safely bring a service account under management?** Map its dependencies and find a named owner first. Import without rotation and monitor. Pilot one rotation in a change window with the owner watching. Then enable scheduled management. Never bulk-import service accounts. **Q. The application team says this account cannot be rotated. What do you do?** Vault it regardless, then compensate: longer interval, exclusive access, brokered sessions only, tighter monitoring, alert on every use. Record it as an accepted risk with a named owner and a review date. Never let “cannot rotate” become “not managed”. **Q. What makes AD service accounts particularly risky?** SPNs make them Kerberoastable so password strength matters, delegation settings can widen their reach, and their passwords are often years old. Group managed service accounts solve the rotation problem by rotating themselves. # Use without Retrieve, and access triage > 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. *Grant the right level of access, and diagnose the two complaints you will hear constantly: cannot see it, or can see it but cannot connect.* **Track:** Operations **Priority:** essential **Time:** about 8 minutes **Topics:** Safe permissions, Least privilege, RBAC, Triage **Walk it in the app:** https://pamsim.com/guides — guide id `permissions-triage` ## The walkthrough A click-by-click walkthrough of the running application. Read as prose it still works: the steps carry the explanation, not just the navigation. ### Step 1 — Two layers, both must permit *On page `/roles`, element `roles:matrix`.* The role decides what kind of thing you may do at all. Safe membership decides which resources you may do it to. An action succeeds only when both allow it. Read the matrix and notice the deliberate separations: an auditor sees everything and can retrieve nothing; the PAM administrator who operates the vault is not an approver. **What an interviewer is testing.** Segregation of duties is a banking control, not a nicety. Requester, approver and reviewer must be different people, and you should say so unprompted. ### Step 2 — The permission ladder *On page `/safes`.* List — can see the account exists. Use — can connect through the session manager without seeing the credential. Retrieve — can reveal the password itself. The goal state for almost everyone is Use without Retrieve. Being able to say that phrase, and why, is described as showing you have actually administered the product. ### Step 3 — Grant on the safe *On page `/lookup?safe=Windows Servers`, element `safe:tabs`.* Open a safe and look at its members. Every grant is on the container, and every account inside inherits it. That is why moving an account between safes is a significant, audited action: it silently changes who can use that credential. **Do this.** Open a safe and switch to the Members tab. ### Step 4 — Triage: “I cannot see the account” *On page `/lookup?safe=Windows Servers`, element `safe:tabs`.* Work the ladder from the bottom. Are they authenticated to the right environment? Are they a member of the safe, directly or through a group that has actually synchronised? Do they hold List? Is the account really in the safe everyone assumes it is in? Did a recent access change or recertification remove something? That last one catches a surprising number of tickets right after an access review. ### Step 5 — Triage: “I can see it but cannot connect” *On page `/lookup?account=linux-root-prod`, element `account:connect`.* Now it is Use permission, then the platform's connection component and PSM service health, then target reachability, then the target account's own state — locked, disabled or expired — then credential synchronisation, then the session logs. Notice this is the session path again. Same ladder as the session troubleshooting walkthrough. ### Step 6 — Remediation: “they should not be able to reveal the password” *On page `/lookup?safe=Windows Servers`, element `safe:tabs`.* Remove Retrieve at the safe level — and then check object-level permissions, because a grant can exist there too and will survive the safe-level change. Forgetting the second half is a real and common mistake. ### Step 7 — Exclusive access makes shared accounts attributable *On page `/lookup?account=linux-root-prod`, element `account:credential-actions`.* Locking a credential for exclusive use means one holder at a time, and it rotates on check-in. That is what turns a shared administrator account into something you can attribute to a person. In a bank you would mandate exclusive access on shared privileged accounts almost by default, and apply dual control by risk — approval latency makes people route around controls they consider excessive. **Do this.** Lock an account for exclusive use, then release it. Watch the audit events both actions produce. ## What this prepares you to answer **Q. What is Use without Retrieve, and why does it matter?** Use lets someone connect through the session manager without ever seeing the credential; Retrieve reveals it. Use without Retrieve is the goal state for almost everyone, because it keeps the secret inside the platform while people still get their work done. **Q. A user says they cannot see an account. How do you triage it?** Work the ladder: right environment, safe membership directly or through a synchronised group, the List permission, whether the account is actually in that safe, and whether a recent access change or recertification removed something. **Q. How do you stop someone revealing a password they can currently see?** Remove Retrieve at the safe level, then check object-level permissions — a grant there survives the safe-level change and is the usual reason the fix appears not to work. **Q. How do you make a shared admin account attributable?** Exclusive access — one holder at a time, checked out and checked in, with rotation on check-in. Combined with brokered sessions and recording, that ties every use to a named person. # Automate it, and read the status code > 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. *Work the REST interface end to end — authenticate, call, and produce every status code that matters — so 401 against 403 is something you have done rather than something you memorised.* **Track:** Operations **Priority:** high **Time:** about 12 minutes **Topics:** REST API, Automation, Status codes, 401 vs 403, Least privilege **Walk it in the app:** https://pamsim.com/guides — guide id `rest-api` ## The walkthrough A click-by-click walkthrough of the running application. Read as prose it still works: the steps carry the explanation, not just the navigation. ### Step 1 — Why any of this is automated *On page `/rest-api`, element `rest:endpoints`.* Everything done by hand in the portal is available programmatically: creating accounts, safes and members, triggering rotations, extracting evidence. That is what makes onboarding five hundred discovered accounts possible, and what turns a quarterly access review into a scheduled extract rather than three days of clicking. The sequence never changes. Authenticate, receive a token, send that token on every call, check the status and the body, log off. ### Step 2 — Authenticate, and then break it deliberately *On page `/rest-api`, element `rest:request`.* Send the authentication call as yourself and note that the response carries a session token. Every other endpoint needs it in the Authorization header. Now change the username to something that does not exist and send it again. That is a 401 — authentication failed, you never got in. Produce it on purpose once and it stops being abstract. **Do this.** Send Authenticate as yourself, then again with a username that does not exist. ### Step 3 — A call that works, and a filter that does not *On page `/rest-api`, element `rest:response`.* Authenticate again so you hold a valid token, then list accounts. Add a filter in the documented form — safeName eq followed by a safe name — and see it narrow the result. Then put something arbitrary in the filter field. That is a 400: the request itself is malformed, so the server never got as far as deciding whether you were allowed. Retrying it unchanged will fail identically, and escalating to the platform team achieves nothing. **Do this.** List accounts with a valid filter, then with an invalid one. ### Step 4 — Absent, or invisible *On page `/rest-api`, element `rest:response`.* Fetch a single account by its identifier, then fetch identifier 9999. The 404 means the object does not exist — or exists and is not visible to you, which in a permission-scoped API looks identical from the outside. That ambiguity is worth naming. If an administrator can list the object and your call returns 404, it is a visibility problem wearing a 404, and the fix is safe membership rather than a corrected identifier. **Do this.** Get a real account, then get account 9999. ### Step 5 — The one the interview is actually about *On page `/rest-api`, element `rest:diagnosis`.* Try to retrieve a password. Depending on the identity you are signed in as, this either returns the secret or returns 403 — because the console signs each call as you, and the permission check is the same one the rest of the platform uses. A 403 here is Use-without-Retrieve working exactly as designed: authenticated, and not permitted to reveal this. The same identity can still connect through the session manager. Switch identity from the profile menu and send the identical call again to watch the answer change. **Do this.** Send Retrieve a password. Then switch identity and send it again. **What an interviewer is testing.** 401 is about who you are. 403 is about what you may do. Never troubleshoot safe permissions on a 401, and never regenerate a token on a 403 — the token was fine. ### Step 6 — Conflict, and why it is often success *On page `/rest-api`, element `rest:response`.* Try to onboard an account using the username and address of one that already exists. That is a 409: a well-formed request the current state refuses. For a re-runnable onboarding script this is usually a success case, not a failure — the account is already there, which is what you wanted. The wrong instinct is to generate a new name to get past it, and that is how an estate ends up holding svc-app01, svc-app01-2 and svc-app01-new. **Do this.** Send Onboard an account with details that duplicate an existing one. ### Step 7 — Throttling and server faults *On page `/rest-api`, element `rest:request`.* Send the same call repeatedly and you will start receiving 429. Bulk jobs meet this long before anything else breaks, and the correct response is exponential backoff honouring Retry-After — retrying immediately extends the window you are being throttled in. Now tick the fault injection box and send anything. That is a 5xx: nothing in your request will fix it. Correlate the timestamp with component and server logs, retry with bounded backoff, and stop — a component that is already failing does not need your loop on top of it. Both say 'not now', and only one is your fault. That is why they need different handlers. **Do this.** Send the same call about a dozen times to reach 429, then tick fault injection for a 500. ### Step 8 — The whole set, in one place *On page `/rest-api`, element `rest:tabs`.* 400 the request. 401 authentication. 403 authorisation. 404 the object. 409 the state. 429 throttling. 5xx the server. Each names a different layer, and the value of knowing them is that each sends you somewhere different. Read the confusion note on each one — that is where the marks are. The pairs that get mixed up are 401 with 403, and 404 with 403, and 429 with 5xx. **Do this.** Read the status code reference tab. ### Step 9 — What makes automation safe rather than clever *On page `/rest-api`, element `rest:request`.* Nobody is testing whether you can write a loop. A dedicated identity per integration so activity is attributable. The minimum permissions the workflow needs — never an administrator as a workaround for a 403. The script fetching its own credential at runtime from an approved mechanism rather than holding one. Then the operational half: re-runnable so a partial failure can be repeated safely, input validated before it writes, backoff on 429, a dry-run mode where practical, a rollback path, an audit report of what it did, and never writing a token or a secret into a log. Finally, log off. A script that authenticates in a loop and never logs off exhausts the session limit, and the resulting failure looks exactly like an outage. **Do this.** Send Log off, then send any other call to confirm the token is now rejected. ## What this prepares you to answer **Q. What is the difference between a 401 and a 403?** 401 means authentication failed or the token is missing, expired or invalid — you never got in. 403 means you are authenticated and the identity lacks the vault authority or safe permission the endpoint requires. They send you to different places: do not troubleshoot safe permissions on a 401, and do not keep regenerating a token on a 403 because the token was never the problem. **Q. Your automation gets a 403 on adding an account. What do you do?** First confirm it really is authenticated — if it were an authentication failure I would expect a 401. With a valid session and a 403, I move to authorisation: identify which object the call is touching and compare the caller's vault and safe permissions against what the endpoint documents, because adding an account and adding safe membership are separate authorities. I would test the minimum read call needed to isolate the scope rather than making the API identity over-privileged as a workaround. **Q. How would you protect an API automation account?** Least privilege — the minimum vault and safe permissions the workflow needs, never an administrator identity as a shortcut. A dedicated identity per integration so activity is attributable. The automation fetches its own credential from an approved mechanism rather than holding it in source or config. Restricted network paths, full audit of its calls, rotation of its credential, and alerting when it is used outside its expected pattern. **Q. How would you onboard five hundred discovered service accounts?** Not as a bulk import. Classify first — platform, environment, owner, criticality, and whether each is interactive, service or machine — and use authentication logs to separate live from dormant. Agree safe and platform standards and the reconcile design, pilot a representative handful across account types with dependencies and session access explicitly tested, then automate the rest through the API in controlled batches with field validation, duplicate rejection, an audit report, health checks, a rollback path and no secrets in logs. Onboard in monitor-only first and rotate later. **Q. What do you do about a 429?** Back off exponentially and honour Retry-After rather than retrying immediately, which just extends the throttling window. Then ask whether the job should be paging or batching instead of looping. It is different from a 5xx: both say not now, but a 5xx is a server-side failure to correlate against component logs, and only one of the two is caused by what you are doing. # Reduce standing privilege without breaking the business > 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. *Run the programme play rather than the technical one: measure first, cut the safe tranche, make the replacement fast enough that nobody routes around it.* **Track:** Operations **Priority:** high **Time:** about 10 minutes **Topics:** ZSP, JIT, Adoption, Metrics, Change management **Walk it in the app:** https://pamsim.com/guides — guide id `reduce-standing-privilege` ## The walkthrough A click-by-click walkthrough of the running application. Read as prose it still works: the steps carry the explanation, not just the navigation. ### Step 1 — Measure before you cut *On page `/risk`.* The instinct is to remove standing rights and see who complains. That is how a programme gets stopped after the first outage, and it is the wrong order. Pull actual usage first: who exercises standing rights, how often, and against what. In most estates the majority of standing privilege is never used at all — and that unused majority is your safe first tranche, because removing it changes nothing for anybody. **What an interviewer is testing.** The measurement step is the answer. Anyone can say "move to just-in-time"; saying which accounts you would take first, and why that set is safe, is what shows you have done it. ### Step 2 — Find the people who never use it *On page `/users`.* Identities here carry their access patterns. Look for the shape you are hunting: privileged entitlements held permanently and exercised rarely or never. Those are the conversations that go well, because you are removing something the person does not use and replacing it with something that works when they do. The users who exercise privilege daily are a later tranche and a different conversation. ### Step 3 — Separate the entitlement from the person *On page `/roles`, element `roles:matrix`.* Standing privilege usually lives in a role or a group rather than on an individual, which is what makes it invisible: nobody granted it to this person, they inherited it by joining a team. That also makes it tractable. Reducing scope on a role reduces it for everybody in the role at once — and nested membership is where privilege quietly accumulates, so enumerate indirect membership before you claim a number. **Do this.** Look at how permissions attach to roles rather than to people. ### Step 4 — The replacement has to be fast *On page `/portal`, element `portal:request`.* Request-based elevation only works if the approval turnaround is fast enough that people do not route around it. Friction kills adoption more reliably than any technical problem, and a control people work around is worse than no control, because it also gives false assurance. So the service level on approvals is a design decision, not an operational detail. Decide it, publish it, measure it, and treat a breach of it as a defect in the control rather than a busy week. **Do this.** Pick an account from the list to bring up the request form. ### Step 5 — Who approves, and how quickly *On page `/requests/incoming`.* The approver's queue is where the service level either holds or does not. Dual control has real approval latency, and people route around controls that block incident response — which is why dual control is applied by risk rather than universally. The usual split: exclusive access on shared privileged accounts almost by default, because it makes them individually attributable; dual control reserved for Tier 0, break glass, and anything touching financial reporting. ### Step 6 — Pilot with somebody willing *On page `/portal`.* Pick a team that wants it, prove the approval service level with real numbers, and publish those numbers. Owners who have seen a safe pilot stop resisting; owners who have seen an outage never trust the platform again. Then expand in waves rather than by announcement. And keep break glass, because the answer to "what if the request path is down" has to exist before you remove the standing rights that were previously the answer. ### Step 7 — Report the reduction so it stays funded *On page `/reports`, element `report:access`.* Standing-privilege reduction and just-in-time adoption are the two metrics that keep this work alive. A programme that cannot show its own progress loses its budget to one that can. The access report is the raw material: requests raised, approved, used and expired. Turn it into a trend rather than a list — the number of identities holding standing privilege, falling quarter on quarter, is the sentence an executive repeats. **Do this.** Generate the Access Report and consider what trend you would extract from it. ## What this prepares you to answer **Q. How do you reduce standing privilege without breaking the business?** Measure before you cut. Pull actual usage — who exercises standing rights and how often — because most standing privilege is never used, and that unused majority is the safe first tranche. Move those users to request-based elevation with an approval service level fast enough that people do not route around it, since friction kills adoption. Pilot with a willing team, prove the service level, publish the numbers, then expand in waves. Keep break glass. And report the reduction as a metric so it stays funded. **Q. What is zero standing privilege, and is it realistic?** The goal state where no identity holds elevated entitlements at rest — privilege is granted for an approved window and expires by itself. It is realistic as a direction rather than an absolute: break glass exists precisely because the request path can fail, and some legacy systems cannot support ephemeral access. The honest framing is the three variables that bound a grant — how long, over what, and authorised by whom — and driving each of them down. **Q. Someone asks for standing admin rights because requesting is too slow. What do you do?** Treat it as a defect in the control rather than a request to decline. If the approval turnaround is slow enough to be worth escaping, the control will be escaped — by this person and quietly by others. Measure the actual turnaround, fix it, and if it genuinely cannot be fixed for a legitimate emergency path, that is what break glass is for, with its alarms and its post-use review. Granting standing rights to solve a latency problem trades a fixable process failure for a permanent exposure. **Q. Where does standing privilege hide?** In roles and groups rather than on individuals, which is why nobody remembers granting it — people inherit it by joining a team. Nested group membership is where it accumulates unnoticed, so indirect membership has to be enumerated before any number is credible. Then the classes outside the directory entirely: local administrator rights on workstations, database privileged accounts, network device enable accounts, and cloud roles that can be assumed without an approval. # Run the platform — upgrades, resilience and cost > 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. *Handle the half of the job that is not access engineering: keeping the platform available, upgrading it safely, and arguing for the budget to expand it.* **Track:** Operations **Priority:** high **Time:** about 11 minutes **Topics:** DR, Upgrades, Backup, Licensing, Component logs **Walk it in the app:** https://pamsim.com/guides — guide id `platform-operations` ## The walkthrough A click-by-click walkthrough of the running application. Read as prose it still works: the steps carry the explanation, not just the navigation. ### Step 1 — The platform is a Tier 0 availability dependency *On page `/concepts`, element `concept:platform-operations`.* Everything else in this simulator assumes the platform is up. This walkthrough is about the half of the job where it is not, and about the questions that get asked when an interviewer wants to know whether you have operated something rather than configured it. Resilience, upgrade discipline, where to look when it breaks, and the budget conversation. **Do this.** Read the operations card. ### Step 2 — Replication, and the question behind it *On page `/vault`, element `vault:replication`.* A disaster recovery vault replicating from the primary, distributed or satellite vaults where an estate is geographically split, and load-balanced portal, credential manager and session manager components. Backup and restore use dedicated utilities rather than a file copy, because the encrypted store is not something you back up by copying a directory — and a copy without the server key decrypts to nothing anyway. **What an interviewer is testing.** Expect the follow-up, and expect it to be the real question: have you actually tested a failover, or only documented one? The honest answer names when you last tested and what broke. ### Step 3 — The failure nobody notices *On page `/vault`, element `vault:health`.* Look at component state. The dangerous failure here is not the loud one — it is a credential manager that has quietly stopped. Access still works, sessions still broker, and passwords simply stop rotating. Four months later that is an audit finding covering every account it was responsible for. Which is why component monitoring is a control rather than hygiene, and why one connected credential manager out of two is not "fine, we have redundancy" — it is half your rotations silently not running. ### Step 4 — Upgrade order, and why it matters *On page `/concepts`, element `concept:platform-operations`.* The vault first, then the portal, then the credential manager, then the session managers, with version compatibility checked across components. In-place against side-by-side is a risk decision rather than a preference — side-by-side costs infrastructure and buys you a rollback that actually works. And always re-validate afterwards: run a rotation, open a brokered session. An upgrade that leaves credential management silently failing is worse than no upgrade, because nothing alerts and the failure surfaces months later as a finding. ### Step 5 — Validate a rotation, deliberately *On page `/cpm`, element `cpm:queue`.* This is what post-upgrade validation looks like in practice: run a change, watch it complete, then verify. Not "the service started" — an actual credential changed on an actual target and the vault and the target agree afterwards. The same discipline applies after any change to a platform, a plugin or a connection component. **Do this.** Run a change on an account and watch the job to completion. ### Step 6 — Where to look when it breaks *On page `/concepts`, element `concept:platform-operations`.* By component. The credential manager's console and trace logs for rotation failures. The session manager's logs for connection component errors. The portal's logs for interface and API problems. The vault trace for authentication and permission problems. And the sentence that signals experience: most failures are environmental rather than product defects — connectivity, name resolution, permissions, target account state. Blaming the product first is the answer that marks somebody out. ### Step 7 — Licensing, and the politics of coverage *On page `/concepts`, element `concept:platform-operations`.* Licensed per managed account, which is why "onboard everything" meets budget resistance. That is not an obstacle to route around — it is the reason prioritising by risk exists. Tier 0 first is simultaneously the best security argument and the best budget argument: largest blast radius per account, smallest number of accounts, fastest demonstrable win. Being able to say that out loud is the sign you have argued for a budget rather than only spent one. **What an interviewer is testing.** Deployment model is the companion question. Self-hosted keeps control of upgrade timing, network placement and data residency, which regulated banks often want and sometimes need. Hosted removes the infrastructure and upgrade burden. Have a view, justify it, and say what would change your mind. ## What this prepares you to answer **Q. Walk me through a platform upgrade. What order, and how do you validate success?** Vault first, then the portal, then the credential manager, then the session managers, with version compatibility checked across components. In-place against side-by-side is a risk decision — side-by-side costs infrastructure and buys a working rollback. Validation is behavioural, not service state: run a rotation to completion and verify it, and open a live brokered session. An upgrade that leaves credential management silently failing is worse than no upgrade, because nothing alerts and it surfaces months later as an audit finding. **Q. How would you design resilience for the platform?** A disaster recovery vault replicating from the primary, distributed vaults where the estate is geographically split, and load-balanced portal, credential manager and session manager components, with replication lag monitored. Backup and restore through the dedicated utilities rather than a file copy. And then the part that matters: test the failover on a schedule, because a replica nobody has promoted is a belief rather than a control. **Q. Where do you look when something breaks?** By component and by path. Rotation failures: the credential manager's console and trace logs. Session failures: the session manager's logs plus the per-session connection component and recorder logs. Interface and API problems: the portal logs. Authentication and permission problems: the vault trace. Then the target's own authentication and system logs. Most failures are environmental rather than product defects — connectivity, name resolution, permissions, target account state. **Q. How do you handle the cost argument when you cannot onboard everything?** Licensing is per managed account, so coverage has a price and prioritisation is unavoidable. Tier 0 first is both the best security argument and the best budget argument: the largest blast radius per account and the smallest number of accounts, so it is the fastest demonstrable win. Then service accounts with the widest dependency footprint, then the long tail. Quantify it — percentage of the known estate under management, and discovery coverage against the estimated estate. # Triage a PTA detection > 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. *Work the Privileged Threat Analytics queue: know the named detections, tell an analytics finding from a workflow event, and take the right first action on each.* **Track:** Investigation **Priority:** essential **Time:** about 10 minutes **Topics:** PTA, Detections, Triage, Incident response, SIEM **Walk it in the app:** https://pamsim.com/guides — guide id `pta-triage` ## The walkthrough A click-by-click walkthrough of the running application. Read as prose it still works: the steps carry the explanation, not just the navigation. ### Step 1 — This page is the analytics layer *On page `/alerts`.* Privileged Threat Analytics watches privileged activity and raises named detections. The audit trail records everything that happened; PTA is the judgement about which of it matters. Without that layer a bank produces millions of privileged events a month and reviews none of them meaningfully. The thing that makes it more than a log alerter is vault context. The vault knows every credential it handed out, so a privileged logon it cannot account for is visible as theft rather than as ordinary administration. No SIEM rule can see that on its own. **What an interviewer is testing.** If you can only say 'it detects anomalies', you have not used it. The answer they want names detections and says where the signal comes from. ### Step 2 — Learn the catalogue *On page `/alerts`, element `alerts:detections`.* Open the detection catalogue below the list. Ten named detections, each with the signal that raises it and the response it calls for. This is the list an interviewer is fishing for when they ask what PTA detects. Group them in your head by source. From session activity: credential theft. From the absence of a vault record: PSM bypass, unmanaged account. From directory telemetry: golden ticket, over-pass-the-hash. From behavioural baselines: irregular hours, irregular source, excessive access. From policy state: violations and compliance drift. **Do this.** Expand the catalogue and read the three most severe rows. **What an interviewer is testing.** Being able to say which detections come from which source shows you understand the architecture, not just the marketing list. ### Step 3 — Filter to a single detection *On page `/alerts`, element `alerts:filters`.* Use the Detection filter to isolate one type. Each seeded example is a worked case with a real description rather than a placeholder. Start with Suspected credential theft. Read the description: a registry hive containing password material was copied on a domain controller, and then the Security event log was cleared. Two signals, and the second is the one that removes any doubt about intent. **Do this.** Filter by Suspected credential theft and open the event. ### Step 4 — The order of operations on a theft detection *On page `/alerts`.* Rotate first. The credential is the thing of value, and rotating it makes what the attacker took worthless — do this before the investigation is even properly open, because every minute it stays valid is a minute it can be used elsewhere. Then terminate the session, then preserve the recording as evidence before anything is cleaned up, then establish scope: where else did that identity authenticate in the same window. **What an interviewer is testing.** Candidates usually say 'investigate'. Saying 'rotate first, then investigate' is the answer that sounds like someone who has actually held the pager. ### Step 5 — Golden ticket, and the one detail people get wrong *On page `/alerts`.* A golden ticket means the krbtgt key is compromised, so an attacker can mint a ticket for any identity in the domain. It is the most severe finding in an Active Directory environment. The remediation is to reset krbtgt twice, with replication allowed to complete in between. Almost everyone says 'reset krbtgt' and stops. One reset leaves the previous key valid, so the forged tickets keep working — say 'twice, with replication in between' and you have answered the follow-up before it is asked. **Do this.** Filter by Golden ticket and read the event. **What an interviewer is testing.** This is a favourite question precisely because the single-reset answer is so common. ### Step 6 — Not everything here is a detection *On page `/alerts`.* Find the break glass event. It has no detection label, and that is deliberate: break glass raises an event every time it is used, by design. It is a record that a defined thing happened, not a judgement that something is wrong. Knowing which of your criticals are expected is what stops the queue becoming noise. An analyst who cannot tell the difference either investigates routine events or learns to ignore the whole channel. ### Step 7 — PSM bypass is the architectural finding *On page `/alerts`.* Filter by PSM bypass. A password changed on a target with nothing in the rotation history to account for it means two things: the vault's copy is now wrong, and a network path to that device exists which does not go through the session gateway. The reconcile fixes the credential. Closing the network path is the actual fix — an account reachable around the gateway is not really under management, and every control you have described depends on the gateway being the only way in. **What an interviewer is testing.** Answering with only 'reconcile it' fixes the symptom. Naming the bypass path is the answer of someone who thinks about the control model. ### Step 8 — Close it with a finding *On page `/alerts`.* Take an event for investigation, then close it with a note. A note is mandatory here on purpose: an event closed without one is indistinguishable from an event nobody looked at. Answer three things — what happened, whether it was authorised, and what changed as a result. 'Nothing changed' is a legitimate third answer when you say why. **Do this.** Open an event, take it for investigation, then resolve it with a note. **What an interviewer is testing.** Auditors sample closed events and read the notes. A queue of events closed with no finding is a worse audit outcome than a queue nobody triaged, because it looks like a control that is being performed and is not. ## What this prepares you to answer **Q. What does PTA detect?** Named detections rather than generic anomalies: suspected credential theft, PSM bypass and suspicious password change, golden ticket, over-pass-the-hash, unmanaged privileged accounts, irregular access hours, irregular source, excessive access requests, policy violations and compliance drift. **Q. How does PTA differ from a SIEM?** PTA is privileged-specific and understands vault context — it can tell that a domain administrator logon had no matching credential retrieval, which is the definition of a credential used outside the vault. A SIEM is enterprise-wide and has no such context. In practice PTA detects and forwards to the SIEM, which correlates the finding with endpoint and network evidence. **Q. You get a suspected credential theft alert. What do you do first?** Rotate the credential, before anything else — that makes what was taken worthless. Then terminate the session, preserve the recording as evidence, and establish scope by checking where else that identity authenticated in the same window. Mature deployments automate the rotation so it happens before a human reads the alert. **Q. How do you remediate a golden ticket?** Reset the krbtgt account password twice, allowing replication to complete between the two resets. A single reset leaves the previous key valid, so forged tickets continue to work. Then treat the whole domain as compromised and work outwards from there. **Q. What does an unmanaged privileged account tell you?** That privilege exists outside every control you have described: it rotates on nobody's schedule, appears in no approval workflow, and is recorded nowhere. Discovery finds them; the work is deciding for each one whether to onboard it or remove it. They are the usual gap between what a compliance report claims and what is actually true. **Q. Why does a PSM bypass detection matter beyond the one account?** Because it proves a network path to the target exists that avoids the session gateway. Reconciling the credential fixes the symptom; the real remediation is closing that path, since every control in the design assumes the gateway is the only way in. # Review a suspicious session > 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. *Investigate recorded privileged activity and know the order of operations when a credential may be compromised.* **Track:** Investigation **Priority:** high **Time:** about 10 minutes **Topics:** PSM recording, Investigation, Incident response, Evidence **Walk it in the app:** https://pamsim.com/guides — guide id `session-review` ## The walkthrough A click-by-click walkthrough of the running application. Read as prose it still works: the steps carry the explanation, not just the navigation. ### Step 1 — Recording is a detective control *On page `/recordings`.* Isolation stops the credential reaching the endpoint. Recording tells you what happened. They are separate controls and auditors test them separately. Video matters less than searchable command text. Nobody reviews an hour of desktop; they search for the command. ### Step 2 — Search activities, not sessions *On page `/recordings`, element `recordings:search`.* Filtering by user and date narrows a haystack. Searching what was actually typed finds the needle. Try the credential-theft and audit-tampering terms — clearing an event log, dumping a registry hive, reading the shadow file, enumerating the most privileged group in the directory. **Do this.** Type wevtutil into the activity search and see which sessions come back. ### Step 3 — Risk scoring, on the published scale *On page `/recordings`.* Sessions and individual commands score 1 to 100: 70 and above is High, 30 to 69 Medium, below 30 Low, and an em dash means no score at all rather than a zero. A session takes the score of its riskiest activity, not an average — one credential-dumping command in an otherwise routine hour is exactly what should surface. **Do this.** Sort by risk and open the highest-scoring recording. ### Step 4 — Read the timeline against the justification *On page `/recordings`.* The strongest signal in session review is the mismatch between what someone said they would do and what they actually did. That is precisely why every request demands a business justification. Look for scope creep, mass enumeration, credential access, audit tampering, and timing that does not fit the person's normal pattern. **Do this.** Play the recording. Use skip idle time, and filter to High risk to jump to the activity that matters. ### Step 5 — What the platform should alert on *On page `/alerts?severity=critical`.* Privileged access happening outside the vault — the control bypass, and the most important one. Break-glass retrieval. A failed authentication followed by a success on the same account. Retrieval spikes. Changes to safe permissions or policy. Rotation being disabled. Growing failure backlogs. Sessions that bypass recording. Component downtime. Most of those are control-failure alerts rather than attack alerts, and that is the point. ### Step 6 — Preserve evidence before you clean up *On page `/audit`, element `audit:filters`.* The order matters and interviewers test it. Contain access. Preserve evidence — the platform's records, the directory's, the endpoint's and the SIEM's. Then rotate or reconcile. Then hunt for lateral use and persistence. Then remediate, validate and improve the control. Rotating first destroys the timeline. Rotation is a containment step, not the whole incident. **What an interviewer is testing.** “How do you preserve evidence during a privileged account compromise?” Say the sequence, and say that line about rotating first — it is the discriminating answer. ### Step 7 — Correlate carefully *On page `/audit`.* Always correlate timestamps across sources — one clock-skewed log can invert an entire timeline and send an investigation the wrong way. And before declaring that something did not happen, verify that you actually had telemetry covering it. Absence of evidence is not evidence of absence. ## What this prepares you to answer **Q. How do you preserve evidence during a privileged credential compromise?** Contain access first, then preserve evidence from the PAM platform, the directory, the endpoint and the SIEM before changing anything. Only then rotate or reconcile, hunt for lateral movement and persistence, remediate, validate recovery and improve the control. Rotating first destroys the timeline. **Q. What would you alert on that indicates a control failure rather than an attack?** Privileged access happening outside the vault, break-glass retrieval, rotation or management being disabled, growing CPM failure backlogs, sessions bypassing recording, and changes to safe permissions or policy. **Q. What do you look for when reviewing a session recording?** Whether the activity matches the stated justification. Then scope creep into unrelated systems, mass enumeration, credential store access, audit tampering, and timing inconsistent with the person's normal pattern. **Q. Isolation or recording — which is the stronger control?** They do different jobs. Isolation is preventive: the credential never reaches the endpoint. Recording is detective: it tells you what happened. Auditors test them separately and you need both. # Read the target's event log > 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. *Work the other half of the record: the Windows Security events privileged activity produces, what each one means, and why the finding usually lives in the gap between the two logs.* **Track:** Investigation **Priority:** essential **Time:** about 11 minutes **Topics:** Windows events, 4624, 4625, 4672, Correlation, Audit policy **Walk it in the app:** https://pamsim.com/guides — guide id `windows-events` ## The walkthrough A click-by-click walkthrough of the running application. Read as prose it still works: the steps carry the explanation, not just the navigation. ### Step 1 — Two logs, one event *On page `/target-events`.* A Windows server has no idea that privileged access management exists. It records that a shared administrative identity logged on from an address at a time. It does not know which human borrowed that identity, under what approval, for what stated reason — the vault holds that half. Neither log is complete alone, and reading them together is the actual skill being tested. Every question that starts 'what logs would you check' is really asking whether you can build a timeline across sources. ### Step 2 — The three you must know cold *On page `/target-events`, element `events:tabs`.* 4624 a logon succeeded. 4625 a logon failed. 4672 special privileges were assigned to a new logon — the event that marks a session as administrative rather than ordinary. 4624 and 4672 arrive as a pair for a privileged logon, which makes 4672 the efficient filter when you want administrative activity rather than all activity. If you take one thing from this walkthrough into a rapid-fire round, make it those three in that order. **Do this.** Open the catalogue tab and read the three entries. **What an interviewer is testing.** Expect this as a one-line rapid-fire question. Answer it in one breath: 4624 successful logon, 4625 failed logon, 4672 special privileges assigned to a new logon. ### Step 3 — The rest of the working set *On page `/target-events`, element `events:tabs`.* 4740 an account was locked out — and the caller computer name in that event is the field that matters. 4724 a password was reset by somebody else, which is what a credential manager change looks like from the target's side. 4728 a member was added to a security-enabled global group, with 4732 for local groups. 4688 process creation, which is what turns 'they had a session' into 'here is what they ran'. 1102 the log was cleared. That is enough to work almost any privileged access investigation. The others you look up. ### Step 4 — Read a logon and its logon type *On page `/target-events`, element `events:list`.* Open a 4624 and look at the logon type. Type 2 is interactive at the console. Type 3 is network — a service or a remote share. Type 10 is RemoteInteractive, which is RDP. It is the field that separates a person at a keyboard from a service account authenticating in the background, and getting that wrong sends an investigation in entirely the wrong direction. **Do this.** Select a 4624 from the list and read the raw message. ### Step 5 — The correlation panel *On page `/target-events`, element `events:detail`.* For a brokered session the panel names the vault-side record that accounts for the event: which session, and which named person borrowed the shared identity. That is attribution restored — the target could never tell you. This is what an audit trail is for. A target system only ever sees 'Administrator logged on'. The platform is what knows the rest. ### Step 6 — Now filter to what nothing explains *On page `/target-events`, element `events:filters`.* Set the correlation filter to events with no vault record. What is left is privileged logons the platform cannot account for: no retrieval, no brokered session, no rotation job. That is the single most important finding in privileged access monitoring. Either the credential was obtained outside the platform, or a network path to the target exists that bypasses the session manager. Both are control failures, and neither is visible in either log on its own. **Do this.** Filter to “No vault record” and open one of the results. **What an interviewer is testing.** This is the headline analytics detection — unmanaged privileged access — described from first principles. Being able to explain why it needs two sources is better than naming the detection. ### Step 7 — 4625 is how you find a stale dependency *On page `/target-events`, element `events:filters`.* Filter to failed logons. After a rotation, a repeating 4625 for the same account from one host is the dependency nobody mapped — a Windows service, a scheduled task, an application pool or a database connection string still authenticating with the old password. This is the other half of the most common incident in a privileged access programme. The vault says the rotation succeeded and something still broke; this log is where you find out what. **Do this.** Filter to event ID 4625. ### Step 8 — Lockouts, and why you do not reconcile first *On page `/target-events`, element `events:list`.* A 4740 says the account locked out. The caller computer name names the host generating the bad passwords. Reconciling before you deal with that simply restarts the cycle: the credential is repaired, the stale process authenticates again with the old value, and the account locks a second time. Find the source, control it, and then decide between change and reconcile based on the actual credential state. **What an interviewer is testing.** "A managed account is locked. Do you reconcile it?" — not automatically. Reconciliation fixes synchronisation; it does not fix the reason for the lockout. ### Step 9 — The caveat that finishes the answer *On page `/target-events`, element `events:tabs`.* An event ID only helps if the audit policy producing it was enabled, the log was large enough not to have wrapped, and the events were forwarded somewhere they survive the host. So before saying something did not happen, confirm you would have seen it if it had. 'We were not recording that' and 'it did not occur' produce identical empty searches, and treating them as the same thing is how an investigation reaches a confident wrong conclusion. It is also why 1102 matters less than the person clearing the log expects. If sessions are recorded off-host and events are forwarded, clearing the local log destroys very little and announces itself loudly. ### Step 10 — Correlating across sources *On page `/audit`, element `audit:filters`.* The full answer to 'what logs would you check' is a list plus a discipline. The platform's own records — credential manager, session manager, portal, vault audit. The targets' authentication and system logs. The directory's logon, privilege and group-change events. Network, firewall and proxy logs. And the enterprise SIEM, which aggregates all of it. The discipline is correlating timestamps carefully. One clock-skewed source can invert an entire timeline and make the response look like the cause — normalise to UTC and check before drawing conclusions from ordering. ## What this prepares you to answer **Q. What do 4624, 4625 and 4672 mean?** 4624 an account successfully logged on; 4625 an account failed to log on; 4672 special privileges were assigned to a new logon, which is the event flagging that a privileged session is starting. 4624 and 4672 come as a pair for a privileged logon, so filtering on 4672 gets you administrative activity rather than all activity. **Q. A privileged credential may have been used outside the vault. How would you know?** By correlating the target's logon events against the vault's retrieval and session records. A 4624 for a privileged account with no matching retrieval, no brokered session and no rotation job means the credential came from somewhere the platform did not hand it out — either obtained outside the platform, or a network path exists that bypasses the session manager. That finding does not exist in either log alone, which is exactly why both are collected. **Q. What logs would you check when investigating privileged activity?** The platform's own — credential manager, session manager, portal and vault audit events. The target systems' authentication and system logs. Active Directory logon, privilege and group-change events. Network, firewall and proxy logs. And the SIEM, which aggregates all of it plus the application's own logs. Then correlate timestamps carefully, because one clock-skewed source can invert the whole timeline. **Q. Rotation succeeded but the application broke. Where do you look?** The target's failed logon events. A repeating 4625 for that account from one host is a dependency still holding the old password — a service, scheduled task, application pool or connection string. First confirm the vault password and the target password match; if they do, the credential is healthy and the fault is the stale copy, so find it and update it rather than reconciling. **Q. Someone says an action definitely did not happen because it is not in the log. Do you accept that?** Not without checking telemetry coverage first. An event only exists if the relevant audit policy subcategory was enabled, the log had not wrapped, and the events were being forwarded. 'We were not recording it' and 'it did not happen' produce identical empty searches, so I verify the coverage before treating absence as evidence. # When an administrator leaves > 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. *Walk the termination chain control by control, across all three identity pillars, and know the step almost everyone forgets.* **Track:** Compliance **Priority:** essential **Time:** about 10 minutes **Topics:** Leavers, Termination timeliness, IGA, SCIM, Rotation **Walk it in the app:** https://pamsim.com/guides — guide id `leaver-controls` ## The walkthrough A click-by-click walkthrough of the running application. Read as prose it still works: the steps carry the explanation, not just the navigation. ### Step 1 — The trigger has to be authoritative *On page `/users`.* The chain starts with the human resources system, and that matters more than it sounds. Anything driven by a manager remembering to send an email is already the weakness — it is unevidenced, unmonitored, and it fails silently on exactly the terminations that matter most. An auditor testing termination timeliness will sample leavers from the HR record, not from your ticket queue. If the two populations differ, that difference is the finding. **What an interviewer is testing.** Naming HR as the authoritative trigger unprompted is a small, cheap signal that you have been through this control rather than read about it. ### Step 2 — The identity layer goes first *On page `/users`.* The identity provider deactivates the identity, which kills single sign-on and terminates active sessions. That is the fastest-acting step in the whole chain and the one that stops further access immediately. Then provisioning pushes deprovisioning downstream to connected applications. The gap to call out is any application integrated only by just-in-time provisioning: it created the account at first login and has no mechanism to remove it, so nothing downstream ever hears that the person has gone. ### Step 3 — Which is why the pillars matter here *On page `/concepts`, element `concept:iam-pillars`.* This one process crosses all three. Governance owns the lifecycle and the authoritative trigger. Access management deactivates the identity and kills the sessions. Privileged access removes the elevated entitlements and deals with the credentials. It is also where a failure in one becomes visible in another: a leaver still holding safe membership is a governance failure that surfaces on the privileged side, and it will be found by a privileged access review rather than by the process that caused it. **Do this.** Read the pillars card. ### Step 4 — Remove the entitlement *On page `/safes/1`, element `safe:tabs`.* Directory account disabled, then safe membership removed. This is the entitlement half: whatever the person could have listed, used, retrieved or managed, they can no longer reach. Check the membership tab. Every grant here is a row somebody will have to justify at the next access review — and a leaver appearing in it is the single most common finding a privileged access review produces. **Do this.** Open a safe's members and consider what removing one entails. ### Step 5 — The step almost everyone forgets *On page `/cpm`, element `cpm:queue`.* Removing a person does not invalidate a password they memorised. Every shared credential the leaver could reach has to be rotated immediately — not at its next scheduled interval, immediately. This is the reason exclusive access and one-time passwords exist. If credentials rotate on check-in, the exposure window closed the moment they last checked one in, and this step becomes a formality rather than a scramble. Where they do not, it is a real list of accounts and a real change window. **Do this.** Look at what a rotation queue would need to contain for one departing administrator. **What an interviewer is testing.** This is the step that separates a complete answer from a plausible one. Most people stop at "remove their access" and never mention the credentials they still know. ### Step 6 — And the credentials they held physically *On page `/accounts`, element `accounts:filters`.* Hard tokens returned and revoked. If they held a break-glass credential, that gets rotated too — and the offline copy has to be reissued, because a sealed envelope somebody may have photographed is not sealed. The audit-visible number here is unreturned tokens from leavers. It is a finding, and an untracked spare is worse, because nobody can say who holds it. ### Step 7 — Timestamped evidence throughout *On page `/audit`, element `audit:filters`.* Termination timeliness is a control tested against a clock: access removed within a defined window of the leaving date. So each step needs a timestamp somebody can produce later, from the system that did it rather than from a spreadsheet describing it. Filter the trail and read it as a sequence. That sequence — identity deactivated, membership removed, credentials rotated — with times attached, is what the control test actually consumes. **Do this.** Filter the audit trail to the user category. ### Step 8 — Then verify, rather than assume *On page `/reports`, element `report:safe-membership`.* The last step is a reconciliation: the safe membership report against the current leaver list. Removal you performed and removal you can demonstrate are different things, and only the second survives an audit. It is also how you find the failures of the process itself — the application that only does just-in-time provisioning, the group somebody was a member of indirectly, the local account that never appeared in the directory at all. **Do this.** Generate the Safe Membership Report and read it as a leaver check. ## What this prepares you to answer **Q. Walk me through what happens, control by control, when an administrator is terminated.** Human resources is the authoritative trigger — anything driven by a manager email is already a weakness. The identity provider deactivates the identity, killing single sign-on and active sessions. Provisioning deprovisions downstream applications, and the gap to name is any application integrated only by just-in-time provisioning, which creates accounts and never removes them, so it needs manual reconciliation. Directory account disabled. Safe membership removed. Then the step people forget: every shared credential they could reach is rotated immediately, because removing a person does not invalidate a password they memorised. Hard token returned and revoked, break-glass rotated if they held it. Timestamped evidence throughout for the termination-timeliness control, then a verification access review. **Q. Why is rotating credentials part of a leaver process?** Because access removal and credential invalidation are different things. If somebody retrieved a shared administrative password last month, disabling their account does not change what they know. Any credential they could reach has to be rotated immediately rather than at its next interval. It is also the strongest practical argument for exclusive access and one-time passwords: where credentials rotate on check-in, the exposure window already closed and this step is a formality. **Q. What makes termination timeliness fail?** Usually the trigger rather than the removal. A process driven by manager notification rather than the human resources record fails silently on the terminations that matter. After that: applications integrated only by just-in-time provisioning, which never deprovision; indirect group membership nobody enumerated; local accounts that were never in the directory; and shared credentials that were removed as an entitlement but never rotated. **Q. How would you prove the leaver control operated?** Sample from the human resources leaver record rather than from the ticket queue, and for each one produce timestamped evidence from the systems that acted — identity deactivation, deprovisioning, safe membership removal, credential rotation — measured against the leaving date. Then reconcile current safe membership against the leaver list to show nothing survived. Removal you performed and removal you can demonstrate are different things. # Maturity, metrics and the standards behind them > 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. *Frame a roadmap answer, quantify a programme with numbers an auditor and an executive both accept, and name which document each requirement comes from.* **Track:** Compliance **Priority:** high **Time:** about 10 minutes **Topics:** Maturity, Metrics, Standards, Roadmap, Landscape **Walk it in the app:** https://pamsim.com/guides — guide id `maturity-and-metrics` ## The walkthrough A click-by-click walkthrough of the running application. Read as prose it still works: the steps carry the explanation, not just the navigation. ### Step 1 — The arc, and why it forces an order *On page `/concepts`, element `concept:maturity-and-metrics`.* Ad hoc, then discovered and inventoried, then vaulted, then rotated, then session-controlled, then least privilege enforced, then just-in-time with zero standing privilege, then analytics driven. Its value is not that it is a ladder to climb — it is that it forces the order. You cannot secure an estate you have not inventoried. You should not attempt session control before the credential is vaulted and rotating. And zero standing privilege is meaningless while nobody knows what standing privilege exists. **Do this.** Read the maturity card. **What an interviewer is testing.** Any "where would you take this?" question is answered with the arc plus where you judge them to be. Naming the stage they are at, and the next one, is a roadmap. ### Step 2 — Coverage is the first number *On page `/`.* The dashboard is trying to answer the most diagnostic question in the discipline: what proportion of the privileged estate is actually under management, and how does that compare to what discovery says exists? It works as a question to ask an interviewer as much as an answer to give one. If there is no number, that is the number — no denominator means no discovery, and the first six months of the job are an inventory exercise. ### Step 3 — Which is why discovery is the denominator *On page `/discovery`, element `discovery:findings`.* Everything on this page is outside the count. That gap — between the accounts you manage and the accounts that exist — is the single number a programme lives or dies by, and the first scan is always uncomfortable. Discovery coverage against the estimated estate is the companion metric. Scanning three subnets out of forty produces a reassuring number that means nothing. ### Step 4 — Hygiene, and the backlog nobody reports *On page `/reports`, element `report:failed-rotation`.* Rotation compliance, credential age and the failed-rotation backlog. The third one is the metric that actually predicts an audit finding, because a rotation failing quietly for four months is a control that has stopped operating while the policy still says it works. Generate it and read it as a number rather than a list. "Eleven accounts have been failing for more than thirty days" is a metric; the list is the work. **Do this.** Generate the Failed Rotation Report. ### Step 5 — The rest of the set, by what they prove *On page `/concepts`, element `concept:maturity-and-metrics`.* Control: the share of privileged sessions isolated and recorded. Direction of travel: standing-privilege reduction and just-in-time adoption. Operations: time to onboard an account, break-glass usage count and review rate. Lifecycle: orphaned privileged accounts eliminated, and deprovisioning time for leavers. Authentication: multi-factor coverage on administrative access, and specifically the share on phishing-resistant factors — those are two different numbers and quoting only the first is how programmes flatter themselves. Hardware: tokens issued, returned on termination, and unreturned. Compliance: access-review completion, and control gaps closed. ### Step 6 — Where the requirements are actually written down *On page `/concepts`, element `concept:standards-map`.* The federal control catalogue supplies the vocabulary — account management, segregation of duties, least privilege, remote access, and the audit family. The digital identity guidelines supply assurance levels, and the top authenticator level effectively requires hardware, which is how you justify buying keys. The zero trust publication is the model behind per-application network access. The internet security benchmarks contribute account management and access control management. The card-data standard's requirements seven and eight cover need-to-know access and authenticating every user, including that shared accounts must be individually attributable — which is exactly what exclusive access delivers. **Do this.** Read the standards card. ### Step 7 — And the banking-specific layer *On page `/concepts`, element `concept:standards-map`.* The financial privacy legislation reaches banks through interagency guidelines enforced by the banking agencies, not through the trade regulator's rule — a distinction worth getting right, because getting it wrong signals you learned it from a summary. The examination council publishes the handbook examiners work from. The national bank supervisor sets heightened standards for large institutions. And the financial reporting legislation is what makes access to programs and data an audited domain rather than a preference. **What an interviewer is testing.** Naming the examination council and the bank supervisor unprompted signals you understand banking specifically rather than security generally. It is a cheap, high-value signal. ### Step 8 — Do not be a one-vendor candidate *On page `/concepts`, element `concept:vendor-landscape`.* Naming the alternatives shows you understand the category rather than one product's menu, and it is a normal question because most estates have more than one after an acquisition. The useful closing sentence: the fundamentals survive the vendor. Discover, apply least privilege, remove standing access, broker and record, produce evidence. The product decides how, not what. **Do this.** Read the landscape card. ## What this prepares you to answer **Q. How would you stand up a programme somewhere with none?** Discover before you protect — you cannot secure an estate you have not inventoried, and the first scan always finds more than the configuration database claims. Then prioritise by blast radius: Tier 0 first, then production service accounts with the widest dependency footprint, then the long tail. Vault and rotate before attempting session control, and map dependencies before rotating anything. Aim for an early win that proves value without causing an outage, because programme funding depends on the first ninety days not breaking production. **Q. How would you measure whether the programme is working?** Coverage first — the percentage of the known privileged estate under management, and discovery coverage against the estimated estate, because without a denominator nothing else means anything. Then hygiene: rotation compliance, credential age, failed-rotation backlog. Then control: the share of sessions isolated and recorded. Then direction of travel: standing-privilege reduction and just-in-time adoption. Plus lifecycle numbers, multi-factor coverage on admin access with phishing-resistant factors counted separately, and access-review completion. **Q. Which standards drive these requirements?** The federal control catalogue for the control vocabulary — account management, segregation of duties, least privilege, remote access, and the audit family. The digital identity guidelines for assurance levels, where the top authenticator level effectively requires hardware. The zero trust architecture publication for per-application access. The internet security benchmarks and the international management standard for access control. The card-data standard's requirements seven and eight. And for a bank specifically, the financial privacy legislation through interagency guidelines, the examination council's handbook, heightened standards from the national bank supervisor, and the financial reporting legislation behind the audited access domain. **Q. Which other products in this space do you know?** The other established privileged access vendors with their password-store and endpoint-privilege products; the general-purpose secrets managers and the modern infrastructure-access products that broker sessions with short-lived certificates instead of stored passwords; the federation and multi-factor vendors alongside the large cloud identity providers with native time-bound role activation; the zero trust and security service edge vendors; and the cloud providers' own secret stores and identity centres. The point is that the fundamentals survive the vendor — discover, least privilege, remove standing access, broker and record, evidence. # Pull the reports an audit asks for > 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. *Run the reporting surface end to end: which report answers which question, how to generate and export one, and what has to travel with it for it to count as evidence.* **Track:** Compliance **Priority:** essential **Time:** about 10 minutes **Topics:** Reports, Evidence, IPE, Access review, Export **Walk it in the app:** https://pamsim.com/guides — guide id `pull-reports` ## The walkthrough A click-by-click walkthrough of the running application. Read as prose it still works: the steps carry the explanation, not just the navigation. ### Step 1 — Each report answers somebody's actual question *On page `/reports`, element `reports:catalogue`.* This is not a menu of dashboards. An auditor asks for the account inventory and the access report. A security lead asks for the risk report and the failed rotations. A platform owner asks for safe membership before an access review. A privileged access team lives in the failed rotation report. Learn which report answers which question and you can respond to a request without a meeting first. That is a surprisingly large part of the job. **Do this.** Read the eight report cards and what each one claims to answer. ### Step 2 — Population — what exists *On page `/reports`, element `report:privileged-accounts`.* The first question in any audit is completeness: prove this is every privileged account, not the ones you chose to show me. Generate the inventory and look at what a row carries — the account, its safe, its platform, its owner, its credential age, whether it is compliant, its risk. The report is the starting point; the evidence is reconciling it against the directory to show nothing is missing. **Do this.** Generate the Privileged Account Report. ### Step 3 — The access review artefact *On page `/reports`, element `report:safe-membership`.* One row per grant: the safe, the person, their role, the permission level, when it was granted. This is what a recertification campaign is actually built on. Generate it and export it. The export is the point — a review runs on a file somebody signs off, not on a screen somebody looked at. **Do this.** Generate the Safe Membership Report and export it to CSV. ### Step 4 — Operating effectiveness — did the control run *On page `/reports`, element `report:rotation`.* Rotation logs across the period are the evidence that credential management actually operated, rather than merely being configured correctly. Every change, verify and reconcile, with its trigger and its outcome. Then generate the failed rotation report. That one is the working list: each row is a credential drifting further out of policy every day, with the step the job died on and the cause. It is also, uncomfortably, the report an auditor finds most interesting. **Do this.** Generate the Password Rotation Report, then the Failed Rotation Report. ### Step 5 — Filter, then export what you filtered *On page `/reports`.* The row filter narrows what is on screen, and the export follows it — an export of a filtered report is labelled as filtered for a reason. This matters more than it sounds. Handing an auditor a filtered extract without saying it was filtered is how a completeness question turns into a finding. If you narrowed it, the parameters you narrowed it with are part of the evidence. **Do this.** Filter a report to a subset, then export it and note the filename. ### Step 6 — What has to travel with the file *On page `/reports`.* Any report you hand over is Information Produced by the Entity — evidence whose own completeness and accuracy you must be able to prove. The file alone does not establish either. Keep the source system, the report or query logic, the parameters used, the timestamp of generation, and the reconciliation that shows the population is complete. A screenshot with no provenance is not evidence, and that sentence is worth saying verbatim in an interview. **What an interviewer is testing.** Volunteering IPE unprompted is one of the strongest signals that you have worked with auditors rather than around them. ### Step 7 — Where the reports come from *On page `/audit`, element `audit:filters`.* Every report here is generated live from the same records the platform writes as it runs. That is what makes it defensible — it is not a spreadsheet somebody has been maintaining alongside the system. Filter the trail to denied results. Refusals are the densest evidence in the log, because every one is a control that actually did something rather than a control that was merely present. **Do this.** Filter the audit trail to Result: denied. ### Step 8 — Doing it on a schedule instead of by hand *On page `/rest-api`, element `rest:endpoints`.* A quarterly access review done by hand is three days of clicking. The same review as a scheduled extract through the API is a job that runs on the first of the month and lands a file with its own parameters recorded. The safe members endpoint across every safe is the access review population. The accounts endpoint is the inventory. Automating the extract is not just efficiency — a generated file with its query recorded alongside it is stronger evidence than one a person assembled. ## What this prepares you to answer **Q. An auditor asks you to prove privileged access controls. What do you give them?** Three layers in order. Population: the full privileged account inventory from the vault, reconciled against the directory to demonstrate completeness. Design: safe permissions, Master Policy settings and platform rotation configuration. Operating effectiveness: rotation logs across the period, session recordings, access review sign-offs, ticket-linked approvals and termination timeliness. And for every report handed over, the query behind it — a screenshot with no provenance is not evidence. **Q. What is IPE and why does it matter here?** Information Produced by the Entity. Any report you give an auditor is itself evidence whose completeness and accuracy you have to be able to prove, so the source system, the report logic, the parameters, the generation timestamp and the reconciliation travel with the file. It is also why a filtered export must be labelled as filtered — an unlabelled subset turns a completeness question into a finding. **Q. Which report would you use for a user access review?** Safe membership — one row per grant with the person, their role and the permission level, exported so it can be signed off. It depends on being able to enumerate the population completely, which is why it is reconciled against the directory and the HR feed. What it catches is leavers who still hold membership, movers who kept old access, and temporary grants nobody withdrew. **Q. How would you make audit evidence production repeatable?** Automate the extracts through the API on a schedule rather than assembling them by hand — safe members across every safe for the review population, the account inventory for completeness, rotation history for operating effectiveness. A generated file with its parameters and query recorded alongside it is both cheaper and stronger evidence than a manually assembled one, and it means the same evidence exists next quarter without anybody rediscovering how it was made. # Produce evidence for an audit > 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. *Answer what an auditor actually asks for, in the three layers they ask for it, and know why a screenshot is not evidence.* **Track:** Compliance **Priority:** high **Time:** about 9 minutes **Topics:** SOX, ITGC, Access review, Evidence, IPE **Walk it in the app:** https://pamsim.com/guides — guide id `sox-evidence` ## The walkthrough A click-by-click walkthrough of the running application. Read as prose it still works: the steps carry the explanation, not just the navigation. ### Step 1 — PAM is the Access to Programs and Data control set *On page `/reports`.* That is the SOX 404 ITGC domain privileged access lives in. The others — program changes, program development, computer operations — are audit convention rather than statute, and knowing that distinction is a small credibility marker. Feature to control: vaulting and rotation is credential management; Use-without-Retrieve and recording is privileged activity monitoring; dual control and ticketing is authorisation; exclusive access is attribution; access reviews and termination timeliness are lifecycle. ### Step 2 — Layer one — population *On page `/reports`, element `report:privileged-accounts`.* The auditor's first question is completeness: prove this is every privileged account, not the ones you chose to show me. You produce the full inventory from the vault and reconcile it against the directory. The reconciliation is the evidence, not the list. **Do this.** Generate the Privileged Account Report and look at what it contains. ### Step 3 — Layer two — design *On page `/policies`, element `policy:access`.* Would the control work if it ran? That is inspected from configuration: safe permissions, policy settings, platform rotation configuration. Screenshots of settings, with the date and the person who captured them. ### Step 4 — Layer three — operating effectiveness *On page `/reports`, element `report:rotation`.* Did it operate throughout the period? Rotation logs across the whole period, session recordings, access-review sign-offs, ticket-linked approvals, termination timeliness. A control can pass design and fail operating effectiveness, and that is the common finding: the policy was right, but rotation had been failing on thirty accounts for four months. **Do this.** Generate the Password Rotation Report, then the Failed Rotation Report. **What an interviewer is testing.** If you can explain test of design versus test of operating effectiveness, and give that example, you will sound like someone who has been through an audit. ### Step 5 — The access review artefact *On page `/reports`, element `report:safe-membership`.* Once or twice a year someone must answer whether everyone who can reach a privileged credential still needs to. The Safe Membership Report is that conversation's artefact — one row per grant, with the person, their role and the permission level. Deliberately boring output, deliberately boring work. What it catches is leavers who still hold membership, people who moved teams, and “temporary” grants nobody removed. **Do this.** Generate the Safe Membership Report and export it. ### Step 6 — Information Produced by the Entity *On page `/reports`.* Anything you hand an auditor is evidence whose completeness and accuracy you must be able to prove. Keep the source system, the query or report logic, the parameters, the timestamp and the reconciliation alongside it. A screenshot with no provenance is not evidence. That sentence is worth saying in the interview verbatim. ### Step 7 — The audit trail underneath it all *On page `/audit`, element `audit:filters`.* Every report here is generated live from the same records the rest of the platform writes. That is what makes the evidence defensible: it is not a spreadsheet somebody maintained. Filter to denied results — refusals are the densest evidence in the log, because each one is a control actually doing something. **Do this.** Filter the audit log to Result: denied. ### Step 8 — Deficiency, significant deficiency, material weakness *On page `/reports`.* The ladder turns on likelihood and magnitude of misstatement. Compensating controls can lower where a gap lands. A remediation plan does not by itself reclassify a deficiency — a point candidates routinely get wrong, and a good one to get right. ## What this prepares you to answer **Q. What evidence would you give an auditor for privileged access?** Three layers. Population: the full privileged account inventory reconciled against the directory, to prove completeness. Design: safe permissions, policy settings and platform rotation configuration. Operating effectiveness: rotation logs across the period, session recordings, access review sign-offs, ticket-linked approvals and termination timeliness. **Q. What is the difference between test of design and test of operating effectiveness?** Design asks whether the control would work if it ran, and is inspected from configuration. Operating effectiveness asks whether it operated throughout the period, and is sampled. A control can pass design and fail operating effectiveness — the classic case is correct policy with rotation silently failing for months. **Q. What is IPE and why does it matter?** Information Produced by the Entity — any report you hand the auditor is itself evidence whose completeness and accuracy you must prove. Keep the source system, report logic, parameters, timestamp and reconciliation with it. A screenshot with no provenance is not evidence. **Q. Does having a remediation plan downgrade a deficiency?** No. The classification turns on likelihood and magnitude of potential misstatement, and compensating controls can affect where it lands — but a plan to fix it later does not reclassify it. # Dual control and access approval > 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. *Work both halves of the approval workflow and understand where time-bound access fits the Zero Standing Privileges argument.* **Track:** Compliance **Priority:** high **Time:** about 8 minutes **Topics:** Dual control, ZSP, JIT, Segregation of duties **Walk it in the app:** https://pamsim.com/guides — guide id `dual-control` ## The walkthrough A click-by-click walkthrough of the running application. Read as prose it still works: the steps carry the explanation, not just the navigation. ### Step 1 — The requester's half *On page `/portal`.* A request carries a reason, a timeframe, and whether multiple access is needed or a single connection will do. A ticket reference links it to a change or incident record, which is what turns “who accessed this and why” into auditor-ready evidence. The justification is not paperwork. It is the thing a session recording gets reviewed against later. **Do this.** Search for an account, select it, and fill in a request — reason, timeframe, and whether you need multiple access. ### Step 2 — The approver's half *On page `/requests/incoming`.* You are not deciding whether the person is trustworthy — they already authenticated. You are deciding whether this account, for this window, is proportionate to the stated task. Three questions: is the justification specific enough to review later, is this the least privileged account that would do the job, and is the duration proportionate or just the maximum? **Do this.** Open the incoming queue and confirm a request. Notice that a reason is mandatory on the decision. **What an interviewer is testing.** Segregation of duties: requester, approver and reviewer must be different people. PAM SIM lets you approve your own request only because self-approval is switched on in policy — say that if you demonstrate it. ### Step 3 — Where the rule lives *On page `/policies`, element `policy:access`.* Approval requirements, maximum window, MFA and justification requirements are organisation-wide policy. Turn self-approval off here and the API refuses your own request — not just the interface. Applying dual control everywhere is a mistake worth naming: approval latency makes people route around controls. Apply it by risk — Tier 0, break glass, financial reporting systems — and mandate exclusive access more broadly instead. **Do this.** Turn off Allow self-approval, then try to approve one of your own requests. ### Step 4 — The grant expires by itself *On page `/requests/mine`.* Approval creates a window with a hard expiry. Nobody has to remember to revoke it, and nobody accumulates an entitlement they used once two years ago. That is the mechanism underneath just-in-time access and Zero Standing Privileges. The shorthand for the three variables is TEA — Time, Entitlements, Approvals. ### Step 5 — Vaulted versus just-in-time *On page `/access/infrastructure`.* Vaulted means a long-lived credential exists and is injected. JIT means no standing credential exists at all — the entitlement is created for the session and destroyed with it. Nothing to rotate, nothing to steal in between. Watch the terminology trap: JIT provisioning in federation creates an application account at first sign-in and never removes it, which is an audit gap. JIT elevation in PAM grants temporary rights that auto-revoke. Same two letters, opposite risk profile. The gap in the provisioning sense is worth stating precisely, because it hits two controls at once. Nothing tells the application somebody has left, so the account stays active — which breaks termination timeliness, and also breaks user access review, since you cannot recertify a population you cannot enumerate. Where an application supports the provisioning standard, use it; where only the login-time creation exists, accept the gap and compensate with periodic reconciliation against the human resources feed, documented as a detective control because the preventive one is unavailable. **What an interviewer is testing.** Asked a bare "tell me about JIT", ask which one they mean before answering — the question is deliberately ambiguous and asking is itself the strong signal. Then the summary: JIT provisioning creates lasting access, JIT elevation grants temporary access. ### Step 6 — Break glass is the exception that proves it *On page `/sessions`.* Emergency access is expedited, not unauthorised. It still needs approval; what changes is response time. The compensating controls are mandatory recording, a critical alert, and automatic rotation the moment the session ends. That last one is what stops an emergency password quietly becoming a shared standing credential. ## What this prepares you to answer **Q. What is dual control and where would you apply it?** A second authorised person must approve before a credential is released. Apply it by risk — Tier 0, break glass, financial reporting systems — rather than everywhere, because approval latency makes people route around controls. Mandate exclusive access more broadly instead. **Q. What are Zero Standing Privileges?** No identity holds privileged entitlements at rest. Privilege is granted for a task and revoked automatically. The three variables are time, entitlements and approvals. Vaulting a shared credential is step one, brokering the session is step two, time-limited approval is step three. **Q. Tell me about JIT.** Ask which one they mean first — the question is deliberately ambiguous and asking is the strong opening. JIT provisioning is federation: the application creates the account at first single sign-on from the assertion's attributes. It creates and never deprovisions, which breaks termination timeliness and also breaks user access review, because you cannot recertify a population you cannot enumerate. JIT elevation is the privileged access sense: no standing administrative rights, time-boxed approved elevation that auto-revokes, aiming at zero standing privilege. Summary: provisioning creates lasting access, elevation grants temporary access. **Q. What is the difference between JIT provisioning and the provisioning standard?** The provisioning standard is push-based and covers the whole lifecycle including deprovisioning, without the user logging in. Login-time provisioning only creates, and only when somebody signs in. Use the standard wherever the application supports it; where only login-time creation exists, accept the gap and compensate with periodic reconciliation of the application's user list against the human resources feed — documented as a detective control, because the preventive one is unavailable. **Q. How does break glass differ from normal privileged access?** It is expedited, not unauthorised. Approval is still required, but the controls shift to compensating ones: mandatory recording, a critical security event, and automatic credential rotation as soon as the session ends so the password cannot become a shared standing secret. # 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?' # The REST API > 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. A simulated PVWA REST surface, driven from a console inside the application at https://pamsim.com/rest-api. The status a call returns is not scripted: it is decided by the signed-in identity's real permissions and the real state of the seeded data, so an Auditor genuinely cannot retrieve a credential and a duplicate account name genuinely conflicts. ## The endpoints ### Authentication #### `POST /PasswordVault/API/Auth/CyberArk/Logon` — Authenticate Exchange credentials for a session token. Every other call carries that token in the Authorization header. **What it teaches.** The shape of the whole sequence: authenticate, hold a token, call, log off. Change the username to something that does not exist and you get the 401 you would see in production. **Requires.** Nothing beyond a valid session token. **Status codes reachable.** 200, 400, 401 | Field | In | Required | Notes | | --- | --- | --- | --- | | username | body | yes | Defaults to the identity you are signed in as. Change it to an unknown name to see a 401. | | password | body | yes | PAM SIM stores no passwords. Any non-empty value is accepted for a known username — the point of the field is that a real script must never carry one literally. | #### `POST /PasswordVault/API/Auth/Logoff` — Log off Invalidate the session token. **What it teaches.** Scripts that authenticate in a loop and never log off exhaust the session limit, and the failure looks like an outage. Log off in a finally block. **Requires.** Nothing beyond a valid session token. **Status codes reachable.** 200, 401 ### Accounts #### `GET /PasswordVault/API/Accounts` — List accounts Query the managed account inventory, optionally narrowed by a search term or a safe filter. **What it teaches.** Filtering and pagination are the difference between a script that works on a demo estate and one that works on 40,000 accounts. A malformed filter returns 400, not an empty list. **Requires.** List accounts on the safe **Status codes reachable.** 200, 400, 401 | Field | In | Required | Notes | | --- | --- | --- | --- | | search | query | no | Free-text match on account name, username or address. | | filter | query | no | Structured filter. The documented form is `safeName eq `. Anything else is rejected. | | limit | query | no | Page size. The response carries a count so a caller knows whether to page. | #### `GET /PasswordVault/API/Accounts/{accountId}` — Get one account Fetch a single account's properties by its identifier. **What it teaches.** 404 against 403. An identifier that does not exist is not a permission problem, and treating it as one sends you to the wrong team. **Requires.** List accounts on the safe **Status codes reachable.** 200, 401, 404 | Field | In | Required | Notes | | --- | --- | --- | --- | | accountId | path | yes | Try a real one from the list call, then try 9999. | #### `POST /PasswordVault/API/Accounts` — Onboard an account Create a managed account: what it is, where it lives, which platform manages it and which safe holds it. **What it teaches.** Bulk onboarding is this call in a loop. It is also the clearest 403 in the API — the add-account authority is separate from the ability to read the inventory. **Requires.** Add accounts on the safe **Status codes reachable.** 201, 400, 401, 403, 409 | Field | In | Required | Notes | | --- | --- | --- | --- | | name | body | yes | | | userName | body | yes | | | address | body | yes | | | platformId | body | yes | Platform identifiers are deployment-specific. A wrong one is a 400, not a silent default. | | safeName | body | yes | | ### Credentials #### `POST /PasswordVault/API/Accounts/{accountId}/Password/Retrieve` — Retrieve a password Ask the vault for the actual secret. The single most audited call in the API. **What it teaches.** This is where Use-without-Retrieve becomes real. Sign in as someone who can connect through the session manager but not reveal the password, and this call returns 403 while everything else still works. **Requires.** Retrieve accounts on the safe **Status codes reachable.** 200, 401, 403, 404 | Field | In | Required | Notes | | --- | --- | --- | --- | | accountId | path | yes | | | reason | body | no | Where policy demands a reason or a ticket, omitting it is a 400 rather than an unaudited retrieval. | #### `POST /PasswordVault/API/Accounts/{accountId}/Change` — Trigger a change Mark the account for an immediate credential change by the CPM. **What it teaches.** The API queues work for the CPM rather than changing anything itself. A 200 here means the job was accepted, not that the password changed — which is exactly the distinction that makes people close incidents too early. **Requires.** Initiate CPM account management operations **Status codes reachable.** 200, 401, 403, 404 | Field | In | Required | Notes | | --- | --- | --- | --- | | accountId | path | yes | | ### Safes #### `GET /PasswordVault/API/Safes` — List safes Enumerate the safes visible to the caller. **What it teaches.** What the API returns is scoped to the caller, so this doubles as a permissions check: a safe you cannot see is indistinguishable from a safe that does not exist. **Requires.** Membership of the safe **Status codes reachable.** 200, 401 #### `GET /PasswordVault/API/Safes/{safeName}/Members` — List safe members Who holds what permission on a safe. **What it teaches.** This call is how an access review gets automated. Run it across every safe on a schedule and you have the population an auditor asks for, with provenance. **Requires.** View Safe Members **Status codes reachable.** 200, 401, 403, 404 | Field | In | Required | Notes | | --- | --- | --- | --- | | safeName | path | yes | | ### Operations #### `GET /PasswordVault/API/ComponentsMonitoringSummary` — Component health The health of each component: vault, CPM, session managers and the portal itself. **What it teaches.** The call behind 'how do you monitor CyberArk'. A CPM that has quietly stopped is not an outage anyone notices — it is an audit finding four months later. **Requires.** Audit users **Status codes reachable.** 200, 401, 403 ## The status codes Every automation question eventually lands on the same distinction: 401 means you never got in, 403 means you got in and are not allowed. Regenerating a token on a 403 achieves nothing, because the token was fine. ### 200 OK The call succeeded. For anything that queues work — a change, a reconcile — it means the request was accepted, not that the work finished. **First thing to check.** Read the body. A 200 with an empty result set is a filter problem, not a success. **Confused with.** Nothing, but it is over-trusted: do not close an incident because the API returned 200. Confirm the effect. ### 201 Created A new object exists and the response carries its identifier. **First thing to check.** Keep the identifier. Onboarding scripts that discard it cannot report what they created or roll it back. ### 400 Bad Request The request itself is wrong: malformed JSON, a missing required field, an invalid value, a filter the API does not parse. **First thing to check.** Compare your payload against the documented schema field by field. The response usually names the field. **Confused with.** 404 — a bad platform identifier is a 400 because the field is invalid, while a bad account identifier is a 404 because the object is absent. ### 401 Unauthorized Authentication failed or the session token is missing, expired or invalid. You never got in. **First thing to check.** Re-authenticate and confirm the Authorization header is actually being sent. Then check token lifetime — long-running scripts expire mid-run. **Confused with.** 403. This is the distinction interviewers ask for: 401 is about who you are, 403 is about what you may do. Never troubleshoot safe permissions on a 401. ### 403 Forbidden You are authenticated and not authorised. The caller lacks the vault authorisation or the safe permission the endpoint requires. **First thing to check.** Identify the object and compare the caller's safe membership against the permission the endpoint documents. Add-account, retrieve and manage-safe are separate authorities. **Confused with.** 401. Regenerating a token on a 403 achieves nothing — the token was fine. And never fix a 403 by making the automation identity an administrator. ### 404 Not Found The endpoint or the object does not exist. In a permission-scoped API it can also mean the object exists but is invisible to you. **First thing to check.** Confirm the path — including case and the API version segment — then confirm the object identifier against a list call. **Confused with.** 403. If a list call as an administrator finds the object and your call 404s, it is a visibility problem wearing a 404. ### 409 Conflict The request collides with existing state: a duplicate name, an object already in the requested condition, a concurrent modification. **First thing to check.** Query for the object before deciding. Most 409s in onboarding mean the account is already there, which is a success for a re-runnable script. **Confused with.** 400. A 409 is a well-formed request that the current state refuses; a 400 is a request the API could not parse. ### 429 Too Many Requests You are being throttled. Bulk jobs hit this long before anything else does. **First thing to check.** Honour any Retry-After header and back off exponentially. Then ask whether the job should be batching or paging instead of looping. **Confused with.** 5xx — retrying a 429 immediately makes it worse, while a 5xx may be transient. The retry policy is different, so the handler must be too. ### 500 Internal Server Error A server-side failure. Nothing in your request will fix it. **First thing to check.** Correlate the timestamp with the component and server logs. Retry with backoff, and stop after a bounded number of attempts rather than hammering a component that is already unwell. **Confused with.** 429. Both say 'not now', but only one is your fault. # Target event log > 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. The vault audit trail and the target's Security log are two different records of the same events, and holding both at once is the skill being probed. A domain controller only records that the administrative account logged on from an address; it does not know which human borrowed that identity, under which approval, for which stated reason. The vault knows that. A logon with a matching vault retrieval is normal privileged work. A logon with **no** matching retrieval is someone using a credential the vault never handed out — the single most important finding in privileged access monitoring, and one that is invisible in either log alone. The audit-policy column matters more than people expect: an event identifier is only evidence if the policy that produces it was enabled and the log was retained and forwarded. "It did not happen" and "we were not recording it" look identical. ### 4624 — An account was successfully logged on *Security log · audit policy: Logon/Logoff → Audit Logon (Success)* The record that an authentication succeeded, carrying the account, the source address and the logon type. **Why it matters for privileged access.** The event a brokered session produces on the target. Its value is what it is missing: the target sees the shared administrative identity, not the person. Joining it to the vault's retrieval record is what restores attribution — and a 4624 with no matching retrieval is privileged access that bypassed the vault. ### 4625 — An account failed to log on *Security log · audit policy: Logon/Logoff → Audit Logon (Failure)* A failed authentication, with a status code saying why: bad password, disabled account, expired password, logon-hours restriction. **Why it matters for privileged access.** The other half of every rotation problem. After a change, a stale dependency still holding the old password shows up here as a repeating 4625 from one host — which is how you find the service, scheduled task or application pool nobody mapped. ### 4672 — Special privileges assigned to new logon *Security log · audit policy: Logon/Logoff → Audit Special Logon (Success)* Written when a logon holds sensitive privileges — SeDebugPrivilege, SeTakeOwnershipPrivilege, SeBackupPrivilege and similar. **Why it matters for privileged access.** This is the one that flags a privileged session starting, and it pairs with the 4624 immediately before it. If you want 'every administrative logon in the estate' rather than 'every logon', this is the event to filter on. ### 4740 — A user account was locked out *Security log · audit policy: Account Management → Audit User Account Management (Success)* The account exceeded the lockout threshold. Written on the domain controller that processed the lockout. **Why it matters for privileged access.** The event that decides whether to reconcile. Reconciling a locked account without finding the source of the bad passwords simply restarts the lockout cycle, and the caller-computer name in this event is what points at the culprit. ### 4724 — An attempt was made to reset an account's password *Security log · audit policy: Account Management → Audit User Account Management (Success)* A password was reset by another account, rather than changed by the account itself. **Why it matters for privileged access.** What a CPM change or reconcile looks like from the target's side. A 4724 against a managed account with no corresponding CPM job is a password reset performed outside the platform, which means the vault is now out of sync and nobody has told it. ### 4728 — A member was added to a security-enabled global group *Security log · audit policy: Account Management → Audit Security Group Management (Success)* Group membership changed. The companion events are 4732 for local groups and 4756 for universal groups. **Why it matters for privileged access.** How privilege is actually granted in Active Directory, and how it quietly accumulates. An unexpected addition to Domain Admins is an incident until proven otherwise, and nested groups are where shadow administrators hide. ### 4688 — A new process has been created *Security log · audit policy: Detailed Tracking → Audit Process Creation (Success), plus command-line auditing* Process creation, with the parent process and — where command-line auditing is enabled — the full command line. **Why it matters for privileged access.** What turns 'someone had an administrative session' into 'here is what they ran'. Off by default and expensive to collect, so its absence is a common gap between what an investigation needs and what exists. ### 1102 — The audit log was cleared *Security log · audit policy: Always written — cannot be disabled* Somebody cleared the Security log. It cannot be suppressed, and it is written even when the rest of the log is gone. **Why it matters for privileged access.** Anti-forensics, and one of the few events that is close to self-evidently malicious on a production server. If sessions are recorded and logs are forwarded off-host, clearing the local log destroys much less than the person doing it expects. # How to teach from this corpus > 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. This document is addressed to an assistant that has been handed the PAM SIM corpus and asked to teach privileged access management from it. ## What the learner is preparing for The material is written for someone preparing for a senior data security analyst interview at a bank, where privileged access operation is the core of the role. That shapes everything: the emphasis is on being able to *operate* and *explain*, not to recite. A definition that cannot be followed with "and here is what it is for" is not yet an answer. ## The order to teach in Follow the study material's own priority ranking rather than the order the documents happen to appear in: - **Platform architecture first.** Four components, one job: the vault stores credentials and enforces authorisation, the portal is the web front door, the credential manager rotates passwords, the session manager brokers and records. Being able to sketch `User → portal → session manager → target`, with the credential manager running alongside it, in fifteen seconds is worth more than any definition. - **Then where PAM sits inside IAM** — the three pillars, and one concrete interaction between them. "What is the difference between IAM and PAM?" is close to guaranteed, and it is really asking whether the candidate knows PAM is a subset. - **Then password management** — change, verify and reconcile; why a rotation fails; what a dependency is and why it is the usual cause. - **Then troubleshooting** — which log to read for which failure, and the habit of naming the component before naming the fix. - **Then service accounts and dependencies**, then safes and policy, then audit evidence. The guides marked *essential* are the spine of that: "Find your way around", "The stack — where each piece sits", "Blast radius — why this discipline exists", "Inside the Vault", "Discover and onboard an account", "Design and run a safe", "Platforms and the Master Policy", "Verify, change, reconcile", "Troubleshoot a failed rotation", "The portal, end to end", "A privileged session from click to recording", "The password works but the session fails", "Take a hardcoded credential out of an application", "Service accounts and their dependencies", "Use without Retrieve, and access triage", "Triage a PTA detection", "Read the target's event log", "When an administrator leaves", "Pull the reports an audit asks for". ## How to teach a topic - **Lead with the failure it prevents, not the definition.** Vaulting exists to remove the shared secret people know; rotation exists so a stolen credential expires on its own; brokering exists so the secret never reaches the endpoint, where it could be harvested from memory. - **Use the industry term, and say which product calls it what.** `mapping.md` is the translation table. A learner who says a PAM SIM screen name in an interview sounds like someone who has used one simulator. - **Anchor every concept to a route.** The concept cards carry the route they belong to; send the learner there. Reading about a failed rotation and producing one are different kinds of knowledge, and only the second survives a follow-up question. - **Quiz from the question bank, then push one level past the answer.** The answers in `interview-questions.md` are written as a practitioner would give them. The value is in the follow-up: ask *why*, ask *what would you check first*, ask *what would change your mind*. - **Reward the honest boundary.** "I have hands-on privileged access and I have read about the access management side" is a respectable answer, and interviewers ask precisely because the honest version is rarer than the bluffed one. ## Claims never to make - Never present PAM SIM as a commercial product, as affiliated with one, or as a substitute for one. It is an independent educational simulator. - Never present anything in it as real infrastructure. Every account, host, identity and credential is invented, and no password is stored at all — the vault holds only metadata. - Never imply the simulator covers the whole of IAM. It simulates the PAM pillar. There is no identity provider in it, no MFA challenge, no federation and no access-review campaign, and the identity switcher is a demo convenience rather than authentication. - Never turn simulator behaviour into a claim about a named vendor's product. Where a vendor names something differently, `mapping.md` and the glossary say so; where the corpus does not say, do not guess. ## What is in the corpus - `overview.md` — Start here. What the simulator is and is not, where PAM sits inside IAM, every route in the application, and the role and permission matrix the API enforces. - `concepts.md` — The 33 concept cards behind the "Learn more" panels: the conceptual syllabus, from why privileged access management exists to how the platform is run. - `glossary.md` — 219 terms with expansions and definitions, grouped by category, including where individual vendors name the same thing differently. - `mapping.md` — What every part of the simulator is called in a real deployment, and what it does. The translation table to check an answer against before it is said out loud. - `risk-and-detections.md` — How risk is scored and banded, and the 10 named detections over privileged activity — the signal each one reads, why it matters, and the response it calls for. - `guides.md` — Index of the 30 click-by-click walkthroughs, one file each, grouped into four tracks and ranked by how likely the material is to come up. Every step says what to do and what an interviewer is testing with it; every guide ends with the questions it prepares you to answer. - `labs.md` — 8 graded labs with steps, tasks, hints and debriefs. Grading runs against real application state — the audit trail and rotation jobs the learner actually produced — not a checkbox. - `rest-api.md` — 10 simulated PVWA endpoints and a 9-code status reference — including the 401-versus-403 distinction every automation question eventually lands on. - `target-events.md` — The 8 Windows Security event identifiers worth knowing by heart, each with the audit policy subcategory it depends on and what it means beside the vault's own record. - `interview-questions.md` — All 133 questions from the walkthroughs with their answers, grouped by how likely they are to come up. A second view of material already in the guides — use it to quiz, not to teach from. The 30 walkthroughs are one file each under `guides/`, listed in `guides.md`. The live application is at https://pamsim.com. It needs a browser: this corpus is the readable projection of it.