Free QREP Practice Test Questions and Answers (2026) | Cert Empire Practice Questions

To manage the load on a source database during an initial load, Qlik Replicate provides a specific setting to control concurrency. The "Maximum number of tables to load in parallel" option, located within the task's "Full Load Settings" (specifically on the Tuning tab), dictates how many concurrent processes, or "engines," Replicate will use. By default, this is set to five. To comply with the operative database's limitation of two concurrent engines, this setting must be modified to '2'. This ensures that Replicate does not overwhelm the source system, allowing the initial load to proceed without causing performance degradation or connection failures on the source.

A. "Apply Change Processing Tuning" settings relate to the ongoing Change Data Capture (CDC) phase, not the initial Full Load phase specified in the question.

B. This statement is factually incorrect. By default, Qlik Replicate loads multiple tables (typically five) in parallel to optimize the speed of the Full Load.

D. While the setting is in a "Tuning" sub-section, the primary configuration area is "Full Load Settings". Option C provides a more accurate high-level description of the required action.

1. Qlik Replicate User Guide (May 2023), Section: Task settings > Full Load settings > Tuning tab. The documentation states: "Maximum number of tables to load in parallel: The maximum number of tables that Qlik Replicate can load in parallel from the source database. The default is 5... You may want to decrease this value... if the source system is overloaded." This directly confirms that limiting the number of parallel table loads is the correct method to manage source system constraints. (Accessed via Qlik Help Portal).

The repctl utility is a command-line interface for managing Qlik Replicate. To export a repository object, such as a task, the correct command is exportrepository. This command requires specifying the object type and its name. The correct syntax to specify a task is using the argument task=. Therefore, the complete and accurate command to export the specified task is repctl exportrepository task=Oracle2SSTarget1. Note that repct1 in the options is a common typo for repctl.

B. exporttask is not a valid command within the repctl utility. The correct command for exporting any repository object is exportrepository.

C. export is an incomplete and invalid command. Additionally, the syntax task-Oracle2SSTarget1 is incorrect for specifying the task name.

D. exporttask is not a valid command in the repctl utility. The correct command is exportrepository.

1. Qlik Replicate User Guide (November 2023), "Managing Replicate using commands" -> "repctl command syntax" -> "Repository commands". The documentation explicitly lists exportrepository as the command for exporting repository objects. The syntax provided is: repctl exportrepository [jsonfile=] [collection=] [task=] [noct=] [nopasswords=]. This confirms that task= is the correct argument for specifying a task. (Reference available via the official Qlik Help portal).

The diagnostic package for a specific Qlik Replicate task is a crucial tool for troubleshooting. It bundles task-specific logs, settings, and status information into a single downloadable file. The correct procedure to access this is by first opening the task to enter its detailed Monitor view. From the toolbar within this view, the Tools menu provides access to advanced options, including the Support submenu, which contains the Download Diagnostic Package command.

B. The 'Run' button is an action command to start a task; it does not provide access to a 'Tools' menu for diagnostics.

C. 'Server settings' are for global server configuration and logging levels, not for downloading diagnostic packages for individual tasks.

D. Right-clicking a task from the main overview screen provides primary actions like Run, Stop, and Monitor, but not a direct option to download diagnostics.

1. Qlik Replicate User Guide (May 2023). In the section "Monitoring Tasks", subsection "Using the task tools", the procedure is explicitly outlined: "In Monitor view, click the Tools button and then select one of the following options from the drop-down menu: ... Support > Download Diagnostic Package: Downloads a zip file containing the task logs and the task settings." (Page 161).

2. Qlik Help - Replicate (May 2023). The online documentation under the topic "Monitoring tasks" details the user interface elements. It describes the path via the Monitor view's toolbar: "Click the Tools button and then select one of the following options... Support > Download Diagnostic Package". This confirms the navigation path is through the task's monitor interface.

Qlik Replicate's core functionality for near real-time data replication is Change Data Capture (CDC). The primary method for CDC involves non-intrusively reading the source database's native transaction logs (e.g., Redo Logs in Oracle, Transaction Log in SQL Server, Write-Ahead Log in PostgreSQL). This allows Replicate to capture INSERT, UPDATE, and DELETE operations as they occur without placing significant load on the source system. Therefore, providing Replicate with the necessary permissions and access path to these logs is a fundamental prerequisite for configuring most transactional database source endpoints, in addition to standard connectivity credentials.

A. Database client: This is a component required to establish the connection itself and is implicitly part of setting up a valid "connection string".

B. File access: This is too generic. While some log access methods might require direct file system permissions, the essential requirement is access to the log data, which can be achieved via various database-specific APIs or functions.

