CyberArk PAM Interview Questions and Answers (2026)

① Fundamentals — what PAM is, and the four parts of CyberArk

Every CyberArk round opens with fundamentals. The questions sound easy — that is the trap. The panel is not checking the definition; they are checking whether you understand the boundary of each part and how the parts fit together. Format below: the question as asked, a model answer you can say in 20–40 seconds, and the trap hiding inside.

Q1. "What is a privileged account, and why is it the #1 target?"
Model answer: Any account with elevated rights — root, Administrator, a service account (SA), an enable account on a switch, a cloud admin role. It is the attacker's #1 target because one stolen privileged credential is a master key: it moves laterally, disables logging and reaches the crown jewels. Account types you should name: Local, Domain, Service and Shared accounts. The trap: stopping at "the admin account". Service and shared accounts are where real estates bleed — naming them signals field awareness.

Q2. "PAM vs IAM — same thing?"
Model answer: IAM governs ALL identities — joiners, movers, leavers, what every employee may access. PAM is the high-security subset for privileged identities: vaulting, rotation, session brokering and audit. IAM decides who gets a gate pass into the office; PAM decides who gets the strong-room key, for how long, and keeps the CCTV running while they hold it. The trap: saying "PAM is part of IAM" and stopping — they want the functional difference (lifecycle vs controlling-privileged-use).

Q3. "Explain CyberArk's core architecture — what does each component do?"
Model answer: Four pieces around one store. The EPV (Vault) is the encrypted store — it only keeps secrets safe, nothing else. The CPM connects to targets to verify, change (rotate) and reconcile passwords. The PVWA is the web UI to request, retrieve and audit. The PSM proxies and records sessions so the password never lands on the user's endpoint. The trap: blurring the Vault and the CPM — the Vault never rotates anything; rotation is the CPM's job.

Q4. "What is a Safe, and why not just put everything in one?"
Model answer: A Safe is a logical container inside the Vault that holds credentials/files, scoped by access. You separate Safes so least privilege is enforced by container: the Unix team only sees the Unix Safe, the DBAs only the DB Safe. CyberArk ships built-in Safes too — System (config, license, logs), VaultInternal (LDAP mapping), the Notification Engine Safe. The trap: "one big Safe is simpler" — it destroys the entire segregation model.

Q5. "Name some built-in Vault users and what the Master user is for."
Model answer: Built-in users include Administrator, Auditor, Master, Batch, NotificationEngine, the PSMApp_* app users, PVWAAppUser and PVWAGWUser; built-in groups include Auditors, PVWAUsers, PVWAMonitor, PSMAppUsers and PSMLiveSessionTerminators. The Master user is the break-glass account — you log in as Master using the Master CD to recover the Vault. The trap: using the Master user for daily admin. It is disaster-recovery only; the Master CD lives offline.

The four parts, one tap each

Tap each card — say what it does before you flip.

② Vault & CPM rounds — layers, ports, CDs, Logon vs Reconcile

This is the deep-knowledge round, and the section that separates "watched a demo" from "ran the platform". Two warnings baked in from the 2026 corrections: do not memorise a version number — Self-Hosted is around v14.x now, so panels reward you for talking about the compatibility matrix (Vault ↔ PVWA ↔ component versions must align) rather than reciting "v11.3". And the OS baseline is Windows Server 2019/2022 with a current .NET, not the 2012/.NET 4.5.2 you will see in old blogs.

Q6. "Name the 7 security layers that protect the Vault."
Model answer: Defence-in-depth: Firewall, Code-Data Isolation, Encrypted Network Communication, Visual Security Audit Trail, Strong Authentication, Granular Access Control and File Encryption — with Dual Control layered on as an access policy. Like a bank locker room: guarded walls, a vault door, encrypted ledgers, CCTV, two-key entry. The trap: mixing in product names — PSM and CPM are components, not Vault security layers.

