Explanation:

A. Minimal resources are assigned to update Pega Platform for each new release.
This is not a valid reason to choose Pega Web Mashup over API. In fact, Web Mashups often require more UI-related updates during Pega upgrades, because Mashups rely on the rendered Pega UI, which can change significantly with each platform release (e.g., layout, styling, or JavaScript behavior). While REST APIs are typically versioned and more backward-compatible, Web Mashups depend on front-end elements that are not as stable. If a team has minimal resources, they would likely prefer a more stable, decoupled integration such as API calls, rather than UI-dependent integrations that need maintenance after upgrades.

Reference:
Pega Community – Embedding Pega using Web Mashup “Consider the upgrade impacts on user interface elements when embedding Pega content via mashups.

” B. Developers have access to only App Studio when configuring the integration.
This is a valid and recommended use case for Web Mashup. When developers or citizen developers are limited to App Studio, Web Mashup offers a low-code, UI-driven method to embed Pega forms and assignments into external websites without needing deep technical knowledge or access to Dev Studio. App Studio provides ready-to-use embed options, and the mashup code snippet can be placed in any HTML-based front-end. REST API integration, by contrast, requires Dev Studio access and knowledge of authentication, service rules, and data mapping — which are not accessible or practical within App Studio

. Reference:
Pega Community – Configuring Web Mashups in App Studio “You can configure web mashups directly in App Studio to embed case types in web pages.

” C. Users are expected to create cases, open assignments, and manage data privacy.
This scenario clearly supports the use of Web Mashup. When end users (e.g., customers or employees) interact directly with Pega to perform actions like creating cases, completing assignments, or updating sensitive data, you need to expose the Pega UI. Web Mashup allows such interaction by embedding Pega screens within a parent website, preserving context, session management, and access controls. REST APIs do not provide UI — they only allow system-level data exchange. For user-facing functionality with case processing, Web Mashup is the best practice.

Reference:
Pega Docs – Web Mashup Use Cases “Use Pega Web Mashup when you want users to interact with your Pega applications directly from a web page.”

D. The application is built on Pega Platform version 8.2 using UI Kit.
This is not a deciding factor. While Web Mashup is technically compatible with applications built on UI Kit in Pega 8.2, this does not make it a best practice. UI Kit is a legacy front-end framework and lacks some of the responsive capabilities and performance enhancements of Theme Cosmos or Constellation. Also, as the platform evolves, Pega encourages migration away from UI Kit. Therefore, choosing Web Mashup solely because of the platform version or UI kit does not align with best practices. The decision should instead focus on interaction type (user-facing vs. system integration).

Reference:
Pega Community – UI Architecture Evolution “UI Kit is supported but is no longer recommended for new applications. Consider migrating to Theme Cosmos or Constellation for long-term maintainability.”

Final Answers:
B. Developers have access to only App Studio when configuring the integration.
C. Users are expected to create cases, open assignments, and manage data privacy.

Explanation:

A. Access of Role to Object:
Access of Role to Object (ARO) allows you to define permissions (like read, write, delete) for a particular class (data or case) based on role. However, it does not provide conditional logic — it grants or denies access globally for a role across the entire application or class. In this scenario, you only want to block access conditionally — when the order is in the Fulfillment stage. ARO cannot evaluate conditions like stage or property values, so it's not suitable here.

Reference:
Pega Docs – Defining AROs

B. Access When:
Access When rules are boolean conditions used within an ARO or Access Deny rule to make access conditional — but on their own, they do not enforce security. They act like helper logic (true/false checks), typically referencing properties or stages (like .pyStageName = "Fulfillment"). So while you would use an Access When in this case, by itself it doesn't satisfy the requirement. It must be combined with Access Deny or ARO to actually block access.

Reference:
Pega Docs – About Access When rules :

C. Access Group:
An Access Group links an operator to an application, roles, portals, and work pools. It determines what application context the user runs in and what roles are assigned, but it does not define fine-grained access control (like restricting updates in a certain stage). This requirement involves field-level or case-level security logic, not user-application assignment. So Access Group is irrelevant here.