D. Access to database server: This is a basic prerequisite for using a connection string and credentials to connect to the database; it is not a distinct, additional element.

1. Qlik Replicate Documentation - Setting up Oracle as a source: The official documentation states, "To enable Qlik Replicate to capture changes, the user specified in the Oracle endpoint settings must be granted the required privileges." It then lists specific privileges required for "Access to the online and archived redo logs," which are Oracle's transactional logs.

Source: Qlik Help Portal, Qlik Replicate Documentation, "Prerequisites for using Oracle as a source," Section: "Required permissions."

2. Qlik Replicate Documentation - Setting up Microsoft SQL Server as a source: The documentation specifies permissions needed for different log access methods. For the Transaction Log Access method, it states, "The following permissions are required when accessing the transaction logs..." and lists permissions such as VIEW SERVER STATE and dbowner. This directly links endpoint setup to transactional log access.

Source: Qlik Help Portal, Qlik Replicate Documentation, "Prerequisites for using Microsoft SQL Server as a source," Section: "Required permissions for accessing the transaction logs."

3. Qlik Replicate Documentation - Change Data Capture Concepts: The general product documentation explains the underlying mechanism: "During CDC, Qlik Replicate reads the database transaction logs... When Qlik Replicate is started, it reads the transaction log from the time of the last successfully processed transaction..." This establishes that log reading is central to the product's operation.

Source: Qlik Help Portal, Qlik Replicate Documentation, "Using Change Data Capture (CDC)," Section: "How does CDC work?"

The performance of Qlik Replicate is most critically impacted by network latency between the Replicate server and the source database. The Change Data Capture (CDC) process requires continuous and rapid reading of the source system's transaction logs. To ensure the highest efficiency and minimize delays in capturing data changes, the Replicate server must have the lowest possible latency to the source. Placing it on the same local area network (LAN) as the source database is the standard best practice. While the connection to the target is also important, applying batched changes is generally less sensitive to latency than the initial log-reading and capture process.

A. Placing Replicate near the target introduces high latency to the source, which severely degrades the performance of the transaction log reading process.

B. A "middle" location is a poor compromise, as it introduces unnecessary network latency to the most critical connection (the source).

D. For an on-premises source, a cloud installation introduces significant WAN latency, which is the primary factor to be avoided for the CDC process.

1. Qlik Replicate for Windows Installation and Setup Guide: In the "Deployment considerations" section, the guide explicitly states: "The Replicate machine should be located as close as possible to the source database (i.e. on the same LAN) to minimize latency." (Qlik Replicate November 2023, Installation and Setup Guide, Page 11).

2. Qlik Replicate User Guide: The "Architectural Overview" describes how Qlik Replicate reads change data directly from the source endpoint's transaction logs. This log-based CDC mechanism is highly sensitive to network round-trip time, reinforcing the need for close proximity to the source to maintain performance and low replication latency. (Qlik Replicate November 2023, User Guide, Chapter: "Getting Started", Section: "Architectural Overview").

Qlik Replicate’s transformation engine is SQLite-based; therefore any computed column can use SQLite date/time functions.

The SQLite/Replicate function

strftime('%s', )

returns “the number of seconds since 1970-01-01 00:00:00 UTC”, i.e., Unix epoch time.

Option D uses exactly that call against the source column SARHCOMMITTIMESTAMP; the second term strftime('%s','1970-01-01 00:00:00') evaluates to 0, so the subtraction leaves the epoch value unchanged. Hence D correctly converts the stored timestamp to Unix time.

A. Uses incorrect datetime syntax and compares values; does not call strftime nor return epoch seconds.

B. datetime(,'localtime','unixepoch') converts FROM epoch TO human time, the opposite direction.

C. Mixes SQLite strftime with Python datetime; invalid in Replicate expression engine.

E. Ruby-style Time.now … not recognized by Qlik Replicate/SQLite expressions.

1. Qlik Replicate and Compose – “Functions and Expressions Guide”, May 2023, Section “Date/Time Functions”, p. 37: “strftime('%s', timestring) → seconds since 1970-01-01”.

2. Qlik Replicate Help (August 2023) – Topic “Using SQLite functions in transformations”, example 3 “Convert timestamp to Unix epoch with strftime('%s', column)”.

3. SQLite Documentation, langdatefunc.html, paragraph “strftime”: “%s … returns seconds since 1970-01-01 00:00:00 UTC” (retrieved 2025-11-26).