Q7. "What's on the Master CD vs the Operator CD?"
Model answer: The Master CD holds the Recovery Private Key, Recovery Public Key, Server Key and a random DB key — it is the break-glass key to recover the Vault as the Master user. The Operator CD holds everything except the Recovery Private Key (Recovery Public Key + Server Key + DB key), used for normal start-up. The trap: swapping them — the private recovery key is the one thing the Operator CD must NOT contain, which is why the Master CD is locked offline.

Q8. "How does the CPM keep a password correct on the target — verify, change, reconcile?"
Model answer: Three jobs. Verify = the CPM logs in to confirm the Vault's copy still matches the target. Change = scheduled or on-demand rotation. Reconcile = when the two have drifted out of sync (someone reset it outside CyberArk), the CPM uses a privileged Reconcile account to force-reset the password back into the Vault. The watchman re-keys your locker weekly so a copied key is dead by Monday. The trap: forgetting verify — and not knowing where reconcile is configured (next question).

Q9. "Logon account vs Reconcile account — and where is each set?"
Model answer: A Logon account is how the CPM authenticates when the managed account itself cannot log in directly — e.g. an Oracle account reached via a privileged OS login. A Reconcile account is the privileged account the CPM uses to force a drifted password back in sync. Both are linked on the Platform — not the Master Policy. The trap (the single most-failed CyberArk interview question): saying "Reconcile is set on the Master Policy". It is on the Platform. Say that crisply and the panel knows you have actually onboarded an account.

Q10. "What's in the default Vault config, and which services run?"
Model answer: Default Safes include System, VaultInternal and the Notification Engine Safe. Core Vault services are the PrivateArk Server, the DB, the PrivateArk Remote Control Agent (port 9022, reached with PARClient for remote ops), the Event Notification Engine and the hardened Windows Firewall. Key files: dbparm.ini, vault.ini, passparm.ini, plus paragent.ini for the remote-control agent; logs are ITAlog.log + trace. The trap: not knowing the remote-control agent runs on 9022 — a favourite "do you actually know the box" probe.

Q11. "What is the correct component install order, and why?"
Model answer: Vault → PVWA → CPM → PSM. The Vault must exist first because every other component authenticates to it and stores its app users/Safes there; PVWA provides the web layer and the config Safes the others rely on; CPM and PSM register last. The trap: "CPM before PVWA" — install PSM or CPM before the Vault/PVWA and they have nothing to bind to.

③ PSM & PVWA rounds — sessions, dual control, the real consoles

The session and web layers are where panels test whether you have actually clicked the product. Say the why, then name the exact screen.

Q12. "Explain PSM — and how it stops the password reaching the user."
Model answer: The PSM is a proxy: the user launches a session through PVWA, PSM connects to the target and injects the credential server-side, so the password never lands on the user's endpoint. Every session is recorded (video + keystroke/text) to the PSMRecordings Safe. Default PSM Safes include PSM, PSMLiveSessions, PSMUnmanagedSessionAccounts and PSMRecordings; the app/gateway users are PSMAppUser and PSMGWUser; logs are PSMConsole.log / PSMTrace.log; config is basic_psm.ini. The trap: saying "PSM stores passwords" — it stores nothing; the Vault does. PSM brokers and records.

Q13. "What is PSMShadowUser, and what does PSMP do?"
Model answer: PSMShadowUser is the per-session isolated identity auto-created on the PSM server, so each session is sandboxed under its own throwaway local user. PSMP / PSM-for-SSH is the Linux flavour — a proxy for Unix/SSH targets supporting tunneling and SCP/SFTP. The why: isolation means one compromised session can't pivot into another. The trap: assuming PSM does Linux natively — SSH targets go through PSMP.