Reference:
Pega Docs – Access Groups

D. Access Deny :
Access Deny rules are used to explicitly deny users the ability to perform actions (like modify, write, delete) based on conditions, and they can use Access When logic to determine when to block access. In this case, you can create an Access Deny rule for the Car Dealer role on the Order class, denying the Modify or Update action when the case is in the Fulfillment stage — which would be implemented using an Access When rule like .pyStageName == "Fulfillment". This makes Access Deny the ideal solution because it lets you block an action based on a specific condition — exactly what the question requires.

Reference:
Pega Docs – About Access Deny

Final Answer:

D. Access Deny :
Because it lets you block users (e.g., car dealers) from modifying cases based on specific conditions (like the Fulfillment stage), using Access When as a condition.

Explanation:

A. Configure a data transform to apply the Open-Review status on the appropriate assignments.
This is incorrect because setting the case status via a data transform is not standard practice when assigning status during workflow stages or assignments. Data transforms are used to initialize or manipulate data, but setting status is better handled using assignment configuration or utility shapes like UpdateStatus. Also, it adds unnecessary complexity and violates Pega best practices for work status management.

Reference:
Update Case Status – Pega Best Practices

B. Add Open-Review as an allowed status on the case type record.
This is correct. Before a status can be used in a case, it must be listed in the "Statuses" section of the case type rule. This ensures that it is a valid status that appears in history tracking, reporting, and case lifecycle control. If you try to set a status that's not in the case type configuration, you may get errors or the status may not behave correctly. This is a required setup step.

Reference:
Pega Docs – Case Type Rule Form

C. Create a field value record for the Open-Review status.
This is not necessary in most cases. Pega uses Field Value rules for localization or when you need to translate status labels into different languages. If you don’t need localization or alternate wording, you don’t need to create a Field Value just to use a new status. The system will accept "Open-Review" as a status as long as it’s defined in the case type record. So unless there's a localization requirement, this step is optional, not required.

Reference:
Pega Docs – Field Value Rules

D. Apply the Open-Review status to the appropriate assignments.
This is correct. In the assignment shape (or a preceding utility shape like UpdateStatus), you configure the case to transition to a specific status (here: Open-Review) once it reaches that point in the process. This ensures the status reflects the case’s real-time state and drives SLA, escalation, and business reporting. Setting the status directly in the assignment's configuration panel is the standard approach.

Reference:
Pega Community – Assignments and Status

Final Answers:
B. Add Open-Review as an allowed status on the case type record
D. Apply the Open-Review status to the appropriate assignments.

Explanation:

A. Delete any properties exposed in table columns from the BLOB.
This option is incorrect and unrelated to the Purge/Archive wizard. Deleting exposed properties from the database (i.e., removing columns from a table or from the BLOB) is a schema-level operation that affects how data is stored and queried. Pega does allow exposing or un-exposing properties, but that process is done via column population jobs or class rule updates, not the Purge/Archive wizard. Moreover, this is a data model optimization task, not a method for purging old case data for performance purposes.

Reference:
Pega Docs – Exposing properties and BLOB structure

B. Remove old cases to reduce the size of a database table.
This is the correct and intended use of the Purge/Archive wizard. In Pega, over time, resolved (completed) cases can accumulate in large volumes, leading to larger database tables and slower performance for queries, reporting, and data retrieval. The Purge/Archive wizard helps identify and archive or delete old case instances based on configurable criteria like age, status, or case type. Archiving also provides an option to restore cases later, maintaining compliance needs while optimizing performance.

Reference:
Pega Docs – About the Purge/Archive wizard “Use the Purge/Archive wizard to remove resolved work items from your database to reduce the size of work tables and improve performance.”

C. Delete stored SQL procedures that have been updated.
This is not related to the Purge/Archive wizard. Stored SQL procedures are database-level constructs typically used in custom integrations or extensions. Pega does not manage SQL procedures with the Purge/Archive wizard. If these procedures are outdated, they would need to be updated or removed manually by a database administrator (DBA) or via a database deployment script. The wizard plays no role in managing or removing stored procedures and is focused solely on case data (work objects).