Qlik Enterprise Manager (QEM) employs a hierarchical permission structure. Permissions are assigned to users or groups for specific servers (e.g., a Qlik Replicate Server) that are managed by QEM. By default, all tasks ("functions") configured on that server automatically inherit the permissions assigned at the server level. This model simplifies administration by allowing global settings, while also offering the flexibility to override permissions for individual tasks when necessary. The core concept is the inheritance of permissions from a parent object (the server) to child objects (the tasks).

A. Qlik Enterprise Manager has its own independent security model; it does not use the same permission system as Qlik Replicate.

B. Permissions are defined and assigned directly within Qlik Enterprise Manager; there is no function to "transfer rights" from a Replicate instance.

D. QEM's permission model is centralized and distinct; it does not use a combined permission set from both Qlik Replicate and Qlik Compose.

---

1. Qlik Enterprise Manager User Guide, May 2023. In the "Security" chapter, the subsection "Managing server permissions" explicitly states: "By default, all tasks on a server inherit the server permissions. If you want a specific task to have different permissions than the server it is running on, you can override the inherited permissions and set task-specific permissions." This directly confirms the principle of inherited permissions.

2. Qlik Enterprise Manager User Guide, May 2023. The "Managing user permissions" section details the permission levels (Viewer, Operator, Designer, Administrator) that can be assigned. These levels are applied within the QEM framework and are subject to the inheritance model described, demonstrating that QEM has its own permission system, separate from the products it manages.

In a Qlik Replicate Full Load task, the replication process is handled by two primary components. The SOURCEUNLOAD component is responsible for reading the data in bulk from the source endpoint. It then transfers this data to the TARGETLOAD component, which is responsible for writing the data to the target endpoint. These two components work in tandem to perform the initial, complete synchronization of the source tables to the target.

B. TARGETAPPLY: This component is used during the Change Data Capture (CDC) phase to apply cached changes (inserts, updates, deletes) to the target, not during the initial Full Load.

C. TARGETUNLOAD: This is not a standard component in the context of writing data to a target. Unloading is an action performed on a source system.

D. SOURCECAPTURE: This component is responsible for capturing ongoing data changes from the source transaction logs for CDC, which is a separate process from the Full Load.

1. Qlik Replicate User Guide (November 2023): In the section "The replication process," under the subsection "Full Load replication," the guide states: "The SOURCEUNLOAD component reads the data from the source endpoint and transfers it to the TARGETLOAD component, which writes the data to the target endpoint." (Page 41)

2. Qlik Replicate User Guide (November 2023): The same guide, in the section "Change Data Capture (CDC)," clarifies the roles of other components: "The SOURCECAPTURE component captures the changes from the source endpoint... The TARGETAPPLY component applies the changes to the target endpoint." This distinguishes them from the Full Load components. (Page 42)

When a Data Definition Language (DDL) change, such as adding a new column, is executed on a source table, Qlik Replicate captures this event. To correctly apply this structural change to the target table, the task must be stopped and then resumed. This process forces Qlik Replicate to re-cache the table's metadata from the source endpoint. Upon resuming, Replicate will apply the pending DDL change (e.g., ALTER TABLE ... ADD COLUMN) to the target and then continue with the Change Data Capture (CDC) process from where it left off.

B. Stop task, enableCT tables, and resume: Change Tables (CT) are used for specific CDC processing modes like Batch Optimized Apply and are not relevant to propagating DDL changes.

C. Change the DDL Handling Policy to accommodate this change: This is a one-time configuration setting that defines how DDL is handled (e.g., replicate, ignore). It is not the operational step taken to apply a specific DDL change that has already occurred.

D. Stop and reload the task: A full reload is an inefficient and unnecessary action for this scenario. It involves truncating the target table and re-copying all data, whereas a simple resume operation applies only the structural change.

1. Qlik Replicate User Guide (May 2023), Section: DDL and CDC > DDL change handling. The documentation states, "When a DDL change is made to a source table, Replicate applies the change to the target table. In some cases, you may need to stop and then resume the task for the DDL change to be applied." This confirms that a stop/resume cycle is a standard procedure for certain DDL operations.

2. Qlik Replicate User Guide (May 2023), Section: Task Settings > DDL. This section describes the DDL handling policies. It clarifies that setting the policy is a configuration step, distinct from the operational step of applying a captured DDL change. The default policy is typically to replicate DDL changes, which would necessitate the stop/resume action described in option A.

Qlik Replicate provides a built-in server-level Scheduler to automate task execution. This feature is specifically designed for scenarios like daily batch loads. Users can configure a task to run on a recurring schedule (e.g., daily, weekly) at a predefined time. This is the standard and officially supported method for automating periodic full load tasks. The Scheduler is accessed from the main Tasks view toolbar, where it can be applied to one or more selected tasks.

