PEGACPLSA23V1 Practice Questions

The configured Content Security Policy (CSP) includes the directive img-src 'self' data: blob:. This directive instructs the browser to only load images from the application's own origin ('self'), as data: URIs, or as blob: URIs. The attempt to load an image from an external domain, https://malicious.com, violates this policy. A compliant browser enforces the CSP by blocking the request to the unauthorized domain. As a result, the image will fail to load, and the browser will typically log a security violation error in its developer console.

B: The browser blocks the network request entirely; it does not load the resource and then decide against displaying it.

C: A compliant browser's function is to enforce the CSP, not ignore it. Ignoring the policy would render it useless.

D: The image will not load because its source, https://malicious.com, is not on the whitelist defined by the img-src directive.

1. Pega Platform™ Documentation

"Content security policies": This document outlines that a CSP adds a layer of protection to mitigate attacks like cross-site scripting by specifying the domains that the browser should consider valid sources for resources. The browser is responsible for enforcing this policy.

2. Pega Platform™ Documentation

"Content security policy management": This section details the configuration of CSP directives

including img-src. It explains that these directives create a whitelist of allowed sources

and any resource from a non-whitelisted source will be blocked by the browser.

3. Pega Platform™ Documentation

"Security Checklist": The Pega security checklist emphasizes implementing a strict Content Security Policy as a critical measure to secure the application

confirming that policies are meant to be enforced to prevent loading of untrusted assets.

This solution represents the most robust and scalable architectural pattern for handling large-scale historical reporting in Pega. Storing all application-related data, including product master data and transactional sales data, within the standard PegaDATA schema is the correct approach. For complex, long-term trend analysis spanning five years, using Business Intelligence Exchange (BIX) to extract data to a dedicated data warehouse is the Pega-recommended best practice. This strategy offloads resource-intensive analytical queries from the live transactional database, preventing performance degradation of the core application while enabling powerful analysis with specialized BI tools.

A: Incorrectly suggests segmenting product data into the CustomerData schema. Product data is core application data and belongs in the PegaDATA schema alongside the related sales workflow data.

B: Proposing direct queries by BI tools on the live transactional database is a significant anti-pattern that would severely impact the application's performance, especially with five years of data.

D: Incorrectly centralizes all data in the CustomerData schema and recommends direct database querying by BI tools, which is both an incorrect data model and a poor performance strategy.

1. Pega Academy (Lead System Architect 8.7 Module): "BIX and data extraction". This module explicitly details the use of Business Intelligence Exchange (BIX) for extracting large volumes of data from the Pega database to a separate reporting database or data warehouse. It emphasizes this approach to avoid performance impacts on the transactional system when running complex

long-running reports. The scenario in the question is a classic use case for BIX.

2. Pega Documentation: "Business Intelligence Exchange (BIX)". The official documentation describes BIX as the tool for extracting transactional data from the Pega Platform database into formats suitable for use in external reporting

analytics

and data warehousing systems. It highlights that BIX is designed for high-performance extraction without impacting OLTP users.

3. Pega Documentation: "Understanding the Pega Platform schemas". This documentation clarifies the purpose of the different schemas. The PegaDATA schema is the primary schema for all case data

assignments

and application-specific data tables. The CustomerData schema is designated for customer-centric data

typically used by Pega Marketing and Customer Service applications

not for general application or product master data. Storing both product and sales data in PegaDATA is the standard practice.

This scenario describes a classic cascading or dependent data relationship. The best practice in Pega is to use separate, dedicated data pages for each distinct data entity. A list-structure data page should be created to populate the top-level Categories. A second, parameterized list-structure data page should be created for Sub-categories. This Sub-category data page accepts the selected Category ID as a parameter to filter and retrieve only the relevant sub-categories from the database. This approach is modular, reusable, and aligns with Pega's data virtualization principles for optimal performance and maintainability.

A: Using a single, complex data page for both entities violates the single responsibility principle, making it less reusable, harder to maintain, and less performant than two dedicated data pages.

B: This option is incomplete as it fails to specify a data page for loading the initial Category list, which is a critical first step and a Pega best practice.

D: This option only addresses retrieving data after a Sub-category is selected. It completely ignores the primary requirement of how to populate the Category and Sub-category selection lists.

1. Pega Documentation

"Configuring a cascading control": This document explicitly outlines the correct pattern. It states

"To configure a cascading control

you create two controls and source them with two separate data pages. The first data page retrieves a list of values for the first control. The second data page is parameterized to retrieve a filtered list of values for the second control based on the value of the first control." This directly supports option C.

