Delinea Secret Server common mistakes
Delinea Secret Server · Understand the traps and how to avoid them.
Treating 'Secret Server Fundamentals and Vaulting' as a product-tour topic and memorizing UI menus instead of the secret lifecycle: template, secret, secret policy, heartbeat, and dependency relationships.
The UI is intuitive enough that candidates skim the conceptual layer, then freeze on scenario items that ask which object enforces rotation or which object inherits a policy.
What to do instead
Build a one-page object map: templates define fields, secrets hold values, secret policies govern behaviour, heartbeats test and rotate, dependencies track where a secret is used. For each object write what it inherits and what it overrides, then answer practice scenarios by naming the object that owns the behaviour.
Assuming a changed secret value is automatically propagated to dependent systems, or that disabling a heartbeat stops rotation.
Candidates conflate heartbeat (health check and rotation trigger) with dependency (change propagation and remote password change). They also assume rotation and propagation are one step.
What to do instead
Separate the two concepts explicitly: heartbeat answers 'does this credential still work and should it rotate', dependency answers 'who else must be updated'. Note that a dependency can be configured to receive password changes remotely, and that rotation without a working dependency leaves stale credentials on targets. Drill scenario questions until you can predict the failure when one piece is missing.
Answering permission questions by naming the highest role a user holds rather than tracing the effective permission from folder inheritance, group membership, and secret-level overrides.
Secret Server permissions are additive and inherited, so the intuitive 'most powerful role wins' shortcut produces the wrong answer on items designed around inherited folder rights or explicit secret-level grants.
What to do instead
For every permissions scenario, draw the chain: user, groups, folder tree, inherited versus broken inheritance, then any secret-level entry. Remember that permissions are additive and that the most permissive applicable grant generally governs access, while explicit deny-style restrictions come from other controls. Practice by writing the effective permission for a user before reading the answer choices.
Confusing folder-level access with secret-level access and forgetting that moving a secret between folders changes its inherited permissions.
Candidates think of folders as filing cabinets rather than as the primary permission boundary. They miss items where a secret moved to a new folder silently gains or loses access for a group.
What to do instead
State the rule to yourself: folders are the permission container; secrets inherit unless explicitly overridden. Then work through move scenarios: which grants travel with the secret and which are re-derived from the destination. Include the effect on users who had access only through the source folder.
Treating session management as only 'recording a session' and missing the surrounding controls: launchers, session policies, approval workflows, and the difference between proxied, recorded, and direct connections.
Session recording is the most visible feature, so candidates learn that and skip how access is actually brokered, what requires approval, and what happens when a launcher or protocol is unsupported.
What to do instead
Map the path a user takes: request access, approval if required, launch through the appropriate launcher or proxy, session recorded per policy, session terminated and logged. For each stage know which configuration object controls it and what the fallback is when a control is not configured.
Confusing check-out (exclusive, time-bound credential checkout) with a normal secret view or with remote session launch, and misjudging what happens when a checked-out secret's time expires.
All three actions look like 'getting the password', so candidates pick the answer that sounds most secure rather than the one matching the described workflow and its automatic expiry and force-check-in behaviour.
What to do instead
Write a comparison table: view (read value, logged), check-out (exclusive lock, auto check-in on expiry, requires check-in or force check-in), session launch (credential never shown to the user). Then answer items by matching the scenario's stated constraint, such as 'two admins must not use the credential simultaneously'.
Assuming distributed engine or site configuration is optional plumbing and answering connectivity questions without considering which engine actually performs the heartbeat or password change.
Candidates study the central application and treat engines as deployment detail, so they cannot explain why a heartbeat fails from one network segment but succeeds from another.
What to do instead
Learn the rule that the engine assigned to the secret's site performs the work. For any connectivity scenario, identify the secret's site, the engine serving it, and the network path from that engine to the target. That single habit resolves most troubleshooting items.
Ignoring the interaction between authentication backends (AD, LDAP, local, SSO) and user onboarding, including how group membership from a directory maps into Secret Server groups and permissions.
Candidates memorize the list of supported authentication types but not how users are synchronized, how directory groups become Secret Server groups, and what happens when a user is disabled upstream.
What to do instead
Trace one user end to end: directory account, synchronization into Secret Server, group membership, inherited folder permission, resulting access. Then vary one element (user disabled, group renamed, sync failing) and predict the effect. This converts a memorization topic into a reasoning topic.
Reading the audit log as a flat list of events and being unable to answer 'who accessed this secret and when' versus 'who changed its configuration'.
Reports and audit views contain many event types, and candidates do not distinguish access events (view, check-out, session) from administrative events (permission change, policy change, secret edit).
What to do instead
Categorize event types into access, administrative, and system categories before answering. For a given question, decide which category the asker needs, then select the report or audit view that surfaces it. Practice by writing the exact question a compliance auditor would ask and matching it to the report.
Answering reporting items from memory of report names instead of knowing what each report's data source and time window are, leading to wrong answers about retention and completeness.
Report names are similar and the exam tests whether you know which report answers a specific compliance question, plus the fact that reporting is bounded by retention settings and audit configuration.
What to do instead
For each major report, record three facts: what question it answers, which events or objects it draws from, and what limits its coverage (retention window, enabled auditing, scope). Then answer by matching the compliance question to those three facts rather than to the report title.