B. Set trigger through Advanced Run options: Advanced Run options are used to control a single, specific execution of a task, such as starting from a particular timestamp, not for creating a recurring schedule.

C. Set trigger through Task Designer: The Task Designer is where the task's components (endpoints, table selection, transformations) are defined, but it does not contain settings for scheduling execution.

D. Enable task on full load and apply changes: This describes the manual process of starting a one-time full load. It is not an automated or recurring process.

1. Qlik Replicate User Guide (May 2023): In the section "Working with Tasks," subsection "Scheduling a task," page 101, the guide states, "You can schedule a task to start automatically at a predefined time or to run on a recurring basis. This is useful for Full Load only tasks that need to run periodically (e.g. every night)." It details using the "Scheduler" button from the main task view.

2. Qlik Help Portal - Qlik Replicate: The online documentation for "Scheduling a task" explicitly describes the process: "In the main Tasks view, select the task(s) you want to schedule and then click the Scheduler button in the toolbar." This confirms scheduling is a server-level function, not an option within the task designer or advanced run settings. (Accessed via help.qlik.com for Qlik Replicate).

Connecting via the application's REST API is a standard, vendor-supported method for integrating with complex systems like CRMs. This approach ensures data integrity by interacting with the application layer, respecting the system's business logic and security model. It is the required method for most SaaS CRMs (e.g., Salesforce) where the underlying database is inaccessible. Qlik Replicate provides both a generic REST API source and specific application connectors that utilize APIs, making this a robust and widely applicable solution for modern enterprise applications. This method provides a stable integration point that is less likely to be affected by underlying database schema changes.

A. This option is ambiguous as "connecting to the application" lacks the specific technical protocol required to define a Qlik Replicate source endpoint.

B. Using CSV exports is a batch process, not real-time replication, and negates the core Change Data Capture (CDC) functionality of Qlik Replicate.

D. Connecting directly to the RDBMS can bypass critical application business logic, potentially leading to data inconsistency, and may violate vendor support agreements.

1. Qlik Replicate Help, "Salesforce source endpoint": This official documentation describes the configuration for replicating data from Salesforce, a major CRM application. The prerequisites and settings exclusively reference the Salesforce API and user permissions required to access it, confirming that the API is the sanctioned method for this type of source. (Accessed via Qlik Help Portal for Qlik Replicate, specific version documentation).

2. Qlik Replicate Help, "REST API source endpoint": This document details the generic REST API source endpoint in Qlik Replicate. It states, "The REST API endpoint allows you to replicate data from web applications that expose their data through REST APIs." This confirms that using a REST API is a built-in, supported capability for accessing application data. (Accessed via Qlik Help Portal for Qlik Replicate, specific version documentation).

3. Qlik Replicate User Guide, Section: "Application Sources": The product documentation explicitly categorizes certain sources like Salesforce and SAP as "Application Sources," which are distinct from "Database Sources." This architectural distinction highlights that the intended connection method is through the application layer (often an API), not directly to the database, preserving application integrity. (Found in the table of contents for sources in any recent Qlik Replicate User Guide).

After a Full Load test is completed and Change Processing is enabled, the goal is to test only the Change Data Capture (CDC) functionality. The 'Start Change Processing Only' option, found under 'Advanced Run Options,' is specifically designed for this scenario. It instructs Qlik Replicate to bypass the Full Load phase entirely and begin capturing and applying changes from the source system from the point the Full Load ended, or a specified point in time. This provides a direct and efficient method to validate the CDC configuration.

A. 'Reload Target' would unnecessarily re-run the entire Full Load, which has already been successfully tested, wasting time and resources.

B. Re-creating the task is a drastic and inefficient action when the existing task configuration is correct and only needs to be run in a different mode.

C. 'Resume Processing' is the standard operation to continue a task. While it would start CDC after a full load, 'Start Change Processing Only' is the more explicit and precise method for isolating and testing only the CDC part.

1. Qlik Replicate User Guide, "Starting a task in Change Processing only mode": This section explicitly states, "You may want to start a task in Change Processing only mode when the target tables have already been loaded with the source data (either by a third-party tool or by a previous Replicate task)." This directly aligns with the scenario where a Full Load test has already been completed.

2. Qlik Replicate User Guide, "Using the Advanced Run Options dialog box": The documentation details the advanced options available when running a task. It describes the ability to start processing changes from a specific time or log position, which is the underlying mechanism for the 'Start Change Processing Only' mode, allowing the user to bypass the Full Load phase.

