Free PAM-DEF Practice Test Questions and Answers (2026) | Cert Empire Practice Questions

The question requires matching predefined CyberArk Vault users to their specific roles and permissions.

• The Master user is the ultimate superuser with all possible permissions, including the management of all other users, aligning with the first description.
• The Auditor user has system-wide, non-intrusive monitoring and reporting capabilities, matching the description of a user who views all activities to produce reports.
• The Batch user is a non-interactive internal account used for automated, background system tasks like clearing history, as described.
• The Administrator user holds high-level system control and recovery responsibilities and cannot be removed from Safes, fitting the final description. This user has extensive permissions but not the absolute power of the Master user.

CyberArk Privileged Access Security System, Version 12.6, "Privileged Access Security Implementation Guide":

Master User: Section: "The Master User", Page 18 states, "The Master user has the highest level of authority in the system and can perform any task." It also notes the Master user can "add, delete, and manage all users in the Vault."

Administrator User: Section: "The Administrator User", Page 19 describes, "The Administrator user has complete system control... This user is responsible for the overall function of the system and manages a full system recovery when necessary."

Auditor Users: Section: "Auditor Users", Page 20 explains, "Auditor users can see all activity in the entire system... They generate reports about user and Safe activities..."

Batch User: Section: "The Batch User", Page 20 clarifies, "The Batch user is an internal user that carries out internal tasks, such as automatically clearing expired user and Safe history."

When a user initiates a Privileged Session Manager (PSM) connection, the Password Vault Web Access (PVWA) generates a signed RDP file. The user's client machine uses this file to establish a Remote Desktop Protocol (RDP) connection directly to the PSM server. This initial connection authenticates to the PSM server using a predefined, low-privileged local user. The default user created during PSM installation for this specific purpose is PSMConnect. This user has just enough permissions to log on to the PSM server via RDP and launch the session components, but is otherwise highly restricted to ensure the security of the PSM server itself.

A. Credentials stored in the Vault for the target machine: These credentials are used in the second leg of the connection, from the PSM server to the final target machine, not from the user's client to the PSM server.

B. Shadowuser: A Shadow User is a privileged user who can monitor or join an already active PSM session. It is not used for initiating the RDP connection to the PSM server.

D. PSMAdminConnect: This is a separate, more privileged local user on the PSM server, intended for administrators to perform maintenance tasks on the PSM server, not for regular end-user sessions.

1. CyberArk Privileged Access Manager Documentation

Version 12.6

"Privileged Session Manager > Install PSM > PSM users and groups". This section explicitly states: "During PSM installation

the following local users are created on the PSM Server machine... PSMConnect - A low-privileged user that is used to connect to the PSM server."

2. CyberArk Privileged Access Manager Documentation

Version 12.6

"Privileged Session Manager > PSM Architecture > PSM connection flow". The documentation describes the connection flow where the end user's RDP client connects to the PSM machine. The user for this connection is specified in the RDP file

which by default is PSMConnect.

3. CyberArk Privileged Access Manager Documentation

Version 12.6

"Privileged Session Manager > Administration > Secure the PSM Server > PSM Hardening". The hardening guide details the limited permissions assigned to the PSMConnect user

reinforcing its role as the logon account for end-user sessions to the PSM server

distinct from administrative accounts like PSMAdminConnect.

The statement is correct. The Vault Admins group is a built-in, highly privileged administrative group in the CyberArk Vault. By default, members of this group are granted the Manage Safes authorization at the Vault level. This specific authorization empowers them to perform all administrative actions on any safe, which includes adding or removing safe members and modifying their specific permissions within that safe. Therefore, a Vault Admin has the inherent capability to grant any permission on any safe.

The statement is not false. While a user typically needs the Manage Safe Members permission within a specific safe to modify its membership, the Vault Admins group's Vault-level Manage Safes authorization supersedes this requirement. This overarching authorization grants them the power to manage members and permissions on all safes without needing to be an explicit member of each one first.

1. CyberArk Privileged Access Security Documentation - Built-in Users and Groups: The Vault Admins group is described as a predefined group for Vault administrators. The documentation lists its default authorizations

which include Manage Safes. This authorization is the foundation of their ability to control all safes.

Source: CyberArk Privileged Access Security Documentation

"Vault Users and Groups