Reference:
There is no connection in Pega documentation between Purge/Archive and SQL stored procedures.

D. Remove unused rules caches maintained on the system.
This option is also incorrect. Rules cache management is handled through System Management Application (SMA) or Admin Studio, or during a system restart or cache invalidation process. This process clears cached rule instances to reflect rule updates immediately. However, it has nothing to do with the Purge/Archive wizard, which manages case-level data, not system cache or memory. Managing rule caches may impact performance in different ways but is not the function of this wizard.

Reference:
Pega Docs – Admin Studio: Cache Management

Final Answer:
B. Remove old cases to reduce the size of a database table.

Explanation:

A. Adding an operator record in Dev Studio creates an access group in App Studio.
This is incorrect. When you create an operator record in Dev Studio, you can assign an existing access group to that operator — but you are not creating a new access group. Access groups define which application(s) and roles the operator has access to. These access groups must already exist or be created manually in Dev Studio or App Studio. The operator ID links to an access group but does not generate it. App Studio allows assigning personas, not creating access groups automatically.

Reference:
Pega Docs – Operator ID and Access Groups

B. An operator record must have a default work group.
This is the correct answer. Every operator must have a default work group, which is essential for work routing and team organization. A work group defines the manager (workbasket) and can help route tasks to appropriate work queues or team members. Even if routing isn’t used extensively, Pega expects a default work group for background processing (like assignment delegation, reporting, etc.). This is typically set in the Operator ID rule under the “Work” tab. Missing a default work group may lead to routing errors or failed assignments.

Reference:
Pega Docs – Setting up Operator IDs

C. Operator records must have an authorized manager.
This is incorrect. While an operator record can specify a reporting or authorized manager (for delegation or approval routing), it is not mandatory. Many operators, especially in lower environments or service accounts, don’t have managers assigned. This field is optional and mostly used for delegation, approvals, and performance tracking, but it is not required to create or use an operator record. Therefore, this is not a must-have field.

Reference:
Pega Docs – Operator ID Rule Form

D. Operator records in Dev Studio are known as personas in App Studio.
This is incorrect and represents a misunderstanding. Operator records define individual users (and their access groups, roles, work queues, etc.). Personas, on the other hand, are used in App Studio to model user roles or types, not individuals. For example, "Customer Service Rep" might be a persona, whereas "John.Doe" is an operator record. A persona may correspond to one or more access groups or roles, and help define user journeys — but it is not the same as an operator.

Reference:
Pega Docs – Personas vs. Operators

Final Answer:
B. An operator record must have a default work group.

Explanation:

A. A keyed data page is required for all data pages.
Keyed data pages are only one specific type of data page used to retrieve single records based on a key or set of keys. Not all data pages require keys. Pega supports a variety of data page types — such as list-type data pages, non-keyed pages, and pages scoped at node, thread, or requestor levels. A data page that loads a list of countries, for example, doesn’t need keys. Keyed data pages are used when you want per-key caching and fast retrieval of individual records, not universally.

Reference:
Pega Docs – Keyed Data Pages Overview

B. A keyed data page can use a report definition.
A report definition can be configured as a data source for a keyed data page. This is useful when you need to fetch records from the Pega database using the value of a key passed into the data page (e.g., CustomerID). When the report definition is used, Pega will use the provided key(s) as filter criteria for the report, ensuring that the correct row is retrieved. This setup enables efficient, reusable data access patterns for frequently queried records.

Reference:
Pega Docs – Data sources for data pages

C. A keyed data page can return multiple embedded pages.
A keyed data page is intended to return a single object (Page structure), not a list. It retrieves one record per unique key value, such as retrieving one customer record by Customer ID. If you need to return a list of results (multiple embedded pages), you should configure the data page as a List structure rather than using a keyed page. Keyed pages are for lookup scenarios, not for returning collections or arrays of data objects.