Source: Pega Community / Pega Platform 8.8 Documentation

"Configuring a cascading control".

2. Pega Documentation

"Creating a data page": The documentation on creating data pages emphasizes their role in separating data retrieval logic from the UI. It details the use of parameters to make data pages context-aware

which is the core mechanism for the Sub-category data page.

Source: Pega Community / Pega Platform 8.8 Documentation

"Creating a data page"

Section: "Data page parameters".

3. Pega Academy

Lead System Architect (LSA) Courseware

"Data Modeling" Module: The LSA curriculum stresses the importance of creating a clean

logical

and reusable data model. The principle of creating distinct data pages for distinct business objects (like Category and Sub-category) is a fundamental concept for building scalable and maintainable applications.

Source: Pega Academy

Lead System Architect 8.8

"Data and Integration" Mission

"Data Pages" Module.

The scenario requires patient data to be centrally managed, consistently up-to-date, and accessible by multiple, independent case types (appointments, treatments). The System of Record (SOR) data access pattern is the correct Pega design for this requirement. This pattern, often implemented using data pages, ensures that all processes reference a single, authoritative source for patient data. By fetching data on-demand from the SOR, the application guarantees that the information displayed and used in any process is always the most current version, avoiding the data staleness and integrity issues associated with copying data.

A: Pre-loading data creates a copy that will not update if the original patient record changes, failing the requirement for the data to remain "current."

B: The snapshot pattern is explicitly designed to copy data at a specific point in time, which is the opposite of the requirement to have continuously current information.

C: Storing master data (Patient) within a transactional case (Consultation) is a poor architectural choice. Data propagation also copies data, leading to stale information in child cases.

1. Pega Academy

Lead System Architect (23) Mission

"Data and Integration" Module

"Data virtualization" Lesson. This lesson contrasts the two primary data virtualization patterns. It explicitly states that the "Reference" pattern (SOR pattern) should be used when data must be up-to-date

while the "Copy" pattern (Snapshot) is for data that is valid at a specific point in time. The hospital scenario clearly requires the former.

2. Pega Documentation

"Data Pages

" Section: "Data page definition." This documentation describes how data pages are the primary mechanism for implementing data access patterns. For an SOR pattern

a data page is configured to source data from the appropriate system (e.g.

a patient database table) and can be set with a refresh strategy to ensure the data remains current whenever accessed.

3. Pega Documentation

"Data access patterns

" Section: "System of Record (SOR) pattern." This section defines the SOR pattern as the practice of accessing data directly from the source where it is maintained. It highlights the key benefit as ensuring data is always current and accurate

which directly addresses the core requirement of the question.

Custom guardrail warnings are a feature in Pega Platform designed to extend the built-in application quality checks. Their primary purpose is to help development teams enforce project-specific or organization-specific coding standards that are not covered by the default guardrails (B). The implementation of a custom guardrail involves creating an activity with custom logic that checks for a specific issue. This allows the warning to be triggered based on precise, developer-defined conditions (A). These two aspects—enforcing custom standards via custom conditions—are the core functional characteristics of the feature.

C: While factually true that custom warnings supplement built-in ones, options A and B are more precise in describing the fundamental purpose and mechanism of the custom warnings themselves.

D: Guardrails are an automated tool to aid development. They cannot replace the comprehensive analysis and contextual judgment of a manual code review, which assesses business logic and design quality.

1. Pega Platform Documentation

"Creating custom guardrail warnings." This document states

"you can create your own warnings to enforce your organization's development best practices" (supports option B). It also details the implementation process: "You create a custom guardrail warning by creating an activity to identify the condition to be flagged..." which directly supports the concept of triggering on specific conditions (supports option A). The document also notes that custom warnings "supplement the standard guardrails

" confirming the factual basis of option C

but A and B are more central to the feature's definition.

2. Pega Academy

Low-Code App Builder Extended Mission

"Extending application quality with custom guardrails" Module. This courseware explains

"You can create custom guardrails to warn developers when a rule fails to meet your organization's standards." (supports option B). It further clarifies the implementation: "You create a custom guardrail warning by creating an activity to identify the condition to be flagged." (supports option A). The module explicitly contrasts this with standard guardrails

positioning them as a supplement.

3. Pega Platform Documentation

"Guardrail warnings." This document describes guardrails as an automated system for identifying compliance issues

stating

"Application quality improves when you eliminate guardrail warnings." It makes no claim that this automated process can or should replace manual code reviews (refutes option D).