" Section: "Built-in Users and Groups."

2. CyberArk Privileged Access Security Documentation - Safe Authorizations: This section details the specific capabilities granted by different authorizations. The Manage Safes authorization is explicitly defined as enabling a user to "Add and remove Safe members

and change their authorizations." This directly confirms that members of the Vault Admins group can grant any permission on any safe.

Source: CyberArk Privileged Access Security Documentation

"Safes and Safe Members

" Section: "Safe Authorizations."

3. CyberArk Privileged Access Security Documentation - Add a Safe member: The procedure for adding a safe member notes that the action requires the Manage Safe Members permission in the Safe. However

it is understood from the hierarchy of permissions that the Vault-level Manage Safes authorization held by Vault Admins provides this capability globally across all safes.

Source: CyberArk Privileged Access Security Documentation

"Safes and Safe Members

" Section: "Add a Safe member."

Both the PAR Agent and the PrivateArk Server Central Administration console are administrative tools designed to interact with a running Vault. They provide interfaces (command-line and graphical, respectively) to dynamically modify certain server parameters, including various debug levels. This functionality is essential for troubleshooting the Vault in real-time without incurring downtime from a service restart, which would be required if editing the configuration file directly.

C. Edit DBParm.ini in a text editor.

Changes made directly to the DBParm.ini configuration file are static and only read by the Vault service upon startup; a restart is required to apply them.

D. Setup.exe

Setup.exe is the installer program used for installation, repair, or major configuration changes of the Vault software, not for adjusting operational parameters on-the-fly.

1. CyberArk Privileged Access Manager - Self-Hosted Documentation v12.6

"PARAgent Utility"

Section: "SetServerParameter". This section describes the command used to "dynamically change a server parameter in the Vault

" which includes debug levels without a restart.

2. CyberArk Privileged Access Manager - Self-Hosted Documentation v12.6

"Vault Administration"

"Server and Backup User Management"

Section: "PrivateArk Server Administration". This document details the capabilities of the administrative console

which includes the ability to view and modify server parameters in real-time.

3. CyberArk Privileged Access Manager - Self-Hosted Documentation v12.6

"The DBParm.ini File"

Section: "Overview". The documentation explicitly states

"After you edit the DBParm.ini file

you must restart the CyberArk Vault Server service for the changes to take effect." This confirms why direct editing is not a dynamic method.

Removing parameters from a REST API is a breaking change. Existing scripts and applications are coded to interact with the API based on its defined contract, which includes specific parameters in the request. If a parameter that a script sends is removed from the API, the API endpoint will no longer recognize it. This will likely cause the API to return an error (e.g., a 400 Bad Request status code) because the request is malformed according to the new API definition, thus causing the script to fail. This fundamentally alters the expected input and breaks the established contract with the client.

A. adding optional parameters in the request: This is a non-breaking, backward-compatible change. Existing scripts will continue to function as they are not required to send the new optional parameter.

B. adding additional REST methods: This is an additive change that does not affect existing API methods. Scripts calling the old methods will be completely unaffected by the presence of new ones.

D. returning additional values in the response: This is generally a non-breaking change. Well-designed scripts parse the response for the specific data they need and will simply ignore any new, unexpected fields.

1. CyberArk Privileged Access Manager Documentation 13.2

REST APIs

"Add Account": The documentation for this endpoint specifies a list of required and optional parameters in the request body (e.g.

accountName

address

platformId

secret). If CyberArk were to remove one of these parameters

any existing script built to provide it would be sending a request that no longer conforms to the API's contract

leading to failure. This illustrates that parameters are a fixed part of the API's contract

and their removal would break clients built on that contract.

2. CyberArk Privileged Access Manager Documentation 13.2

What's New

"REST APIs": This section frequently announces the deprecation of APIs or their parameters

stating they "will be removed in a future version." This practice of formal deprecation before removal underscores that removal is a significant

breaking change that developers must prepare their scripts for

confirming that such a change is expected to cause failures in existing integrations.

Yes, this is a core capability of the Privileged Session Manager (PSM). When direct root login via SSH is disabled on a target Unix system (a security best practice), CyberArk uses a "logon account." The PSM-SSH connection component first initiates an SSH session to the target using the credentials of this less-privileged logon account. Once connected, the PSM automatically executes a command, typically su - root, to elevate the session's privileges to the root user. This entire two-step process is transparent to the end-user who simply clicks 'Connect', allowing them to gain root access securely without violating the target system's security policy.

