Pegasystems PEGACPSA88V1 Practice Test Questions, Exam Dumps

Practice Exams:

View All

PEGACPSA88V1 Pegasystems Practice Test Questions and Exam Dumps

Question 1

You realize that your project has expanded beyond the initial expectations, which may cause delays in delivering the Minimum Lovable Product (MLP).

Who is the most appropriate team member to consult in order to review the project plan and address concerns about the release timeline?

A. Project delivery leader
B. Lead business architect
C. Citizen developer
D. Deployment architect

Answer:A

Explanation:

When a project's scope begins to exceed its original boundaries, and there is a risk that the Minimum Lovable Product (MLP) will not be delivered on schedule, it becomes critical to reassess timelines, deliverables, and stakeholder expectations. The person best positioned to guide this process and ensure alignment across planning, execution, and communication is the project delivery leader.

The project delivery leader holds primary accountability for ensuring that the project stays on track and that deliverables are met according to the agreed-upon timelines and scope. This role is responsible for coordinating across various teams—including business architects, developers, and deployment specialists—to ensure that the project progresses efficiently. When scope creep is identified, it is their responsibility to evaluate the impact, update the delivery roadmap, and manage stakeholder expectations accordingly.

Here’s why the other options are not the most appropriate in this situation:

B. Lead business architect: While this role contributes significantly to defining business requirements and ensuring they align with organizational goals, they are not typically responsible for project timelines or release schedules. They may be involved in clarifying whether a new feature aligns with business needs, but they wouldn't own the project delivery timeline.
C. Citizen developer: This role involves non-traditional developers—typically business users—who create applications using low-code/no-code tools. While they contribute to development efforts, they do not have overarching responsibility for managing scope, timelines, or coordinating release schedules. They would be impacted by timeline changes but are not the right contact for managing them.
D. Deployment architect: This team member focuses on ensuring that technical environments are set up correctly for deployment. They are concerned with aspects like infrastructure, system configurations, and release mechanisms but do not manage project planning or scope. Their role becomes more prominent toward the end of the development cycle during release planning and execution.

In contrast, the project delivery leader ensures that the work remains aligned with the schedule and budget, handles communications with stakeholders, and takes charge when realignment is needed due to changes in scope. This role serves as the hub of coordination for planning and execution and is best equipped to evaluate and adjust project plans when issues arise.

In summary, when facing delays or scope changes that threaten delivery of the MLP, the most appropriate person to engage is the project delivery leader, who has both the authority and the responsibility to reassess the situation, adjust the timeline, and reset expectations with stakeholders.

Question 2

While performing testing, you discover that the “Send case status email” step is failing to send an email. What type of work item should you create in Agile Workbench to report this problem?

A. Bug
B. Scenario test
C. Feedback
D. User story

Answer: A

Explanation:

In Agile Workbench, various types of work items are used to track and manage different aspects of a project. When a functionality that is supposed to be working does not behave as expected during testing, the correct way to document and communicate this is through a bug work item.

A bug in Agile Workbench refers specifically to a defect in the system—a situation where something is broken, not working as intended, or producing incorrect results. In this case, the issue is that the "Send case status email" step does not send an email during testing. Since this is a deviation from the expected behavior of a system component that should already be functioning, it is clearly a defect and should be logged as a bug.

Here’s why the other options do not fit this scenario:

B. Scenario test: This type of work item is used to define a test scenario—typically a high-level description of a use case or flow that should be verified during testing. It helps to plan and structure what needs to be tested, but it is not used to report issues discovered during the execution of those tests. Since the failure has already been identified, it no longer belongs in a test planning category.
C. Feedback: Feedback items are usually used during user acceptance testing or exploratory reviews when users or stakeholders provide comments on features, user interface elements, or usability. Feedback is typically more subjective and related to enhancement ideas, user preferences, or experience—not broken functionality. A broken step in a process, especially during functional testing, is not just feedback—it is a technical issue.
D. User story: A user story represents a new piece of functionality or feature from the perspective of an end-user. For example, a user story might describe a new requirement like, "As a case manager, I want to receive an email update when the case status changes." It is not appropriate to use a user story to document defects in existing functionality. Moreover, reporting the failed email-sending action as a user story would misrepresent the issue and could delay its resolution since it would be treated as a new requirement instead of a fix for an existing problem.