Q14. "Walk me through PVWA — prereqs, services, and Dual Control."
Model answer: PVWA runs on IIS (a Windows Server domain member, talking to the Vault on 1858); services include IIS Admin, World Wide Web Publishing and Windows Process Activation; logs are CyberArk.WebConsole/WebApplication/WebTaskEngine.log; config is Web.config, and the config Safes (PVWAConfig holding PVConfiguration.xml + Policies.xml, plus PVWAUserPrefs, PVWAPublicData, PVWAReports, PVWATicketingSystem) live in the Vault. Dual Control is the request/approve workflow before retrieval or a session. The trap: forgetting PVWA needs IIS — it is the only IIS-hosted core component.

Now the two screens panels love to ask about — recreated here so your console matches them.

Pin ① Platform (e.g. WinDomain / UnixSSH / Oracle / CiscoIOS) drives which fields appear; pin ② Safe scopes who can ever see this account; pin ③ is where the Reconcile toggle lives at account level — but remember the reconcile account itself is bound on the Platform. The Additional properties section is collapsible, and "Logon to / Logon account" is optional for targets that can't log in directly.

If more than one connection component is configured, pin ① becomes a dropdown (PSM-RDP / PSM-SSH / PSM-WebApp). Pins ② and ③ are the dual-control gate: Reason and Ticket ID are mandatory on gated Safes, the session opens HTML5 in-browser or as a brokered .rdp, and the red "being recorded" banner plus the toolbar recording dot is what auditors come to see.

④ The 2026 stack, scenarios & the freshness question

This is where panels separate "studied an old blog" from "knows the platform as it ships today". First the modern map (PTA, App Access, EPM, Privilege Cloud / ISP), then scenario answers in the symptom → cause → path → fix → verify structure, then the question that proves you read advisories: can the vault itself be hacked?

Q15. "What is PTA, and what does it actually do?"
Model answer: PTA (Privileged Threat Analytics) analyzes Vault, PSM, SIEM and AD activity to spot anomalies — off-hours access, credential theft, a Golden Ticket, unmanaged privileged accounts — and can auto-respond by rotating or suspending the account. The resident WhatsApp group that pings when someone enters at 3 AM or visits 20 flats in 5 minutes. The trap: calling PTA "just a SIEM" — it is privileged-specific detection with automated response.

Q16. "How does CyberArk stop apps from hardcoding passwords?"
Model answer: Application Access Manager (AAM). The Credential Provider (CP/AIM) is an agent on the app server that fetches the secret locally; the Central Credential Provider (CCP) lets apps call the AIMWebService REST API with no local agent; and Conjur / Secrets Manager Self-Hosted (formerly Conjur Enterprise, plus Conjur OSS) handles DevOps/K8s/CI-CD dynamic machine-identity secrets. The trap: the naming — say "Application Access Manager", not the legacy "AIM" alone.

Q17. "Vault vs EPM — don't they overlap?"
Model answer: No — different estates. The Vault governs server/infra shared privileged credentials; EPM (Endpoint Privilege Manager) removes local-admin rights from workstations (Win/Mac/Linux), enforcing least privilege, app control and credential-theft protection via a SaaS agent. Vault = the server room; EPM = every employee laptop. The trap: "EPM replaces the Vault" — they complement.

Q18. "Self-Hosted, Privilege Cloud, or ISP — explain the difference."
Model answer: PAM Self-Hosted (formerly PAS) = you run Vault/CPM/PSM/PVWA on-prem — for data-sovereignty/regulated workloads. Privilege Cloud = CyberArk hosts the Vault as SaaS; you deploy only the PSM/CPM connectors on-prem. Identity Security Platform (ISPSS) = the unified SaaS umbrella (PAM + Secrets Manager + EPM + Identity SSO/MFA + SIA) under Shared Services. The trap: thinking Privilege Cloud means "the Vault on your premises" — it does not; CyberArk hosts it.