Reference:
Pega Docs – Data Page Structure: Page vs. List

D. A keyed data page can have multiple keys.
Keyed data pages can be configured with multiple keys, allowing you to fetch records using composite key values, such as (CustomerID, Region) or (OrderID, LineNumber). When the data page is referenced with a specific combination of key values, Pega retrieves and caches that exact record. This is helpful for data models where a single identifier is not enough and the data is uniquely identified by a combination of properties. Pega supports multiple parameters to define the keys.

Reference:
Pega Docs – Keyed Data Pages Configuration

Final Answer:
B. A keyed data page can use a report definition.
D. A keyed data page can have multiple keys.

Explanation:

A. A data page is available across multiple user sessions and is updated once a day.
This is not an appropriate example for application settings. The use case here is about data page scope and refresh strategy, which is handled by data page configuration, such as scope (Node, Requestor, Thread) and refresh strategy (time-based, reference-based). Application settings do not control how often data pages refresh or how they are shared. Therefore, this scenario has nothing to do with dynamically configurable application values, and application settings are not used in this context.

Reference:
Pega Docs – Configuring Data Page Refresh Strategy

B. An IT service application stores a list of operating systems using a Pega system of record.

This is not a valid use case for application settings either. Here, the list of operating systems is data, not configuration. It should be stored in a data type or database table, possibly exposed through a data page. Application settings are meant for environment-specific or dynamic configuration values, not storing lists of reference data. If you need a dynamic list of operating systems, you'd use a data page backed by a data type, not an application setting.

Reference:
Pega Docs – Defining Data Types

C. A weather service application points to a web service for weather data.
This is the correct and ideal use case for application settings. When integrating with external systems (like a weather API), the endpoint URL might vary across environments (Dev, QA, Prod). Instead of hardcoding the URL in a connector or data page, you can use an application setting to define it dynamically. This allows non-developers (or DevOps) to change the URL without altering any rules. Application settings improve environmental flexibility, deployment safety, and manageability of external configurations.

Reference:
Pega Docs – Using Application Settings

D. A manager can update the price of a service without a developer editing the application.
This sounds like a data management or business rule delegation use case, not a fit for application settings. If you want a manager to update prices, the correct approach is to use delegated rules (like decision tables or data types) or allow them to update the data through a UI. Application settings are not editable by business users during runtime and are more suitable for environment-specific technical configurations, not business data. So this is not appropriate for application settings.

Reference:
Pega Docs – Rule Delegation for Business Users

Final Answer:
C. A weather service application points to a web service for weather data.

Explanation:

A. Performance Profiler:
The Performance Profiler is the best tool in this case. It shows a breakdown of the time spent in each rule execution, including data transforms, activities, when rules, and more. It records execution time for each rule over a given requestor session, allowing you to identify slow-performing rules. In your scenario, if a data transform is performing poorly, the profiler will show exactly how much time it took, enabling you to optimize the logic, eliminate unnecessary steps, or change the structure.

Reference:
Pega Docs – Using Performance Profiler

B. Database Trace:
Database Trace is useful for identifying SQL query performance issues — like slow queries, unindexed columns, or inefficient joins. It shows the database-level interaction including the time taken by queries, commits, and locks. However, it does not help directly in diagnosing performance problems within data transforms or other rule executions unless the problem originates from a query initiated by the data transform, which is not stated in this case.

Reference:
Pega Docs – Using Database Trace

C. Performance Analyzer (PAL):
PAL (Performance Analyzer) collects high-level performance statistics such as CPU time, rule cache hit/miss, page read/write, and total interaction time. It's good for analyzing system-wide performance or measuring requestor-level statistics, but it does not give granular insight into specific rule executions, like which data transform is slow. You’d use PAL to get overall performance metrics, then use Performance Profiler to drill into specific slow rules.

Reference:
Pega Docs – Using Performance Analyzer (PAL)