In summary, the failure of the "Send case status email" step to send an actual email is clearly a defect. To ensure that it is properly prioritized, investigated, and resolved by the development team, it should be captured as a bug in Agile Workbench. This ensures that the issue is flagged for resolution and can be tracked through to its fix and retesting. Proper classification of issues is vital for maintaining project clarity, accountability, and progress tracking.

Question 3

When creating a data transform rule in Pega Platform, what specific information do you define in the Context section?

A. The application layer, class, and ruleset version that the rule applies to
B. The rule types that you previously marked as relevant records
C. The case types, user portals, and personas that use the rule
D. The application name, rule type, label, and rule identifier

Answer: A

Explanation:

In Pega Platform, when you create a new rule—such as a data transform—you must define a Context. The Context section is essential for ensuring the rule is appropriately scoped and versioned within the overall application structure. Specifically, when configuring a data transform rule, the Context section includes three key elements: the application layer, the class, and the ruleset version in which the rule will reside.

These components serve the following purposes:

Application layer: Pega applications are typically structured into multiple layers (e.g., implementation, framework). The application layer determines where within the application stack the rule will be used. Selecting the correct layer ensures that the rule is only accessible where appropriate, maintaining modularity and reuse.
Class: Every rule in Pega is associated with a class. The class defines the scope or context of the rule and determines what data the rule can access and manipulate. For data transforms, the class typically aligns with a case type or data type, defining the structure the transform will operate on.
Ruleset version: This defines the versioned container for the rule. Rulesets in Pega are like modules that group rules together. Versioning allows changes to be tracked and managed over time, supporting development best practices like rule promotion between environments (e.g., development to testing to production).

Here’s why the other options are incorrect:

B. The rule types that you previously marked as relevant records: Relevant records are used to define which rules are contextually available in certain authoring environments, like App Studio, especially for low-code development. They are not configured in the Context section of a data transform rule.
C. The case types, user portals, and personas that use the rule: While these elements determine how and where a rule might be used in the broader application, they are not specified in the Context section. Usage is typically determined later through integration in process flows or user interfaces.
D. The application name, rule type, label, and rule identifier: These are part of the rule’s overall metadata and are entered in the initial rule creation screen. The rule label and identifier are naming elements, and the rule type is preselected (e.g., Data Transform). These do not define the Context section specifically.

In summary, the Context section of a data transform rule in Pega is crucial for placing the rule in the correct location within the application structure. This includes specifying the application layer, the class the rule applies to, and the ruleset version where it will be stored. Defining this information ensures that the rule can be managed effectively, reused appropriately, and promoted safely across development stages. Therefore, the correct answer is A.

Question 4

Which two of the following statements accurately describe the Constellation design system in Pega? (Choose two.)

A. Constellation design system components are not available in the Traditional UI architecture.
B. Constellation design system is a section-based architecture.
C. Constellation design system improves context switching or multitasking.
D. Constellation design system uses a modular design.

Answer: A and D

Explanation:

The Constellation design system in Pega is a modern UI framework introduced to enhance the usability, consistency, and maintainability of applications built on the Pega Platform. It reflects a shift away from the traditional section-based UI and instead embraces a modular and model-driven design approach.

Let’s break down why A and D are correct and why B and C are incorrect:

Correct Statements

A. Constellation design system components are not available in the Traditional UI architecture:
This is correct. The Constellation design system introduces a new architecture and a distinct rendering engine that is separate from the Traditional UI (also referred to as section-based UI). Because of this separation, the reusable components and widgets developed under the Constellation design system are not compatible with applications built using the Traditional UI framework. Developers cannot simply plug Constellation components into Traditional UI applications without migrating to the Constellation architecture.
D. Constellation design system uses a modular design:
This is also accurate. One of the core principles of Constellation is its modular design, where UI is built using pluggable and reusable modules. These modules—called view components—allow for consistent styling, behavior, and responsiveness across the application. This modularity supports rapid development, easier maintenance, and improved scalability. The modular approach also helps streamline the user experience by enforcing design patterns and eliminating inconsistent custom UIs.

Incorrect Statements

B. Constellation design system is a section-based architecture:
This is incorrect. Section-based architecture is a hallmark of the Traditional UI design system. Constellation, in contrast, moves away from this by using a model-driven, declarative approach to UI configuration. It relies on view components instead of hand-crafted sections, promoting abstraction and consistency over manual customization.
C. Constellation design system improves context switching or multitasking:
This is misleading and largely inaccurate. While Constellation focuses on simplifying the user experience and reducing complexity, it does not prioritize context switching or multitasking. In fact, one of the trade-offs of Constellation’s streamlined interface is that it limits multi-tabbed or multi-window interactions, features that some users rely on for multitasking. Traditional UI architectures offer more flexibility in terms of custom layouts that can facilitate complex user workflows with multiple screens.

