CyberArk CDE (CAU302) study materials
CyberArk CDE (CAU302) study resources

CyberArk CDE (CAU302) common mistakes

CyberArk CDE (CAU302) · Understand the traps and how to avoid them.

Mistake 1

When onboarding an account, the candidate creates the account object but skips the platform's required verification steps (for example, not confirming the CPM can reconcile the password or not assigning a valid platform with the correct credentials), then assumes the account will rotate.

Candidates treat onboarding as a pure data-entry task and forget that a CyberArk account is only functional when the platform, address, username, and password/SSH key are all valid and the CPM can actually reach the target. They also confuse 'account created' with 'account managed'.

What to do instead

Walk the onboarding checklist explicitly: correct platform assigned, valid address and port, working credentials stored, and then run a manual 'Change' or 'Verify' from the CPM to confirm the account is manageable before declaring it onboarded. Know the difference between Verify, Change, and Reconcile and when each is used.

Mistake 2

The candidate creates a Safe and adds members but grants overly broad or wrong permissions (for example, giving 'Full' or 'Safe Admin' when 'Use' or 'Retrieve' is intended), or forgets to add the CPM as a member so it cannot manage accounts in the Safe.

The permission model has many granular rights (Use, Retrieve, List, Add, Update, Delete, Manage Safe, Manage Safe Members, Authorize, Audit, etc.) and candidates memorize a few and guess the rest. They also forget that the CPM requires its own membership in the Safe to rotate accounts.

What to do instead

Learn each Safe member permission and its effect, and practice mapping a role (end user, CPM, auditor, Safe admin) to the minimal permission set. Always verify the CPM user is a member with the rights needed to manage the accounts in that Safe.

Mistake 3

The candidate misconfigures the platform's CPM settings, such as leaving the default password change or reconcile commands that do not match the target system, or ignoring the platform's connection components and timeouts, then blames the target when rotation fails.

Platform management is configuration-heavy and candidates skim the platform properties. They do not distinguish master policy from platform policy, and they do not check that the platform's change/reconcile/verify commands and connection components match the target system and its authentication method.

What to do instead

Study the platform property tabs (UI & Workflows, Automatic Password Change, Password Reconciliation, Session Management, etc.) and know which settings are platform-level versus master-policy-level. When troubleshooting, confirm the platform's CPM commands and connection components are correct for the target before touching the account.

Mistake 4

The candidate cannot explain how PSM connects to a target: they confuse the PSM server role, the connection component, and the connector, and they misconfigure the PSM to target the wrong address or port, so sessions fail or bypass the PSM.

PSM architecture has several moving parts and candidates blur them together. They also assume the PSM is the same host as the Vault or forget that the PSM must be able to resolve and reach the target, and that the target must permit the PSM's connection method.

What to do instead

Draw the flow: user -> PVWA -> Vault -> PSM -> target. Learn the role of the connection component and connector, and verify PSM-to-target network reachability, credentials, and the platform's session settings. Practice a live RDP and SSH session through the PSM.

Mistake 5

The candidate mixes up authentication and authorization concepts: they confuse the Vault's authentication methods (CyberArk, LDAP, RADIUS, SAML, etc.) with the authorization model (Safes, permissions, master policy), and they cannot say where a given control lives.

These topics overlap in the UI and documentation, and candidates study them as one blob. They also forget that directory mappings and authentication methods are configured at the Vault/directory level, while access to accounts is governed by Safe membership and master policy.

What to do instead

Separate the concepts explicitly: authentication proves identity (Vault, LDAP, SAML, RADIUS, PKI), authorization grants access (Safes, permissions, master policy). Map each exam scenario to 'who is the user, how do they authenticate, and what Safe permission or policy grants the action'.

Mistake 6

The candidate cannot trace why a user can or cannot access an account: they ignore master policy settings (such as dual control, exclusive access, or 'require reason'), or they forget that Safe permissions and master policy both apply and the more restrictive wins.

Access control in CyberArk is layered: Safe membership permissions, master policy, and platform settings all interact. Candidates check only one layer and stop, or they assume Safe 'Full' overrides master policy restrictions.

What to do instead

Practice a layered access review: identify the user's Safe membership and permissions, then the applicable master policy settings, then any platform or account-level overrides. Remember that master policy restrictions (dual control, exclusive access, reason required) apply on top of Safe permissions.

Mistake 7

The candidate cannot locate or interpret audit evidence: they do not know where to find Safe, account, or session audit records, or they confuse the PVWA reports with the Vault audit log, and they cannot answer a question about who accessed what and when.

Monitoring and reporting span several interfaces (PVWA reports, the Vault audit, PSM session recordings, SIEM integration) and candidates do not build a mental map of which source answers which question.

What to do instead

Learn the reporting and audit surfaces: PVWA reports for account and Safe activity, the Vault audit for system events, and PSM recordings for session playback. Practice answering 'who accessed account X and when' and 'what changed on Safe Y' from the correct source.

Mistake 8

When a CPM password change fails, the candidate immediately resets the password manually on the target or disables the account, instead of diagnosing the failure (connectivity, credentials, platform commands, or CPM service state).

Candidates panic under time pressure and jump to a 'fix' rather than a diagnosis. They also do not know the order of checks: CPM service status, network reachability, credential validity, platform command correctness, and the CPM log.

What to do instead

Follow a fixed diagnostic order: confirm the CPM service is running, verify PSM/CPM-to-target connectivity, verify the current credential works manually, check the platform's change command, and read the CPM log for the specific error. Only then act, and know how to safely reconcile if the password is out of sync.

Mistake 9

The candidate confuses account lifecycle states and actions: they cannot distinguish Verify, Change, Reconcile, and 'mark for change', and they do not know what happens when an account is in a 'failed' or 'unmanaged' state.

These actions sound similar and candidates memorize definitions without understanding when each applies. They also do not realize that an unmanaged account will not be rotated, and a failed account needs reconciliation or manual intervention.

What to do instead

Build a table of actions and states: what Verify checks, what Change does, when Reconcile is needed (password out of sync), and how 'unmanaged' vs 'managed' affects CPM behavior. Practice recovering an account from a failed state.

Mistake 10

The candidate cannot explain how a session is recorded and audited end to end, or they misconfigure session recording so sessions are not captured, then cannot answer questions about session isolation, recording, or playback.

Session management involves PSM connection components, recording settings, and storage, and candidates treat it as a black box. They also overlook that recording and isolation settings are platform-level and must match the target type.

What to do instead

Learn the session lifecycle: connection component, connector, recording settings, and where recordings are stored and played back. Verify recording is enabled for the platform and test a session to confirm it is captured before relying on it for audit.