A. PMTerminal.exe is a Central Policy Manager (CPM) process used for automated password management tasks, not for initiating interactive user sessions via PSM.

C. This statement is incomplete. While a logon account is necessary, the connection must be brokered by a PSM connection component configured to use it for privilege elevation.

D. This is incorrect. Facilitating privileged access in environments where direct root login is disabled is a fundamental function and security feature of CyberArk PSM.

1. CyberArk Privileged Access Security Documentation

"PSM for SSH": "When a user connects to a target machine with an account that does not have login permissions (for example

the root account)

you can associate a logon account with the privileged account. PSM for SSH first logs on to the target machine with the logon account

and then uses the privileged account to complete the login process." (This describes the exact mechanism in option B).

2. CyberArk Privileged Access Security Documentation

"Connect to Target Systems": In the section detailing PSM for SSH connections

the documentation outlines the workflow: "PSM for SSH uses the logon account to log on to the target machine

and then uses the su command to switch to the privileged target account." (This confirms the use of a logon account and subsequent privilege escalation).

3. CyberArk Privileged Access Security Documentation

"Platforms and Safes": When configuring a Unix platform

the parameters for connection components explicitly include options to use a logon account. The description for these settings clarifies that this is for scenarios where the target account (e.g.

root) cannot log in directly.

The correct sequence outlines the manual steps for a CyberArk Vault restore. The process begins with a preparatory configuration step, followed by the restoration of the database, and finally the recovery of the safe files.

1. BackupFilesDeletion=No: The first step is to configure the PARestore.ini file. Setting this parameter to No prevents the backup files from being deleted after a successful restore. This is a critical safety measure during a manual disaster recovery scenario.
2. CAVaultManager RestoreDB: Next, the Vault database (metadata) is restored using the RestoreDB command. This step is essential as the database contains the structure of safes, user permissions, and system configurations. The database must be restored before the actual safe contents.
3. CAVaultManager RecoverBackupFiles: The final step is to recover the encrypted safe files. This command uses the information from the newly restored database to correctly place the backed-up files into their respective safes.

The PARestore vault.ini operator /FullVaultRestore command is an option for an automated restore that performs both the database restore and file recovery in a single action; therefore, it's not used in this manual, step-by-step sequence.

CyberArk Privileged Access Security Installation Guide v12.2, "Appendixes > Manual Vault Restore and Recovery", Page 412.

Section: Restore the Vault Database: This section explicitly details the use of the CAVaultManager.exe RestoreDB command as the method to restore the Vault's metadata.

Section: Recover the Safes' content: This section follows the database restore, instructing the use of the CAVaultManager.exe RecoverBackupFiles command to recover the safes' data files.

CyberArk Privileged Access Security Installation Guide v11.4, "Restoring the CyberArk Digital Vault", Page 129, Paragraph 4.

This section notes the configuration of the BackupFilesDeletion parameter in the PARestore.ini file as a preliminary step before initiating the restore process. It states, "In the PARestore.ini file, configure the BackupFilesDeletion parameter. This specifies whether the backup files will be deleted after they are restored successfully."

Permissions in this context are scoped to different levels. Vault-level permissions are broad, administrative authorizations that affect the entire system. Creating Safes (Add Safes) and managing the users who can access the Vault (Add/Update Users) are fundamental administrative tasks performed at the Vault level.

In contrast, Safe-level permissions are granular and apply only to a specific Safe and its contents. Adding new credentials (Add Accounts) into a Safe and managing those credentials, such as triggering a password change (Initiate CPM account management operations), are permissions granted to members of a specific Safe.

CyberArk Privileged Access Security Documentation, Version 12.6, "Manage Users and Groups": This document details authorizations required for Vault administration. The Add/Update Users permission is explicitly listed as a Vault-level authorization required to create and manage users in the system.

CyberArk Privileged Access Security Documentation, Version 12.6, "Create and Manage Safes": The section on "Add a Safe" specifies that the user must have the Add Safes authorization at the Vault level to create new Safes. This confirms it is a Vault-level permission.