Data Flows are specifically engineered for complex data integration and large-scale processing tasks. A key advantage is their ability to use multiple Data Sets as sources, allowing them to natively combine and transform data from disparate systems like an EHR and an admissions database. Furthermore, Data Flows are the designated Pega tool for high-volume batch and real-time stream processing, leveraging scalable architecture to efficiently analyze large datasets, such as an entire patient population. A Queue Processor, by contrast, is designed for processing discrete, individual tasks from a single queue and is not optimized for large-scale data aggregation from multiple sources.

C. Data Flow can prioritize tasks based on urgency.

This is incorrect. Task prioritization is a defining feature of Queue Processors, which are designed to process queued items based on factors like urgency, not Data Flows.

D. Data Flow can process data in real-time.

This is not a distinguishing advantage. While Data Flows excel at real-time stream processing, Queue Processors also execute tasks in a near-real-time manner as they are queued.

1. Pega Platform™ Documentation

"Data Flows": "A data flow enables you to combine

process

and move data from one or more sources to one or more destinations... Data flows are scalable and resilient." This supports the ability to handle multiple sources (A) and large volumes (B).

Source: Pega Community

Pega Platform 8.8 Documentation

"Decisioning and analytics > Data Flows".

2. Pega Platform™ Documentation

"Creating a data flow": The process explicitly involves adding and combining multiple data sources. "In the Data flow record

you can combine multiple data sources and then use a wide range of shapes to process the data that these sources provide." This directly validates option A.

Source: Pega Community

Pega Platform 8.8 Documentation

"Decisioning and analytics > Data Flows > Creating a data flow".

3. Pega Platform™ Documentation

"Queue Processor rules": "Use a Queue Processor rule for simple queue management or when you need to queue a recurring or delayed task." This highlights its purpose for discrete

task-based processing

contrasting with the large-scale data analysis function of a Data Flow.

Source: Pega Community

Pega Platform 8.8 Documentation

"Asynchronous processing > Queue Processor rules".

The Library in App Studio serves as a centralized repository for reusable assets, significantly accelerating application development. Its primary advantages are enabling developers to discover and add pre-built components (such as UI templates, data objects, and utilities) to their current application, thereby quickly enabling new features. Strategically, it promotes an enterprise-wide reuse strategy by making assets from all built-on applications available, ensuring consistency, reducing redundant work, and optimizing the overall development process across the Pega ecosystem.

A. Update the existing components to make it more specific to the current application. This is incorrect. The purpose of a library is to promote reuse of generic components, not to specialize them for a single application, which defeats the purpose of reusability.

B. Perform create, read, update, and delete operations on the library components. This is too generic and misleading. While you manage components, the core advantage is not the CRUD capability itself, but the ability to browse and add reusable assets to an application.

1. Pega Platform™ Documentation - "The Library tab in App Studio": This document states

"The Library tab in App Studio provides a central repository for all the reusable assets

or components

that are available in your application. By reusing components

you can speed up application development and ensure consistency... From the Library

you can add components to your application to enable new features..." This directly supports options C and D.

2. Pega Platform™ Documentation - "Creating reusable components": This guide explains that components intended for the Library should be built for reuse. It emphasizes

"When you create a component

you package a set of rules that you can then reuse in case types across your application." This reinforces the concept of reuse (Option D) and adding features (Option C)

while implicitly contradicting the idea of specializing a library component for one-off use (Option A).

3. Pega Academy - Lead System Architect (LSA) Mission - "Enterprise architecture" module: This courseware emphasizes the LSA's role in establishing an enterprise layer of reusable assets. The Library is presented as a key tool for developers to consume these assets

which aligns with optimizing application creation by reusing assets from the entire Pega ecosystem (Option D).

The most effective corrective actions an LSA can recommend to address performance degradation from high data volume are application-centric. Archiving and purging resolved cases (B) directly reduces the size of the active dataset in transactional tables, which significantly improves query performance and processing times. This is a standard Pega best practice. Concurrently, ensuring critical tables are properly indexed (D) is essential. As data volume grows, unindexed or poorly indexed queries become a primary bottleneck. An LSA uses tools like the Performance Analyzer (PAL) to identify slow queries and creates database indexes on properties to optimize data retrieval for reports, UI displays, and background processing.

A. Implement horizontal and vertical database partitioning strategies and replication to distribute the load effectively. This is a database infrastructure-level activity, typically managed by a Database Administrator (DBA), not a direct application-level change implemented by an LSA.