Q19. "Mumbai bank: a contractor used a domain-admin account overnight and nobody knows which human. Design the control."
Answer (structured): Onboard the account into a dual-control Safe, remove direct checkout, force connection through PVWA + PSM with a mandatory Reason/Ticket on connect, record the session, have the CPM rotate-after-use, and let PTA alert on off-hours/anomalous access. Now every use is attributable to a named human, on camera, with the credential dead afterwards. The trap: "just rotate the password" — that gives you no attribution and no recording.

Q20. "Bengaluru DevOps team hardcoded a DB password in a Kubernetes app. Fix it the CyberArk way."
Answer: Remove the secret from code; fetch it dynamically from Conjur / Secrets Manager using the app's K8s machine identity, or via CCP / AIMWebService REST fetch for legacy apps; rotate centrally; and keep Conjur patched — which leads straight to the freshness question below.

Q22. "Which CyberArk cert should I target, and what does it test?"
Answer: Start with CyberArk Defender (PAM-DEF) — a ~90-minute multiple-choice exam; the heaviest topics are Safe, Account and Session management, and the documented top-misses are Reconcile-vs-Logon accounts and the PSM connection components. Then Sentry (install/config) and Guardian/CDE for design. The trap: jumping to Sentry without Defender — panels expect Defender-level fluency first.

⑤ L3 deep-dive — SIA, Secrets Manager/Conjur, CCP, Vault DR, onboarding & EPM

Sections ①–④ pass an L1/L2 panel. An L3 round goes further: the cloud-native access model that is replacing PSM, how applications and pipelines get secrets without a human, how you recover a dead Vault, and exactly how an account gets onboarded. Same format — the question as asked, a model answer, and the trap.

Q23. "What is CyberArk Secure Infrastructure Access (SIA), and how does it differ from PSM / PSMP?"
Model answer: SIA (Secure Infrastructure Access) is CyberArk's newer, cloud-native session-access service in the Identity Security Platform. It is agentless and SaaS-delivered, with built-in high availability and load balancing, and — the headline difference — it can grant access with Zero Standing Privileges (ZSP / just-in-time), provisioning an ephemeral credential for the session instead of always pulling a vaulted one. PSM/PSMP is the mature, on-prem proxy model: a session broker that injects a vaulted credential and records the session, heavy on compliance. The interview line: SIA and PSM coexist — you can run both. SIA is the Zero-Trust/cloud direction and is great for SSH/RDP and cloud-console access; for fat clients (vCenter/ESX, thick-client web apps) CyberArk still steers you to PSM. The trap: saying "SIA replaced PSM". It is positioned to eventually replace PSM/PSMP but today they run side by side, and the real differentiator to name is ZSP vs always-vaulted.

Q24. "Explain the Central Credential Provider (CCP) / Application Access Manager — how does an app get a secret with no hardcoded password?"
Model answer: Under Application Access Manager (AAM) there are two delivery models. The Credential Provider (CP / AIM) is a local agent on the app server that fetches and caches the secret from the Vault at runtime. The Central Credential Provider (CCP) is the agentless version: the app calls the AIMWebService REST API over HTTPS (e.g. GET /AIMWebService/api/Accounts?AppID=…&Safe=…&Object=…) and gets the secret back — no agent on the app box. The key is how the AppID is authenticated: CyberArk verifies the calling application against one or more characteristics — application path, OS user / Windows-domain user, executable hash, IP address, or a client certificate serial number — so a stolen AppID string alone is useless. A secure cache means it does not hit the Vault on every call. The trap: describing it as "an API key the app stores". There is no stored password — the app proves what it is (path/hash/OS-user/cert), and CCP returns the secret just-in-time.

