The interview question that trips up 70% of candidates
Senior PAM interview: "In CyberArk, what's the difference between Connect and Retrieve, and why does it matter for audit?"
Wrong answers: "They're the same", "Retrieve is more secure because it's manual". Right answer: Connect launches a PSM-proxied session — the PSM server injects the credential into the target, so the password is never shown to the user and the entire session is recorded. Retrieve shows the plaintext password on screen, the user pastes it into their own RDP/SSH client, and PSM records nothing. For a SOX or SEBI audit, Connect gives you tamper-proof proof of what happened; Retrieve gives you a blind spot. That single distinction separates the candidates who have run CyberArk in production from the ones who only read the brochure.
💡 The bank locker room analogy
Picture an SBI bank locker room. The Vault is that room — even the branch manager can't open your locker alone. To get in, you sign the register with a reason (request + ticket), the manager turns the second key (dual control approval), and they note the exact time you went in and came out. While your locker is open, nobody else can touch it (exclusive checkout — the padlock icon). When you leave, the manager re-seals it and changes the seal (checkin + CPM rotation). And if you ever forget to come back, after the minimum window the manager reclaims the key and re-seals it anyway. Standing access is the opposite — it's handing every staffer a permanent copy of the master key. CyberArk's whole job is to make sure nobody walks around with that copy in their pocket.
4 things you'll be tested on before we begin
Exclusive access locks an account to one user at a time (padlock icon). It frees only on manual Check-In or when MinValidityPeriod expires and CPM rotates. So what: two engineers can't grab the same root password at once.
Time-boxed privilege granted on demand, revoked automatically. Default ad-hoc window = 4 hours. So what: no standing admin to steal between tasks — the attacker has to catch a tiny window.
A second authorized Safe owner must approve before you retrieve or connect. Two layers: Master Policy flag + Safe-level Authorize password requests. So what: miss layer two and the queue has no approver — permanently stuck.
Connect = PSM session, password never shown, full recording. Retrieve = plaintext on screen, no recording. So what: disable Retrieve on production Safes or your audit has blind spots.
① The access lifecycle — request, approve, checkout, use, checkin
Every privileged session in CyberArk runs the same five-stage loop through PVWA: request → approve → checkout → use → checkin. Skip a stage and you've either blocked your engineers or punched a hole in the audit trail. The portal is just the human surface; underneath, the CPM rotates passwords and the Vault records everything over the proprietary protocol on port 1858.
Kavita Sharma, PAM architect at a 45,000-employee RBI-regulated bank, faced a SEBI CSCRF audit. Vendors had been given shared service accounts with passwords in an Excel sheet — no time-boxing, no recording, no approval. The auditor asked who touched the Oracle DBA account on 10.10.5.32 at 11 PM, and all Kavita had was a 6-month-old email. Major non-conformity. The fix was the lifecycle below: every vendor session now runs request → dual approve → PSM Connect → recorded → auto-revoke.
A Windows team checked out a shared local-admin password for a quick change, then closed the browser without clicking Check In. The account stayed locked for the full MinValidityPeriod (60 min) while two other engineers were blocked mid-incident. The original user was on a flight and couldn't release it. An admin finally released it from PVWA's Locked Accounts view, which fired an immediate CPM rotation. The permanent fix: set AutoUnlockEnabled=Yes so session termination auto-checks-in.
Recreated for clarity🗝️ The exact screen you'll use — PVWA → Accounts → Add Account. Your console matches this layout.
② Just-in-Time vs standing access — why always-on is the risk
Standing access means a privileged account or group membership exists all the time, whether you're using it or not. That's the attack surface: steal one laptop with cached Domain Admin tokens and the whole domain falls. Just-in-Time flips it — privilege is granted for the task, then revoked. CyberArk ships three canonical JIT methods: broker-and-remove (vaulted credential with timed checkout), ephemeral accounts (create-and-delete per session), and temporary elevation (add to a local admin group for ~4 hours, then remove).
Arjun Pillai, Sr. IAM engineer at a 5,000-person Pune IT firm, had 15 senior engineers all carrying permanent Domain Admin. A red team owned the domain in 4 hours from any one laptop. Removing admin from two pilot engineers backfired — they needed it constantly for GPO changes and patching, productivity collapsed, and the mandate was politically reversed in a week. The real fix was JIT: onboard the DC admin account, strip standing membership, and let engineers request a 2-hour window with a CHG ticket. Standing Domain Admins dropped 15 → 0, and the next red team took 48 hours instead of 4 — a 12x improvement.
▶ Watch a JIT grant window open and close
Vendor needs 2 hours on a production server. Request → dual approve → PSM Connect → session recorded → auto-revoke + rotate. Press Play.
root-10.10.5.32, clicks Request Access. Enters reason + ticket INC0045892 + a 2-hour window.13:02.443 — no VPN, no RDP. PSM injects the credential server-side; the password is never shown.root password within minutes. The credential the vendor used is now dead.You're at a Mumbai bank. A third-party vendor needs 2-hour access to production server 10.10.5.32, and the auditor will later demand proof it was time-boxed and approved. Which CyberArk workflow produces that evidence?
Pause & Predict A Linux admin needs root on a single host for a 30-minute patch, and the SOC wants zero privileged account to exist on that box one minute after the job ends. Of CyberArk's three JIT methods — broker-and-remove, ephemeral accounts, temporary elevation — which one leaves the smallest standing footprint, and why?
③ Dual control & ticketing — approval chains and the trap that blocks everyone
Dual control means a user must get explicit confirmation from an authorized Safe owner before retrieving or connecting. It is a two-layer setting, and missing the second layer is the single most common CyberArk outage. Layer one: enable Require dual control password access approval in the Master Policy. Layer two: grant the Authorize password requests permission to specific Safe members. For higher-risk accounts you can add Level 1 + Level 2 approvers. Requests sit in the Safe for 30 days by default; expired or consumed requests can't be re-activated.
A large BFSI firm enabled Require dual control at Master Policy for all production Linux root accounts. Six months later, during a P1 database outage, every DBA was blocked — PVWA showed "waiting for confirmation" with zero approvers. Root cause: nobody had been granted Authorize password requests on the Safe. The Master Policy flag was on; the Safe-level layer was never configured. Recovery needed an emergency PrivateArk Server console login (which bypasses PVWA) to grant the permission and release the account — a near-miss that cost 3 hours of downtime.
Ticketing integration raises the bar: PVWA can validate a ServiceNow ticket before granting. The plugin ships in the PVWA Bin directory and validates INC and CHG ticket types by default. A read-only service account (with sn_change_read and sn_incident_read roles) is onboarded into the PVWATicketingSystem Safe so CPM rotates its credentials. A FailsafeBypassCode covers emergencies when ServiceNow is unreachable — and that code is exactly what you must protect.
A PAM architect documented a cascading failure: during an Active Directory outage, users couldn't authenticate to PVWA (LDAP-dependent) or create ServiceNow tickets (AD-dependent). The FailsafeBypassCode was stored in a wiki page any IT staffer could read. An attacker who knows this pattern can wait for (or trigger) an AD disruption, then use the bypass code against the ticketing check to reach production root with no approval. The mitigation: store the bypass code itself inside a Vault break-glass Safe, requiring out-of-band recovery to retrieve it.
Rahul, an engineer at a Bengaluru fintech, enables "Require dual control password access approval" in the Master Policy for a Safe of production root accounts. But users still retrieve passwords with no approval. What's the most likely cause?
Authorize password requests permission is layer two and decides who can approve. Miss layer two and the gate has no approver — the most common CyberArk mis-config. (a/c/d) would block access entirely, not let it through unapproved.Recreated for clarity🎫 The exact screen you'll use — PVWA → Accounts → [account] → Request. Your console matches this layout.
Pause & Predict You enabled Require dual control password access approval in the Master Policy, but every request now sits forever in "Pending" and nobody can approve it — access is fully blocked. The flag is on. What single thing did you forget to configure, and where?
④ Connect vs Retrieve — and driving it all from the REST API
Connect and Retrieve are two fundamentally different operations. Connect launches a PSM-proxied session: PSM injects the credential into the target server-side, the password never reaches the browser, and the whole session is recorded as a tamper-proof AVI in the Vault (~70 KB/min console, ~200 KB/min GUI). Retrieve returns the plaintext to the user's screen — they copy-paste it into their own client, and PSM records nothing. Hardening rule: disable Retrieve on production Safes.
A global bank's internal audit found 40% of privileged sessions used Retrieve (copy password, paste into RDP) instead of Connect. Because Retrieve bypasses PSM, those sessions had no recording, no keystroke logging, no live monitoring — a SOX control failure. Root cause: connection components were broken for several legacy platforms, so users worked around them with Retrieve. The fix took three parts: repair the connection components, train users, and add a PVWA policy that disables the Retrieve button for production Safes while leaving it on for dev.
For automation, PVWA exposes a REST API at /PasswordVault/API/ (swagger at /PasswordVault/swagger/docs/v1). You log on for a token, search accounts, retrieve with a reason + ticket, and check in — the same lifecycle, scripted. Here's the retrieve call with reason enforcement:
POST https://pvwa.corp.internal/PasswordVault/API/Accounts/48_3/Password/Retrieve
Content-Type: application/json
Authorization: <$TOKEN>
{
"reason": "Emergency patch deployment - INC0045892",
"TicketingSystemName": "ServiceNow",
"TicketId": "INC0045892",
"ActionType": "show"
}HTTP 200 OK "R@nd0mP@ssw0rd2024!" # Account is now exclusively locked to this user (padlock in PVWA). # CPM will NOT rotate until MinValidityPeriod expires or manual Check-In. # If dual control is required and unapproved: HTTP 403 # ITATS262E You are not authorized to perform this action
And the check-in that releases the lock and triggers rotation:
POST https://pvwa.corp.internal/PasswordVault/API/Accounts/48_3/CheckIn
Content-Type: application/json
Authorization: <$TOKEN>
{}HTTP 200 OK
{}
# Lock released immediately. CPM schedules an immediate rotation.
# Padlock icon disappears. Other users can now checkout the account.A PVWA session token expires after ~20 minutes of inactivity, but don't leave it lying around. Call POST /PasswordVault/API/Auth/Logoff when your automation finishes — abandoned tokens count against concurrent-session limits and are an attack surface if intercepted. In a SIEM, an unusually long-lived API token on the PVWA front door is a signal worth alerting on.
Pause & Predict An auditor asks you to prove that a vendor who touched a production database server never actually saw the plaintext password. The access was brokered through PVWA. Which operation must you have used — Connect or Retrieve — and what single artefact do you hand the auditor as proof?
Your automation calls the PVWA REST API to pull a credential for a scripted job. The very first call after building the request body returns nothing useful and every later call is rejected. Which step did the script skip?
Logon first to get a session token, then Retrieve (with a reason) or trigger a Connect, then Checkin. (b) is wrong — Retrieve is fully supported via REST. (c) is wrong — every call is authenticated by the session token, not open. (d) is wrong — the API honours dual control; an un-approved request returns a 403 with ITATS262E until an authorizer approves it.🤖 Ask the AI Tutor
Tap any question — instant context-aware answer.
Deeper questions → chat.techclick.in.
The 5 mistakes that cost L1/L2 candidates the interview
Master Policy flag on, Safe-level Authorize password requests never granted. The queue has no approver and everyone is blocked during a P1. Always set both layers.
Users copy-paste plaintext and bypass PSM. No recording, no audit — a SOX/SEBI control failure. Disable Retrieve on production Safes; mandate Connect.
User closes the browser without Check In; the account stays locked for the full window and blocks the team. Set AutoUnlockEnabled=Yes.
The ticketing emergency code in plaintext means an AD outage plus that code equals unapproved root access. Store it in a break-glass Safe needing out-of-band recovery.
JIT time-limits an existing role; ZSP creates and deletes ephemeral accounts so nothing exists between sessions. Mixing them up signals you've only read the brochure.
📝 Check your understanding — 10 questions, 70% to pass
Q1–Q2 above already count. Below are Q3 to Q10.
What TCP port does the CyberArk Vault use to communicate with PVWA, CPM, and PSM?
A security policy at a Mumbai bank says vendors connecting to production Linux must never see the plaintext password. Which PVWA method enforces this, and which must be disabled?
Priya, a CyberArk admin at an HCL-scale enterprise, checks out a shared local-admin account in PVWA, then closes the browser without clicking Check In. What happens, and when does it free up?
MinValidityPeriod expires and CPM rotates. (d) is the opposite of exclusive access; (c) never happens.In an agentless JIT-for-Windows deployment at a Pune firm, the PSM service crashes mid-session before the window closes. What's the critical operational risk?
A ServiceNow-integrated PVWA stores its FailsafeBypassCode in the company wiki. During an AD outage, an attacker uses it to grab production root credentials. Which two design failures allowed this?
A Pune IT firm wants to remove always-on Domain Admin from 15 engineers without killing productivity. What's the right CyberArk pattern?
A team debates JIT (temporary elevation of existing accounts) vs ZSP with ephemeral accounts (SIA/DPA) for 50 production EC2 Linux hosts. Compare the residual risk after a credential-theft event.
A CISO calls CVE-2024-54840 (PVWA Host Header Injection, CVSS 4.2, EPSS 0.04%) low priority and wants to defer the patch a quarter. Evaluate whether deferral is justified.
Next up — CyberArk AAM, CCP & Conjur
Now humans request access cleanly. Next: killing hardcoded secrets in apps and DevOps — Application Access Manager, the Central Credential Provider, and Conjur for cloud-native and CI/CD pipelines.
Sources cited inline
- CyberArk Docs — Account Check-out and Check-in
- CyberArk — What is Just-In-Time Access?
- CyberArk Docs — Dual Control & Approval Workflows
- CyberArk + ServiceNow Ticket Integration
- CVE-2024-54840 — PVWA Host Header Injection (before 14.4)
- CyberArk — Zero Standing Privileges: Myths vs Reality
- CyberArk Remote Access 22.4 — Mobile Dual-Control Approval