The Constellation design system represents a modernized, modular, and consistent approach to building UI in Pega. It introduces reusable components and separates itself from the Traditional section-based UI model. While it simplifies development and enforces UI consistency, it does not support multitasking capabilities like context switching and does not interoperate with the Traditional UI system. Therefore, the correct answers are A and D.

Question 5

In an order fulfillment case type, the customer needs the ability to update their profile information—including account credentials, contact information, and a list of open orders—during the order placement stage.

How should you configure the case type so the customer can update any of these profile pages independently, and as needed?

A. Add an alternate stage to the case life cycle.
B. Add a button for each profile page to each assignment.
C. Add an optional process to the case workflow.
D. Add a set of optional actions to the case workflow.

Answer: D

Explanation:

In Pega Platform, when users need the flexibility to perform specific actions at their discretion—such as updating personal or profile-related information—these are best implemented using optional actions. Optional actions allow for non-linear interactions that do not interfere with the main case flow but are still available when relevant.

In this case, the customer is working within the order placement stage and needs the flexibility to update parts of their user profile, such as their account ID and password, contact details, or open orders. Importantly, the user must be able to make these updates individually and on demand. The most efficient and user-centric way to support this is by using optional actions, which are typically configured through flow actions that can be launched from user interface elements like buttons or menus.

When you add a set of optional actions to the case workflow, you enable users to execute these actions at points you define—often from within a case view or user portal. These actions do not dictate the sequence of the main workflow but are available whenever the user needs them. This is ideal for self-service scenarios, like updating profile data during an in-progress case.

Here’s why the other options are less suitable:

A. Add an alternate stage to the case life cycle:
Alternate stages are used when the case needs to follow a significantly different path due to an exception or major change in direction. Updating user profile information does not qualify as a major deviation requiring a new stage. It is more of a utility action that should be available from the current stage.
B. Add a button for each profile page to each assignment:
This approach is technically possible but inefficient and not scalable. It creates redundant UI elements across multiple assignments, cluttering the interface and requiring extra maintenance. Pega promotes configuration over customization, and repeating UI buttons in every assignment defeats this principle.
C. Add an optional process to the case workflow:
While this seems close, an optional process generally refers to a subprocess that is launched manually and may run concurrently with the main case flow. However, this is more appropriate for larger, distinct processes, not simple data updates. Moreover, optional actions offer a more direct and granular approach for discrete updates like those in this scenario.

In summary, to allow users to update individual profile pages as needed—without disrupting the main case flow—optional actions provide the most appropriate, clean, and flexible mechanism. These actions can be configured to update specific sections of user data and can be invoked when needed during the case. Therefore, the correct answer is D.

Question 6

An event center has a case type for booking a dining room. Customers first provide basic information and specify whether they want catering. If they do not want catering, they immediately receive a rental rate quote. If they do want catering, they must choose a menu before receiving the quote.

What two configuration options should you use to support this behavior? (Choose two.)

A. Create parallel processes for providing menu preferences and for providing the customer with the rental rate quote.
B. Create a checkbox for customers to indicate whether they want catering for the event. Add a decision shape that evaluates whether the customer checks the box.
C. Configure the menu preferences and appointment date fields with a visibility condition if the customer selects the catering checkbox.
D. Create a process for customers to indicate menu preferences. Add the process as a case-wide optional action.

Answer: B and C

Explanation:

This scenario involves conditional case flow behavior based on whether the customer selects catering. If they choose not to request catering, the case should proceed directly to generating a rental quote. If they do request catering, the case should pause to collect menu preferences before generating the quote. This type of conditional behavior in Pega is typically implemented using decision shapes and UI visibility conditions.

Let’s break down the correct and incorrect options:

Correct Answers

B. Create a checkbox for customers to indicate whether they want catering for the event. Add a decision shape that evaluates whether the customer checks the box.
This is essential for controlling the case flow. A decision shape allows the case to follow different paths based on whether the customer opts for catering. If catering is selected (checkbox checked), the case moves into the menu selection path. If not, it skips directly to quoting. The checkbox is a simple and intuitive way to capture the customer’s choice and is easily referenced in the decision shape.
C. Configure the menu preferences and appointment date fields with a visibility condition if the customer selects the catering checkbox.
This is necessary for user interface behavior. Even though the case flow is managed by the decision shape, the visibility condition ensures that the UI only presents the menu selection fields when relevant. This avoids confusing the customer with irrelevant inputs and enhances user experience. The fields can be set to appear only when the catering checkbox is selected, making the form dynamic and responsive to user input.