D. Tracer:
Tracer is a debugging tool that shows the sequence of rule executions, including activities, data transforms, when rules, and more. It’s excellent for debugging logic (e.g., why a value was or wasn’t set), but not designed for measuring performance. It does not capture timing information in detail or highlight performance bottlenecks like the Performance Profiler does. So while useful for correctness/debugging, it is not optimal for performance analysis.

Reference:
Pega Docs – Tracer Tool

Final Answer:
A. Performance Profiler

Explanation:

A. Specify the HR Managers work group when creating the Attachment category :
This is not a valid configuration for enforcing attachment security. In Pega, work groups are used for routing and organizational structure, not for access control or permissions. When creating or managing an Attachment Category, there is no option to limit access based on a user’s work group. Access control must be enforced using privileges, Access of Role to Object (ARO), and access control policies. Thus, choosing a work group here does not secure the attachment.

Reference:
Attachment categories – Pega Docs

B. Apply the appropriate privilege to the Attachment category:
This is one of the correct configurations. When you create an Attachment Category (e.g., "Reference Letter"), you can assign a privilege to control read, update, or delete access. This allows only operators with that privilege (granted via their role) to access the attachment. This setup ensures that only users explicitly allowed to view the attachment can do so, even if they otherwise have access to the case. It’s an essential part of Pega’s fine-grained attachment security model.

Reference:
Pega Docs – Controlling access to attachments

C. Define an Access of Role to Object (ARO) record on the Access group for HR Managers:
This is the second correct configuration. An ARO (Access of Role to Object) grants specific privileges to a role within an access group. In this case, you must define an ARO for the class (e.g., Data-WorkAttach-File) and assign the privilege you created for viewing the reference letter. When the HR Manager's access group includes this role, they get the privilege — allowing them to read the attachment based on the Attachment Category's restriction.

Reference:
Pega Docs – Defining Access of Role to Object records

D. Configure an access control policy condition on the Attachment category :
This is not necessary in this scenario. Access control policies (such as attribute-based access control or ABAC) can control access to properties or attachments based on dynamic conditions, but the requirement here is role-based ("only HR Managers"). This is best achieved using privileges and AROs, which are simpler and more appropriate for static, role-based access. ABAC is overkill unless access is conditional (e.g., time-based, state-based), which the question doesn’t imply.

Reference:
Pega Docs – Access control policies

Final Answer:
B. Apply the appropriate privilege to the Attachment category
C. Define an Access of Role to Object record on the Access group for HR Managers

Explanation:

C. A new application is migrated to the production system :
The Static Assembler is primarily used after migrating a new application to production. When an application is first deployed, the system must dynamically assemble rules into Java classes and compile them on first use, which can result in performance lags. The Static Assembler pre-compiles these rules so users don't experience slowness or delays the first time rules are executed. It’s best practice to run the Static Assembler after migrating to avoid the overhead of rule assembly at runtime.

Reference:
Pega Docs – Static Assembler Tool Pega Community – Rule Assembly

A. The server is managing a large number of rules caches:
While having many rules in cache can affect system memory and performance, the Static Assembler is not used to manage caches. Cache management is handled by internal mechanisms like Rule Cache, Declarative Cache, and Data Page Cache, not Static Assembler. This tool only pre-assembles rules, reducing initial latency, not managing runtime cache sizes.

Reference:
Pega Docs – Caching mechanisms

B. Access groups contain multiple production rulesets :
Multiple production rulesets in an access group can lead to rule resolution complexity, but it is not a cause for using the Static Assembler. This scenario can cause unexpected rule behavior or priority issues, but not rule assembly performance issues. Therefore, Static Assembler is not applicable here.

Reference:
Pega Academy – Rule resolution and rulesets

D. The application record lists several branch rulesets:
Branch rulesets are typically used during development, not in production. They support parallel development but are not moved to production unless merged. Using Static Assembler in this context would not apply, as branch rules are not deployed to production and would be assembled at runtime during development anyway.

Reference:
Pega Docs – Working with branches

Final Answer:
C. A new application is migrated to the production system.

Explanation:

A. Allows downloading of rules for offline use with a mobile app :
In offline-enabled Pega mobile apps, the cache manifest plays a critical role in allowing specific rules (like UI rules, data transforms, and case types) to be downloaded and stored locally. This enables the mobile app to function even when the device is disconnected from the network. Developers can configure which rules are included in the offline package, helping to ensure users have access to the necessary features and logic even in offline mode.

Reference:
Pega Docs – Offline mobile apps Pega Academy – Configuring mobile offline access

C. Enables users to continue interacting with mobile apps while offline:
One of the primary purposes of the cache manifest is to enable offline functionality. When properly configured, the mobile app can store UI, rules, and data locally, allowing users to continue working on cases, entering data, or performing assigned tasks without internet access. Changes are synced back to the server once connectivity is restored. This improves user productivity, especially for field workers or users in remote areas.

Reference:
Pega Docs – Mobile offline synchronization

B. Provides access to static resources such as HTML files, image files, or JS files:
This statement is more applicable to traditional web cache manifests (like those in HTML5), not Pega's mobile cache manifest. Pega’s mobile offline capability is focused on rules and application content, not managing or caching static web assets directly like raw HTML or JS files. Although mobile apps include assets, the Pega platform handles those differently in its hybrid app model. Therefore, while it sounds accurate, it does not align with how Pega uses the cache manifest in mobile apps.

Reference:
W3C – HTML5 Cache Manifest (deprecated)

D. Supports debugging efforts by providing a run-time view of the rules accessed by the app :
This is incorrect. The cache manifest is not a debugging tool. Its function is to predefine and store rules/resources for offline access, not to provide insight into rule execution or access. For debugging rule behavior in a mobile app, you would use Tracer, Log files, or Live UI in Dev Studio (where applicable), not the cache manifest. Hence, this option does not describe the cache manifest’s role.

Reference:
Pega Docs – Debugging offline mobile apps

Final Answer:
A. Allows downloading of rules for offline use with a mobile app
C. Enables users to continue interacting with mobile apps while offline

Explanation:

A. Managers can reschedule but not delete appointments:
This requirement is related to role-based or action-based access control, not ABAC. The condition “Managers can reschedule but not delete” refers to restricting actions based on roles (e.g., a user’s access group or privileges). This is best enforced using Access of Role to Object (ARO) and privileges, not ABAC. ABAC evaluates attribute values at runtime rather than predefined roles or capabilities.

Reference:
Pega Docs – Configuring Access of Role to Object

B. Personal identifying information in the Work-Baking- class is restricted:
This is a classic use case for ABAC. ABAC is ideal for field-level and class-level protection, such as restricting access to PII (Personally Identifiable Information). For example, even if users can access a case, ABAC can ensure only authorized roles or attribute-matching users can view sensitive fields like SSNs or emails. This is implemented using Access Control Policies on classes or properties like .Email, .SSN, etc., in the Work-Baking- class.

Reference:
Pega Academy – Attribute-based access control

D. Bakers with a rating of 4 or better can add recipes to the database:
This also aligns perfectly with ABAC. Here, access depends on a user’s attribute – their rating. The access policy could state: If .UserRating >= 4, then allow action: AddRecipe. This is evaluated dynamically and would be implemented through an Access Control Policy condition (e.g., .UserRating >= 4) tied to the appropriate class or case type. ABAC lets you enforce fine-grained, dynamic security like this.

Reference:
Pega Docs – Defining Access Control Policy Conditions

C. Agents assigned the "Top Secret" clearance level can delete reports:
This also seems like it could be ABAC, but the action is “delete reports”, which typically refers to access to report definitions or delegated rules, managed using role-based security or privileges. ABAC is mainly intended for case-level and data-level access — not controlling access to the Designer Studio or developer tools. Therefore, ABAC is not the preferred mechanism here.

Reference:
Pega Docs – Privileges and role-based security

Final Answer:
B. Personal identifying information in the Work-Baking- class is restricted
D. Bakers with a rating of 4 or better can add recipes to the database