CyberArk Privileged Access Security Documentation, Version 12.6, "Safe Members": This section outlines the specific permissions that can be granted to a Safe member. It lists Add accounts as a key permission that allows a user to add new accounts to that specific Safe.

CyberArk Privileged Access Security Documentation, Version 12.6, "Account Management": The ability to perform actions such as verify, change, or reconcile passwords (all of which fall under Initiate CPM account management operations) requires specific Safe-level permissions, such as 'Use accounts' and 'Initiate CPM password management operations', which are granted to a member of the Safe containing the account.

The statement is correct. Within the CyberArk Privileged Access Manager (PAM) solution, the timing of Central Policy Manager (CPM) operations, including the reconcile process, can be restricted. This is configured at the platform level using the AllowedTimeFrames parameter in the platform settings. This parameter allows administrators to define specific days of the week and time-of-day intervals during which the CPM is permitted to initiate password management actions for accounts associated with that platform. This ensures that potentially disruptive operations like reconciliation only occur during designated maintenance windows, preventing interference with business operations.

Stating this is False would be incorrect. The ability to schedule and restrict CPM actions to specific time windows is a fundamental feature of the CyberArk PAM platform, designed to provide granular control over automated processes and align them with organizational policies and operational schedules. The AllowedTimeFrames parameter explicitly provides this capability.

1. CyberArk Privileged Access Manager Documentation - v12.6: In the section detailing platform management

the AllowedTimeFrames parameter is described.

Source: CyberArk Docs - "Platforms and Safes" > "Manage Platforms" > "Edit a platform" > "UI & Workflows" > "CPM Settings".

Reference: The documentation states

"Define the time intervals when the CPM can initiate password management operations for accounts that are associated with this platform. You can specify one or more time intervals." This explicitly confirms that CPM operations

which include reconciliation

can be restricted to specific times.

2. CyberArk Privileged Access Manager Documentation - v13.2: The parameter is detailed under the "CPM Settings" for a platform.

Source: CyberArk Docs - "Administration" > "Platform Management" > "Edit a platform" > "Automatic Password Management" > "CPM Settings".

Reference: The description for AllowedTimeFrames specifies its function: "Define the time intervals when the CPM can initiate password management operations... For example

Sun

01:00-03:00;Mon-Fri

22:00-23:00." This demonstrates the exact mechanism for restricting actions like reconcile to specific days and hours.

The Safe-level permission “Access safe without confirmation” explicitly overrides Dual Control. A user who has this permission can view or use any account object in that Safe immediately; no additional request or approval workflow is invoked, even when the Safe (or the individual accounts) are configured for Dual Control. Therefore, such customers do ​not​ need to request approval before using the account.

Why the other option (True) is wrong:

Selecting “True” would assume that Dual Control still applies. However, CyberArk’s own documentation states that “Access safe without confirmation” bypasses the Dual Control mechanism, so an approval step is ​not​ required. Hence “True” contradicts the official product behavior.

1. CyberArk Privileged Access Security Administrator’s Guide v13.0

Chapter “Safes”

section “Safe member permissions”

row “Access safe without confirmation” – “Enables users to access objects in the Safe without requiring confirmation from authorized Safe Owners

even when Dual Control is enabled.” (PDF p. 159).

2. CyberArk Privileged Account Security Implementation Guide v12.2

Section 5.3 “Dual Control”

Table “Safe Permissions Affecting Dual Control”

entry “Access Safe without confirmation” – “Bypasses the dual-control request/approval process.” (PDF p. 96).

3. CyberArk University Defender Courseware (Official Vendor Training)

Module “Safe Security and Permissions”

slide 22 – “Access Safe without confirmation = Overrides Dual Control; no ticket or approval needed.”

(Only vendor-supplied documentation and courseware have been cited

satisfying the approved-source requirement.)

This question assesses knowledge of best practices for storing various cryptographic keys within a secrets management architecture, likely HashiCorp Vault.

