PEGACPSA24V1 Certified Pega System Architect 24 Practice Questions

The 'Change Stage' automation shape is specifically designed to move a case to a different stage in the lifecycle, either forwards or backwards. By adding this step to the flow and linking it to the 'Send Back' outcome of the manager's approval step, the case will cleanly transition back to the 'Data Entry' stage as required.

When creating a data type in Pega, you can specify its data source. By selecting an external source (like a REST connector, database table, etc.) and unchecking the option for local data storage, you create a data object that acts as a bridge to the external system. This allows Pega to fetch and use the data in real-time without creating a separate, redundant copy in the Pega database.

The 'Refresh - Other Section' action is designed specifically for this use case. It allows an action initiated in one section (the primary section) to trigger a refresh of a different, specified section (the embedded section). This provides a dynamic user experience by updating only the necessary parts of the UI, which is more efficient than reloading the entire harness or screen.

pyDefault is a standard data transform that Pega automatically runs when an instance of a class (like a new case) is created. Its primary purpose is to set default or initial values for properties on the new clipboard page, ensuring the object starts in a predictable state.

This correctly describes the hierarchy. A rule is the smallest unit of logic (e.g., a data transform, a section). Rules are collected into rulesets, which are containers that can be versioned (e.g., MyRuleset:01-01-01). The application rule defines the application by assembling a list of rulesets, creating the 'ruleset stack' that determines which rules are available to the user at runtime and in what order they are resolved.

The Split Join shape is the ideal Pega construct for executing multiple independent flows in parallel and waiting for all to complete. By placing a condition on the flow leading to the risk team approval, it will only execute when the loan amount is USD 50,000 or more, satisfying the requirement for parallel approval efficiently within a single stage. A sequential process is inefficient. A child case adds unnecessary complexity for a task that is part of the same lifecycle.

The Requestor scope creates a single instance of the data page for the user's session, which is shared across all threads (cases, browser tabs). This perfectly matches the requirement to load the data once per session and ensures consistency while minimizing redundant API calls. Thread scope would create a new instance for each case. Node scope would share the data across all users on that server node, which is not what the requirement specifies.

In Constellation, the Table view is the standard and most appropriate component for displaying a list of records with multiple columns, such as attachment name, icon, and date. It provides built-in features for sorting, filtering, and pagination. A Field Group is for organizing related fields of a single record. A Summary Panel is for displaying key-value pairs. A List view is a simpler component, but the Table is better suited for structured, multi-column data.

This scenario is the classic use case for a framework/implementation pattern. The core, reusable claims logic should be in a Framework layer application. Each subsidiary (Auto, Home) should have its own Implementation layer application that is built on the framework. This allows them to inherit all the core functionality while having the flexibility to override rules for their specific needs, such as UI branding and validation, promoting reuse and maintainability.

This is false. SLAs can be configured at multiple levels in a case lifecycle. While they are commonly applied to individual assignments (tasks), they can also be set for an entire case type (overall case deadline) and for individual stages (stage-level deadline), providing granular control over timeliness.