Incorrect Answers

A. Create parallel processes for providing menu preferences and for providing the customer with the rental rate quote.
Parallel processes are used when multiple processes can happen independently and simultaneously. In this case, the customer must either go to the quote or go to menu selection before getting the quote, which is a sequential and conditional process, not a parallel one. Therefore, using parallel processes would lead to inaccurate case behavior—e.g., generating a quote before menu preferences are finalized.
D. Create a process for customers to indicate menu preferences. Add the process as a case-wide optional action.
Optional actions are meant for non-essential or user-initiated actions. However, selecting a menu is not optional when catering is requested—it is a required part of the case flow. Optional actions are not automatically enforced in the flow and would allow users to bypass critical steps, such as menu selection, undermining the business logic.

To properly handle the conditional flow based on whether catering is requested, you need a decision shape to route the case logic and UI visibility conditions to control which fields are displayed. This ensures the case only presents and processes the menu selection step when catering is selected. Therefore, the correct answers are B and C.

Question 7

In the Travel booking case type, if a passenger indicates they are traveling with a service animal, they must provide details such as the type, size, and age of the animal.

How should you configure the case life cycle to ensure this requirement is met?

A. Create a Service animal accommodation child case that is automatically resolved if the passenger is not traveling with a service animal.
B. Apply an optional action to the Travel booking case type to allow the passenger to provide the information as needed.
C. Add an Identify service animal process within the Travel booking case life cycle and apply a condition to determine when to run the process.
D. Configure a validation rule in the Travel booking case type settings to check whether the passenger is traveling with a service animal.

Answer: C

Explanation:

In Pega, when a business requirement dictates that certain data must be collected only under specific conditions, the most appropriate way to model this behavior is by using conditional processes in the case life cycle. In this scenario, the requirement is clear: if a passenger indicates they are traveling with a service animal, then the application must collect three pieces of information—type, size, and age of the animal.

This leads us to the best design pattern, which is:

Embedding a process within the case life cycle that is triggered only if the passenger selects that they are traveling with a service animal. This is achieved using a when condition on the process.

Let’s analyze each option:

Correct Answer:

C. Add an Identify service animal process within the Travel booking case life cycle and apply a condition to determine when to run the process.
This is the correct choice because it precisely aligns with the conditional nature of the requirement. By adding a process called something like "Identify Service Animal" into the life cycle and using a condition (e.g., .IsTravelingWithServiceAnimal == true), the process will only execute when relevant. It is clean, scalable, and adheres to Pega's model-driven development principles.

Incorrect Answers:

A. Create a Service animal accommodation child case that is automatically resolved if the passenger is not traveling with a service animal.
While child cases are appropriate for modular or reusable case logic, this scenario doesn’t require the complexity of a separate case. Additionally, automatically resolving a child case introduces unnecessary processing overhead and complicates the case hierarchy without clear benefits. The logic is better handled inline with a conditionally-run process.
B. Apply an optional action to the Travel booking case type to allow the passenger to provide the information as needed.
Optional actions are not appropriate here because collecting service animal information is mandatory when the condition is met. Optional actions are not enforced by the case life cycle and can be skipped by the user, which would result in missing required information.
D. Configure a validation rule in the Travel booking case type settings to check whether the passenger is traveling with a service animal.
Validation rules are used to ensure data integrity after it has been entered, not to control case flow behavior. While a validation rule could enforce that the type, size, and age are not blank after the user starts entering service animal data, it won’t conditionally display or activate the step to collect that data. That’s the job of a conditionally executed process.

The requirement is conditional process execution based on a user's input (i.e., if they are traveling with a service animal). This is best implemented with a dedicated process that runs only when a certain condition is met. Therefore, the correct answer is C.

Question 8

A company frequently receives multiple IT tickets for identical issues, such as “the office Wi-Fi is down.” To manage this, you configure a Search duplicate cases step to identify duplicate tickets.

What is the fundamental condition that should be used for this step?

A. Issue type is same
B. Name of submitter is same
C. Department is same
D. Office location is same

Answer: D

Explanation:

The purpose of the Search duplicate cases step in Pega is to identify whether other active or recently resolved cases are similar enough to be considered duplicates. This helps organizations avoid redundant processing and improve the efficiency of case resolution, especially in high-volume environments like IT service desks.

In the context of this question, the organization receives multiple tickets for recurring issues, specifically “the office Wi-Fi is down.” Although many people might report the same problem, the underlying issue is singular: Wi-Fi is down at a specific location. Therefore, the most critical distinguishing attribute for determining whether two tickets refer to the same problem is office location.

Let’s evaluate each option to see why D is correct and the others are not.

Correct Answer:

D. Office location is same
This is the most accurate and meaningful condition for detecting duplicate IT tickets about a shared infrastructure issue like Wi-Fi. Even if multiple users submit similar issue descriptions or issue types, what makes their tickets identical in business context is that they relate to the same office location. If one office is down, multiple people from that location might report the outage. If the issue is fixed, marking other similar tickets as duplicates avoids unnecessary duplicate handling and resolution.

Incorrect Answers:

A. Issue type is same
While “Wi-Fi issue” may be classified under a shared issue type like “Network Problem,” issue type alone is not a sufficient indicator of duplication. Two users in different locations could both report network problems that are unrelated (e.g., one in New York and one in Chicago). Hence, this condition is too broad.
B. Name of submitter is same
The fact that the same person submitted multiple tickets is not the primary concern in duplicate detection for infrastructure issues. It’s possible for one person to report multiple unrelated issues. Also, different people often report the same widespread problem—making submitter name an unreliable identifier for duplicates in this context.
C. Department is same
While department might narrow down similar business units (e.g., Marketing, Finance), it doesn’t necessarily correlate with geographic or technical factors involved in the issue. Wi-Fi being down is more likely tied to physical location than to a department, which may span multiple floors or even locations.

The core idea in this case is to consolidate duplicate reports of a shared infrastructure issue. Since Wi-Fi issues are tied to physical networks, and those are usually managed per office location, the best basic condition to configure in the Search duplicate cases step is the office location. This allows the system to group tickets that relate to the same outage and streamline the resolution process by linking or resolving duplicates efficiently. Thus, the correct answer is D.

Question 9

On a service level, the passed deadline interval is measured from ________________________.

A. the end of the goal interval
B. the end of the deadline interval
C. when a user begins the assignment
D. when the assignment is ready for a user

Answer: D

Explanation:

In Pega Platform, service-level agreements (SLAs) are used to enforce performance and response time targets for assignments, stages, and cases. An SLA defines three important time intervals:

Goal – the preferred resolution time.
Deadline – the maximum time by which the task should ideally be completed.
Passed Deadline – the time that elapses after the deadline has already been missed.

Each of these intervals starts counting from the same baseline—the moment an assignment becomes available for processing. That moment is defined as when the assignment is ready for a user, not when the user begins working on it.

The Passed Deadline interval is particularly relevant in scenarios where a task was not completed by the deadline. Once the deadline has expired, the Passed Deadline timer starts to measure how much time has passed since the assignment was due, which can be used to escalate the case, trigger additional notifications, or take corrective actions.

Let’s evaluate each option:

A. The end of the goal interval
This is incorrect because the goal interval is just a soft target. The Passed Deadline is not dependent on the end of the goal period. Both goal and deadline are parallel metrics, and the Passed Deadline does not start after the goal; it starts after the deadline, and all intervals are anchored to the assignment ready time.
B. The end of the deadline interval
Although the Passed Deadline logically starts after the deadline has expired, the question is asking: from what point in time is it measured? The deadline itself is defined as a certain time period after the assignment is ready, so technically, the Passed Deadline is also measured from when the assignment is ready, not from the end of the deadline.
C. When a user begins the assignment
This is incorrect because service-level timers are system-controlled, and they begin counting from the moment the assignment is generated and routed—not when a user opens or interacts with it. Waiting for user interaction would be unreliable and inconsistent for performance tracking.
D. When the assignment is ready for a user
This is the correct answer. The SLA clock begins ticking as soon as the assignment is created and available in the worklist or workbasket. All SLA intervals—goal, deadline, and passed deadline—are measured from this initial availability point. This ensures accurate and consistent timing for monitoring case progress and triggering escalations.

In Pega, all service-level intervals, including Passed Deadline, are based on the time when the assignment is ready for a user to work on. This makes D the correct answer, as it accurately reflects how SLA timing is implemented in the system.