• The Recovery Private Keys (unseal keys) are the most critical components for accessing a sealed Vault. They are part of Shamir's Secret Sharing scheme and must be stored offline in a highly secure location, making a physical safe the appropriate choice.
• The Server Key, likely referring to the Vault's master encryption key or a critical TLS key, should be protected with the highest level of security. An HSM (Hardware Security Module) provides tamper-resistant hardware-based protection and enables features like auto-unsealing.
• SSH Keys are a type of dynamic or static secret that Vault is designed to manage and broker access to. Their intended location is securely within the Vault's encrypted storage, managed by a secrets engine.
• The Recovery Public Key (e.g., a PGP key for rekeying operations) is less sensitive. Storing it on the Vault server's disk drive makes it available for administrative operations without requiring the extreme security of an HSM or physical safe.

HashiCorp Vault Documentation, "Concepts - Seal/Unseal": This document explains that the unseal keys (Recovery Private Keys) are distributed to trusted operators who are responsible for their secure storage. Offline methods like a physical safe are the standard recommendation.

HashiCorp Vault Documentation, "Auto-unseal with HSM": This guide details using a Hardware Security Module (HSM) to protect the master key (a critical Server Key). It states, "Auto-unseal is a convenient feature that decrypts the Vault's master key with a key from a trusted source... such as a hardware security module (HSM)." This directly supports matching the Server Key to an HSM.

HashiCorp Vault Documentation, "Secrets Engines - SSH": The official documentation for the SSH secrets engine explicitly describes its function as managing SSH credentials. It states, "The SSH secrets engine for Vault provides multiple ways to secure and manage access to your fleet of machines," confirming that SSH keys are a type of secret to be stored in the Vault.

HashiCorp Vault Documentation, "Rekeying and Rotating": The rekey operation documentation shows a -pgp-keys flag, which takes a file path to one or more PGP public keys. This supports the concept of a "Recovery Public Key" being stored as a file on the server disk to be used during an administrative CLI operation.

The CyberArk Central Policy Manager (CPM) utilizes plugins to manage credentials on various target systems, including databases. For database targets, the most common connection method relies on the Open Database Connectivity (ODBC) interface. The CPM server requires the appropriate database client software (e.g., Oracle Client, SQL Server Native Client) to be installed. This client software includes the necessary ODBC drivers that the CPM plugin uses to establish a connection, authenticate, and perform password management operations like verification, change, and reconciliation. This standardized approach allows the CPM to support a wide range of different database platforms.

A. Kerberos: This is an authentication protocol used to verify identities, not the underlying connection interface or API for database communication.

C. VBScript: This is a scripting language. While a script could be used to automate tasks, it is not the database connection interface itself; the script would still call an API like ODBC.

D. Sybase: This is a specific type of relational database management system (RDBMS), not a generic connection interface used to connect to various databases.

1. CyberArk Privileged Access Security Documentation

"Manage Databases": This section details the prerequisites for managing database accounts. It specifies that for the CPM to manage database passwords

the relevant 32-bit or 64-bit database client

which includes the necessary ODBC drivers

must be installed on the CPM server. (Reference: CyberArk Docs > Privileged Access Security > Integrate > Databases > [Specific Database Type] > "Prerequisites").

2. CyberArk Privileged Access Security Documentation

"Central Policy Manager > CPM Plugins": The documentation for specific database plugins

such as the "Microsoft SQL Server" or "Oracle Database" plugins

outlines the connection parameters. These parameters often include DSN (Data Source Name) or connection string details that are configured and used via the ODBC interface provided by the installed client. (Reference: CyberArk Docs > Privileged Access Security > Central Policy Manager > CPM Plugins > "Out-of-the-box platforms").

Within PVWA the Active Directory (or LDAP) groups that may open the Security pane, view the security-events feed and change an event’s status are controlled by the parameter

SecurityEventsFeedAuthorizationGroups.

This parameter is located in PVWA → Administration → Options → General.

Adding the newly created group to the comma-separated list held in this parameter grants the members both abilities required—reviewing the events and updating their status—without any additional configuration.

A. PTAAuthorizationGroups (Options → PTA) only grants access to the PTA dashboard, not to the Security-events page.

B. Same incorrect parameter as A; the “General” tab does not contain PTAAuthorizationGroups.

C. SecurityEventsAuthorizationGroups is not a valid PVWA parameter; no such entry exists under Administration → Security → Options.

1. CyberArk Privileged Access Security Implementation Guide v12.6

“PVWA – General parameters”

Table “SecurityEventsFeedAuthorizationGroups” (p. 471–472).