C. Schedule regular database defragmentation sessions in collaboration with the Database Administrator. While beneficial for database health, defragmentation is a routine maintenance task for a DBA and is less impactful for this specific problem than directly reducing and optimizing access to the data.

1. Archiving and Purging (Supports Option B): Pega Academy

Lead System Architect (Pega Infinity '23) course

"Data Management" module. This module details the process of using the case archival and purge wizard to move resolved case data from primary transactional tables to an archive

directly addressing performance issues caused by large data volumes.

2. Database Indexing (Supports Option D): Pega Community

"Creating a custom index." This document explains how LSAs can create single or composite indexes on properties directly from the property rule form in Dev Studio to improve the performance of database queries

especially for reports.

3. Performance Best Practices (Supports B & D): Pega Community

"Performance guidance for Pega Platform." This guide emphasizes that managing data growth through purging and archiving

and ensuring proper database indexing

are two fundamental strategies for maintaining application performance. It distinguishes these application-level tasks from underlying database administration.

4. LSA Responsibilities (General Support): Pega Academy

Lead System Architect (Pega Infinity '23) course

"Pega's Class Structure" module

"Property Optimization" lesson. This lesson describes the LSA's responsibility to optimize properties by creating indexes to improve report and query performance

reinforcing that this is a core LSA task.

The Center-out business architecture is a Pega-specific model designed to optimize business processes by focusing on customer outcomes. It starts with the core of the business—the customer Microjourney—and works outward to the channels of engagement and the enterprise systems of record. This approach avoids the common pitfalls of traditional top-down (channel-specific) and bottom-up (system-specific) designs. By centralizing business logic around the customer journey, it ensures consistency across all channels, accelerates the delivery of business value, and creates a more agile and sustainable architecture.

B: This describes a channel-centric, or "top-down," approach. The Center-out model is designed specifically to avoid duplicating logic in each channel by centralizing it.

D: This describes a system-of-record, or "bottom-up," approach where each system maintains its own data and logic. This creates silos, which the Center-out model aims to break down.

1. Pega Academy. (2023). Pega's Center-out business architecture [Module]. In Certified Pega Lead System Architect (CPLSA) 23 courseware. "The Center-out™ business architecture avoids the mistakes of the top-down and bottom-up approaches to deliver customer and business outcomes quickly and sustain the architecture into the future." This directly supports option A.

2. Pega Documentation. (2023). The Center-out business architecture. Pegasystems. Retrieved from Pega Community. The documentation states

"The Center-out approach focuses on the Microjourney objectives

identifies when engagement with a channel is needed to complete a step

and determines what data is necessary to complete a step or updates on the completion of a step." This directly supports option C.

3. Pega Documentation. (2023). The Center-out business architecture. Pegasystems. Retrieved from Pega Community. The document describes the "top-down" approach as leading to "inconsistent and siloed channel experiences

" which aligns with the flawed methodology described in option B. It also describes the "bottom-up" approach as creating "data silos

" which aligns with the flawed methodology in option D.

Dynamic Class Referencing (DCR) is a Pega Platform feature that enhances data model flexibility by deferring the specification of a page's class until runtime. Instead of hard-coding a concrete class at design time, a developer can configure a page property to resolve its class dynamically based on the value of another property, a data transform, or other conditional logic. This allows a single set of rules to operate on different types of data objects, which is essential for building reusable framework components that can be adapted to various implementation-specific data structures without modification.

B: This describes standard data modeling associations (e.g., page lists, embedded pages), not the specific mechanism of DCR, which is about runtime class resolution.

C: DCR determines the object's entire class structure at runtime, not just its attributes. Adjusting attributes on a page of a fixed class is a standard operation.

D: This describes static class referencing, the direct opposite of DCR. DCR is used precisely when the class is not predefined and needs to be changeable.

1. Pega Documentation

"Creating a flexible data model with Dynamic Class Referencing": This document states

"Dynamic Class Referencing (DCR) allows you to create a more flexible data model by dynamically determining the class of a page or page list at run time

instead of design time." This directly supports the core concept in option A.

2. Pega Documentation

"Data models": In the section on data modeling best practices

DCR is highlighted as a technique for reusability. It explains that the class of a page is determined at runtime

often based on a parameter or property value

which aligns with "based on user input or certain conditions."

3. Pega Documentation

"Configuring a dynamic class reference": This guide details the implementation steps

showing that the page's class is set to "refer to a property" or "refer to a data page

" confirming that the class is resolved dynamically based on runtime data

not a fixed design-time definition.