Q25. "How does Conjur's policy-as-code model secure CI/CD secrets — policies, hosts, layers, variables?"
Model answer: Conjur / Secrets Manager manages machine-identity secrets declaratively in YAML policy files kept in Git and loaded into Conjur. The core nouns: a policy is the declarative rule-set (who/what may access which secret); a host is a machine/workload identity (an app, a pipeline runner) that authenticates with an API key or a platform authenticator; a layer is a group of hosts so you grant privileges to the role not each box; a variable is the secret itself (DB password, API key); and permissions (!permit) bind a role to read/execute on a variable. A Host Factory hands identity to machines created by automation (auto-scaling, CI agents) so newly-spun nodes self-enrol. Apps in Kubernetes authenticate via the K8s/JWT authenticator (their service-account identity), never a stored password. The trap: treating Conjur like the EPV — it is not the same store as the password Vault; it is dynamic, machine-identity, code-driven secrets, and the best-practice answer is "policy in version control, peer-reviewed before load".

Q26. "Describe CyberArk Vault DR / replication — how do you recover from a primary Vault failure?"
Model answer: CyberArk runs a Primary–DR topology. The DR Vault is a stand-by replica on a dedicated remote machine, kept in sync by the PADR (PrivateArk Disaster Recovery) service — config in PADR.ini, logs in PADR.log. Replication is continuous: metadata via full export + incremental binary logs after each Vault action, and Safe files/folders copied across. On a real outage you perform a failover — the DR Vault syncs the last data, starts the PrivateArk Server (and ENE) and becomes the live Primary; when production is healthy you do a controlled failback. In larger estates you can run Distributed/Satellite Vaults, where a Satellite can be promoted to Primary and the rest then replicate from the new Primary. The interview point: failover can be automatic or manual, and you must protect the keys — the Server Key/Recovery keys still gate the DR Vault. The trap: calling the DR Vault "a backup". A backup is cold and point-in-time; the DR Vault is a live, continuously-replicated, promotable standby.

Q27. "Walk me through onboarding a privileged account end-to-end."
Model answer: In PVWA → Accounts → Add account: pick the System type / Platform (WinDomain, UnixSSH, Oracle, CiscoIOS…), choose the Safe (which scopes who can ever see it), enter address/username/password, then set automatic management (Verify / Change / Reconcile). If the target cannot log in directly, link a Logon account; if drift must be auto-healed, ensure a Reconcile account is linked on the Platform. For scale you bulk-onboard with Accounts Discovery (scan-and-onboard) or the REST API / Privilege Cloud bulk upload rather than typing each one. The trap: onboarding without setting Verify first — verify proves the Vault copy matches before you let the CPM start rotating, so you do not lock yourself out of a production box.

Q28. "Vault vs EPM again, but deeper — what does EPM actually enforce on an endpoint?"
Model answer: EPM (Endpoint Privilege Manager) is a SaaS, agent-based control on endpoints. It removes standing local-admin rights, then elevates only approved actions just-in-time (an allow/elevate/deny policy per application), enforces application control (allow-list / block / greylist with reputation), and adds credential-theft protection — blocking tools that scrape OS/browser/credential stores (e.g. Mimikatz-style harvesting of cached creds and tokens). The Vault, by contrast, governs shared server/infra privileged credentials. The interview line: EPM enforces least privilege on the box; the Vault brokers shared privileged accounts — they complement, neither replaces the other. The trap: describing EPM as "antivirus" — it is least-privilege + app control + credential-theft defence, not signature AV.

Q29. "PSMP / PSM-for-SSH internals — how does the Linux side actually work?"
Model answer: PSMP (PSM for SSH) runs on Linux and proxies SSH/SFTP/SCP sessions to Unix targets. The user SSHes to the PSMP host (often as vaultuser@target@psmp-host syntax or via a connection component), PSMP pulls the target credential from the Vault, injects it, and the human never sees it. It supports SSH key management as well as passwords, command-level audit/recording, and SSH tunneling for SCP/SFTP. Sessions are recorded centrally like PSM. The trap: assuming plain PSM handles Linux — Windows RDP goes through PSM, Unix SSH goes through PSMP; and increasingly SIA is offered for SSH access with Zero Standing Privileges.