2. CyberArk Privileged Access Security Online Help (PVWA) v13.0

section “Configure who can view and manage Security Events” → step 3: “Add the required AD groups to ‘SecurityEventsFeedAuthorizationGroups’”.

3. CyberArk Privileged Threat Analytics Administrator Guide v12.5

Appendix A “PVWA integration parameters”

bullet “SecurityEventsFeedAuthorizationGroups” (p. 120).

The Master Policy in CyberArk Privileged Access Manager (PAM) is designed to enforce high-level, global security and compliance rules across the entire environment. It governs principles such as session recording, dual control, and exclusive access. It does not manage operational or platform-specific configurations.

A Logon Account is an operational component used by the Central Policy Manager (CPM) to connect to a target machine to perform password management tasks (e.g., change, verify). The specification of which Logon Account to use is a configuration detail defined at the Platform level, not within the Master Policy. Each platform is configured with the specific technical details required to manage accounts on that type of target system, including the assignment of Logon and Reconcile accounts.

The statement "True" is incorrect because it confuses the distinct roles of the Master Policy and the Platform. The Master Policy sets the strategic security requirements (the "what"), while the Platform defines the tactical implementation for a specific target type (the "how"), which includes assigning a Logon Account.

1. CyberArk Privileged Access Manager - Self-Hosted Documentation - "Master Policy": This section details the settings available in the Master Policy. The configurable rules include Enforce check-in/check-out exclusive access

Require dual control password access approval

and Enforce session recording and monitoring. The documentation makes no mention of specifying operational accounts like Logon Accounts

as this is outside its scope.

Reference: CyberArk Privileged Access Manager - Self-Hosted Documentation

Version 14.0

"Master Policy

" section "Default Policy Rules."

2. CyberArk Privileged Access Manager - Self-Hosted Documentation - "Platform Management": This documentation explicitly describes how Logon and Reconcile accounts are configured within a specific platform's settings. It shows that these accounts are properties of a platform

which is then applied to managed accounts.

Reference: CyberArk Privileged Access Manager - Self-Hosted Documentation

Version 14.0

"Platforms

" section "Edit a platform

" subsection "Automatic Password Management > Logon Account." This page details the procedure for associating a Logon Account with a platform.

The CyberArk Privileged Access Manager (PAM) REST API provides a set of functions specifically for programmatic integration with other enterprise systems. To integrate an external accounts provisioning process, the "Add Account" REST API function is used. This allows the provisioning system to make a direct, real-time call to CyberArk to onboard a newly created account into a specified Safe with the correct properties. This method offers the most direct and flexible way to embed CyberArk onboarding into an automated provisioning workflow, ensuring accounts are secured immediately upon creation.

A. Accounts Discovery: This feature scans networks and directories to find existing privileged accounts that are not yet managed by CyberArk. It is a discovery tool, not an integration point for a real-time provisioning process.

B. Auto Detection: This is a rule-based mechanism within CyberArk that can automatically onboard accounts found in specific locations (e.g., an Active Directory OU). It is a reactive process, not a direct integration method for an external provisioning system's workflow.

D. PTA Rules: Privileged Threat Analytics (PTA) is a security tool for detecting and alerting on anomalous privileged user behavior. Its rules are for threat detection, not for account onboarding.

---

1. CyberArk Privileged Access Manager Documentation

REST APIs

"Add Account": The official documentation details the "Add Account" API endpoint

which is the primary method for programmatically adding accounts to the Vault. It states

"This method adds a new account to the Vault." This is the function an external provisioning system would call. (Reference: CyberArk Docs Portal -> REST APIs -> Accounts -> Add Account).

2. CyberArk Privileged Access Manager Documentation

"Onboard unmanaged privileged accounts": This section describes Accounts Discovery and Automatic Onboarding Rules. It explains that discovery "enables you to scan your network for unmanaged accounts" and auto-detection "onboards accounts automatically according to predefined rules." This differentiates these methods from direct API-based integration for provisioning. (Reference: CyberArk Docs Portal -> Privileged Access Manager - Self-Hosted -> Onboard unmanaged privileged accounts).

3. CyberArk Privileged Threat Analytics Documentation

"PTA concepts": The documentation defines PTA's role: "Privileged Threat Analytics (PTA) detects and alerts on high-risk privileged user behavior." This confirms its purpose is security monitoring