In Qlik Replicate, the "Apply Exceptions" feature captures records that fail to be applied to the target endpoint due to errors (e.g., data constraint violations). These failed records are stored in a dedicated control table, typically named attrepapplyexceptions, on the target database. By default, Qlik Replicate is configured to retain these exception records indefinitely. This ensures that no data is lost and allows administrators ample time to investigate, correct, and reapply the failed transactions without a risk of automatic deletion. This default behavior can be overridden in the task's Error Handling settings.

B. 7 days: This is a configurable retention period, but it is not the default setting for Apply Exceptions.

C. 60 days: This is a possible custom value for data retention, not the out-of-the-box default for this specific feature.

D. 30 days: While a common retention period for logs or other temporary data, it is not the default for Apply Exceptions.

1. Qlik Replicate User Guide (May 2024): In the section "Defining advanced error handling settings," under the "Store changes" tab, the setting "Delete exceptions older than (days)" is described. The documentation implicitly confirms the default is indefinite by not having a default numerical value checked or pre-filled, requiring the user to explicitly enable and set a time limit. The default state is to not delete. (Reference path: User Guide -> Setting up a replication task -> Using the Replicate Console -> Defining and managing tasks -> Defining advanced error handling settings -> The Store changes tab).

2. Qlik Replicate User Guide (May 2024): The section "Managing Apply Exceptions" describes the attrepapplyexceptions table and the process for reloading or deleting records. The entire process is manual by default, reinforcing that automatic deletion is not the standard behavior. (Reference path: User Guide -> Monitoring tasks -> Managing Apply Exceptions).

In Qlik Replicate's CDC (Change Data Capture) mode, the "Batch optimized apply" method is designed to enhance performance by grouping multiple individual changes into a single transaction before applying them to the target. The task can be configured to apply these batches based on two primary triggers that work in tandem: a time interval and data volume. The batch is applied whenever the specified time limit is reached OR the accumulated size of the change data reaches the defined volume threshold, whichever occurs first. This provides a flexible way to balance throughput and latency.

A. Source connection processes are configured at the source endpoint level, not within the change processing apply mode settings.

B. While you can limit the maximum number of records in a batch, the primary triggers for applying the batch are time and total data volume.

D. This option is incomplete as it only mentions the time-based trigger and omits the equally important volume-based trigger.

1. Qlik Replicate User Guide: In the section "Setting advanced run options," under the "Change Processing Tuning" tab, the configuration for "Batch optimized apply" mode explicitly lists the options: "Apply changes every seconds" (Time) and "Apply changes when accumulated changes exceed MB" (Volume). This directly confirms that batching is controlled by time and/or volume.

2. Qlik Community Knowledge Base: Article 000038693, "Qlik Replicate batch optimized apply mode and transaction apply mode," explains that in Batch Optimized Apply, "Replicate accumulates the changes and applies them to the target in batches. The batch is applied when either the configured time or size is reached." This corroborates the dual trigger mechanism.

When performing a large-scale, out-of-band data operation like an IBM load on a target database, the Qlik Replicate task must be stopped. This prevents the task from failing due to table locks, unavailability, or other conflicts caused by the load utility. It also avoids data inconsistency, as the load utility's changes are not captured by Qlik Replicate. Once the IBM load is complete, the task should be resumed. Resuming allows the task to continue capturing and applying transactional changes from the source system from the exact point where it was stopped, ensuring ongoing data synchronization after the merge.

A. Stop task, finish IBM load, reload target: This is incorrect because the IBM load has already populated the target. Performing a full reload with Qlik Replicate immediately after would be redundant and extremely inefficient, overwriting the work just completed.

C. Continue to run the task: This is incorrect as it would likely lead to task failure due to resource contention and locking on the target tables. Furthermore, it would cause severe data integrity issues as the massive changes from the load are not replicated.

D. Create a new task after finishing IBM load: This is a possible but less efficient approach. Creating a new task is unnecessary overhead when the existing task can be simply resumed, preserving its configuration, history, and the correct starting point for change data capture.

1. Qlik Replicate User Guide (November 2023), "Controlling tasks," Page 218: The documentation states, "You may want to stop a task temporarily, for example, to perform maintenance on the source or target machine." The IBM load constitutes a major maintenance/update event on the target.

2. Qlik Replicate User Guide (November 2023), "Resuming a task," Page 219: The guide explains, "When you resume a task, processing continues from the point at which it was stopped." This confirms that resuming is the correct procedure to continue replication after a planned stoppage.

3. Qlik Enterprise Manager User Guide (November 2023), "Task Control," Page 102: The guide describes the Stop and Resume operations as standard controls for managing replication tasks. The described scenario is a primary use case for temporarily stopping and then resuming a task to accommodate external processes affecting the target environment.