CyberArk PAM-DEF common mistakes
CyberArk PAM-DEF · Understand the traps and how to avoid them.
Treating CyberArk's safe hierarchy as if permissions were inherited automatically from parent safes to child safes, and answering that a user with access to a parent safe can retrieve accounts in a nested safe.
Candidates carry over intuition from filesystem or AD-style inheritance; in CyberArk, safe membership and safe authorization are defined per safe, and nesting safes organizes them in the UI rather than conferring access.
What to do instead
Memorize that access to accounts is granted through membership in the specific safe (or through a safe that explicitly holds the account), and that being a Safe Admin or member on one safe does not cascade to sibling or child safes unless the user is separately authorized.
Assuming that adding a user to a group in the Vault (or to an LDAP group mapped into CyberArk) grants access immediately, without considering that the user must log out and back in or that the group must be added to the safe.
Authorization is evaluated at authentication time and cached in the user's session token; candidates forget the session-refresh step and pick 'access is instant' answers.
What to do instead
Recall that safe membership changes take effect on the user's next logon (or after the session is refreshed), and that LDAP group membership must be mapped and the group added as a safe member before it confers any rights.
Confusing the CPM (Central Policy Manager) with the PSM (Privileged Session Manager): attributing session recording, isolation, and jump-host proxying to the CPM, or attributing password rotation and verification to the PSM.
Both are Vault-managed components that act on accounts, and exam items describe outcomes ('the password was changed', 'the session was recorded') without naming the component.
What to do instead
Anchor each component to its verb: CPM changes/verifies/reconciles credentials on managed systems; PSM brokers, isolates, and records sessions. Read the outcome in the stem and map it to the component that produces it.
Answering that a CPM change will succeed on a target where the account's platform is misconfigured or the reconciliation account lacks rights, instead of recognizing that failed CPM operations leave the password in a 'failure' state requiring manual or automatic retry.
Candidates focus on the CPM's scheduling and forget the dependencies: correct platform, reachable target, and a privileged reconciliation account with permission to reset the managed account.
What to do instead
When a stem describes a CPM failure, check the chain in order: platform association, network/firewall reachability, reconciliation account privileges, and account state. The fix is usually to correct the platform or reconciliation account, then re-run the change.
Selecting 'the user can see the password in the PVWA' as the reason an account is accessible, when the real gate is the 'Use password' / 'Retrieve password' authorization plus the account's safe membership and any dual-control or request workflow.
The UI shows accounts a user can view but not necessarily retrieve; candidates conflate visibility with retrieval rights.
What to do instead
Separate the authorizations: safe membership grants visibility; 'Retrieve password' or 'Connect' authorizations grant use. Dual control and access-request workflows add a second approver before retrieval. Identify which authorization the scenario is actually testing.
Treating a CyberArk 'platform' as only the OS type, and answering that changing the target OS automatically changes rotation behavior, rather than recognizing the platform defines the rotation/verification/reconciliation logic and must be associated to the account.
Platforms bundle policy (password rules, CPM plugins, connection components); candidates underestimate how much behavior lives in the platform versus the account or safe.
What to do instead
Recall that the platform controls how the CPM changes and verifies the password and which connection components PSM uses. To change behavior, associate the correct platform to the account (or edit the platform), not just the OS field.
Assuming EPM (Endpoint Privilege Manager) removes local admin rights by policy alone, without accounting for the agent deployment, policy targeting, and the elevation request/approval flow that actually enforces least privilege on endpoints.
EPM is agent-based; candidates answer as if a console setting instantly applies to all endpoints, ignoring agent health, policy scope, and the request-and-justify workflow.
What to do instead
For EPM scenarios, verify the agent is installed and healthy on the endpoint, the policy is scoped to the correct target set, and the elevation path (auto-elevate, request-and-approve, or block) is configured. The enforcement point is the agent applying policy, not the console alone.
Confusing application identity and secrets management constructs: treating a CCP/central credential provider call, an application's authentication to the Vault, and a managed account's password as interchangeable, and answering that an app can retrieve any account it can name.
Secrets management items blend application authentication, authorization to the safe, and the retrieval mechanism; candidates collapse these into one step.
What to do instead
Model the flow explicitly: the application authenticates to the Vault (or via CCP), is authorized as a safe member with retrieve rights for that account, and only then receives the credential. Authorization is per safe, not per account name.
Answering that rotating a secret in the Vault automatically updates every consumer, rather than recognizing that dependent applications must fetch the new secret (or be restarted/reconfigured) after rotation.
Candidates assume the Vault pushes credentials to consumers; in practice consumers pull credentials, so a rotation can break apps still holding the old value.
What to do instead
Recall the pull model: after CPM rotates an account, consumers retrieve the new value via CCP/SDK or are reconfigured. When a stem shows an app failing after rotation, the cause is a stale cached credential, not a failed rotation.
Misreading dual control and access-request workflows as the same control, and answering that dual control means the requester confirms their own request, or that an access request needs no approver.
Both involve a second party, so candidates merge them; dual control requires a second authorized user to confirm the action, while access requests route to designated approvers under a workflow.
What to do instead
Distinguish them: dual control = a second authorized user must confirm the same operation before it proceeds; access request = the user requests time-bound access and an approver grants it. Identify which control the scenario describes before choosing.