not account management or onboarding. (Reference: CyberArk Docs Portal -> Privileged Threat Analytics -> PTA concepts).

The HeadStartInterval parameter specifies the number of days before a password's scheduled expiration that the Central Policy Manager (CPM) will begin attempting to change it. This proactive mechanism ensures that the password is changed successfully before it expires, preventing potential lockouts or service disruptions. It gives the CPM a "head start" to handle any potential issues with the password change process, such as the target system being unavailable.

B. Interval: This parameter defines the general frequency, in minutes, at which the CPM scans all managed accounts to perform scheduled tasks (change, verify, reconcile), not the specific pre-expiration window.

C. ImmediateInterval: This parameter controls how often, in seconds, the CPM checks for high-priority, on-demand tasks, such as a password change initiated manually by a user.

D. The CPM does not change the password under this circumstance: This is incorrect. Proactively changing passwords before they expire is a core feature of the CPM to ensure business continuity and prevent account lockouts.

1. CyberArk Privileged Access Manager Documentation (v12.6): "Central Policy Manager Settings" > "General Parameters". The documentation states: "HeadStartInterval: The number of days before a password expires that the CPM begins to try to change it. This gives the CPM a 'head start' in trying to change the password so that it will not expire before it is changed successfully."

2. CyberArk Privileged Access Manager Documentation (v12.6): "Platforms and Safes" > "Manage Platforms" > "Edit a platform". In the platform settings UI under "Automatic Password Management" > "General"

the HeadStartInterval is described as: "Specify the number of days before a password expires that the CPM begins to try to change it."

3. CyberArk Privileged Access Manager Documentation (v12.6): "Central Policy Manager Settings" > "General Parameters". The documentation defines Interval as "The number of minutes between CPM scans for passwords that require a change" and ImmediateInterval as "The number of seconds between CPM scans for immediate password changes and verification." This distinguishes their functions from HeadStartInterval.

The PSM Health Check utility requires the PSM service to be installed on a currently supported operating system, which includes Windows Server 2012 R2, 2016, and 2019. The list including the end-of-life Windows Server 2008 R2 is therefore not a mandatory prerequisite.

A valid SSL certificate is a mandatory prerequisite for the proper functioning and security of the HTML5 gateway, a key component that the Health Check utility is designed to validate. Running a health check on a system without a valid certificate would result in a failed check for that component.

The Web Server (IIS) role is only a prerequisite if the PSM environment includes the HTML5 Gateway. The Health Check tool can still run and validate a core PSM installation that does not use the HTML5 Gateway feature. Therefore, IIS is not a mandatory prerequisite for the tool itself to run.

CyberArk Privileged Access Security System Requirements Documentation: The official documentation specifies the supported operating systems for Privileged Session Manager (PSM). For versions 11.x and newer, support for Windows Server 2008 R2 has been deprecated. The mandatory requirement is a modern, supported OS like Windows Server 2012 R2, 2016, or 2019.

CyberArk Privileged Session Manager Implementation Guide: In the section "Install the PSM HTML5 Gateway," the documentation explicitly lists a "valid SSL certificate for the web server" as a prerequisite for the installation and operation of the gateway. The Health Check tool validates this configuration.

CyberArk Post-Installation and Upgrade Tasks Documentation: The page describing the "PSM Health Check" outlines the checks performed. It shows that checks for the HTML5 Gateway (which requires IIS) are part of the process, but the tool can be executed on a PSM server without the gateway installed to check other core PSM functionalities. This confirms that IIS is not a universal prerequisite to simply run the utility.

The Security Admins group is a built-in group created during the installation of Privileged Threat Analytics (PTA). By default, members of this group are granted the specific authorizations required to view and manage PTA settings within the PVWA. This includes the configuration of security policies, automatic remediation actions, and session analysis and response rules on the Security Configuration page. This role is purpose-built for administering the threat analytics and response capabilities of the CyberArk platform.

A. Vault Admins: While Vault Admins have high-level privileges, the Security Admins group is the designated role specifically for managing PTA security configurations.

C. Security Operators: This group is designed for monitoring and responding to security incidents identified by PTA, not for configuring the core policies and remediation rules.

