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.)