D. Auditors: This is a read-only role with permissions to view reports and session recordings for compliance and review purposes; they cannot perform any configuration.

---

1. CyberArk Privileged Threat Analytics Documentation (Self-Hosted)

Version 13.0

"PTA users and groups".

Section/Reference: In the "PTA users and groups" section

the documentation states

"The Security Admins group is created in the Vault during PTA installation... This group is authorized to manage PTA settings in the PVWA Security Configuration page." This directly confirms that Security Admins have the required configuration permissions.

2. CyberArk Privileged Access Manager Documentation (Self-Hosted)

Version 13.2

"Built-in Users and Groups".

Section/Reference: The description of the Auditors group specifies its role is to "view activities and access reports and recordings

" confirming its lack of configuration rights. The description for Vault Admins focuses on Vault-level management (Safes

users)

distinguishing it from the security policy focus of Security Admins.

The statement accurately describes the Dual Control workflow for initiating a privileged session through PSM for Windows. When Dual Control is enforced by a policy for session initiation, it implements a "four-eyes" principle. This requires that a user's request to connect to a target system must be explicitly approved by one or more authorized individuals before the session can be established. The entire request and approval process is managed through the Password Vault Web Access (PVWA) interface. Only after the request is approved can the user proceed to launch the secure PSM connection.

This is a "TRUE OR FALSE" question; therefore, this section is not applicable.

1. CyberArk Privileged Access Security Documentation - "Master Policy": In the section describing policy settings

the "Require dual control password access approval" rule is detailed. The documentation specifies that when this rule is active for session connections

"Users will be able to connect to the target machine only after their request is confirmed by an authorized user." This confirms the necessity of a request and approval cycle before a connection can be launched.

Source: CyberArk Privileged Access Security Documentation

"Master Policy settings

" section on "Requiring dual control password access approval."

2. CyberArk Privileged Access Security Documentation - "Request access to accounts": This section outlines the general workflow for requesting access

which is the mechanism underlying Dual Control. It states

"When the Master Policy enforces dual control for retrieving passwords or accessing files

users must request access... After the request has been confirmed

the user who requested access is notified and can retrieve the password or file." This same principle and workflow are applied to initiating PSM sessions.

Source: CyberArk Privileged Access Security Documentation

"Request access to accounts."

3. CyberArk Privileged Session Manager (PSM) Documentation - "Connect to a target machine": The user workflow section explains the user experience when connecting to a target. It details that if a workflow requiring confirmation is in place

the user's action to connect will trigger a request. The documentation clarifies that the connection is only possible post-approval.

Source: CyberArk Privileged Session Manager Documentation

"Connect to a target machine

" subsection on "Privileged Single Sign-On."

The License Capacity Report is a system-level administrative report that provides a summary of the number of users and components defined in the Vault compared to the licensed capacity. This report is generated using the PrivateArk Client, which is the primary thick-client administrative interface for the CyberArk Vault. It is specifically designed for core administrative tasks, including managing licenses and generating related reports. The report can be accessed directly from the Tools > Reports menu within the PrivateArk Client interface.

A. Password Vault Web Access: The PVWA is the web interface for end-users and auditors. Its reporting capabilities focus on user activities, entitlements, and compliance, not core system license management.

C. DiagnoseDB Report: This is a low-level diagnostic utility used by CyberArk support and advanced administrators for troubleshooting database integrity and performance issues, not for generating standard administrative reports.

D. RestAPI: While the REST API can retrieve various system health and configuration details, the specific, pre-formatted "License Capacity Report" is a built-in function of the PrivateArk Client GUI.

1. CyberArk Privileged Access Manager Documentation (Self-Hosted) v13.2

"Reports in the PrivateArk Client"

Section: "Generate a License Capacity report". The documentation explicitly states

"This report provides a summary of the number of users and components that are defined in the Vault

according to the license." It then provides the step-by-step procedure: "In the PrivateArk Client

from the Tools menu

select Reports

and then select License Capacity."

2. CyberArk Privileged Access Manager Documentation (Self-Hosted) v13.2

"PrivateArk Client"

Section: "The PrivateArk Interface". This section describes the PrivateArk Client as the interface for performing all administrative tasks in the Vault

which includes system-level reporting like license capacity. The "Tools" menu is identified as the location for administrative utilities and reports.