Security
Separate authentication from authorization
Pega security questions often test the difference between proving identity and granting permission. Authentication verifies an operator through mechanisms such as password policies, LDAP, SAML, or SSO. Authorization determines what that operator can do. Role-based access is expressed through Access of Role to Object (ARO) rules, which grant class-level permissions to roles. Access Control Policies add attribute-based conditions, such as allowing an action only when a case property meets a threshold. Privileges can gate specific actions. Organization, division, and unit structures affect operator context and data access.
Design for least privilege
Grant the minimum access needed. Do not assume a role name grants access by itself; permissions come from AROs, policies, and privileges. Case type security can restrict who can create or access a case type, while class-level rules govern property and rule access. Protect sensitive data with appropriate encryption and avoid exposing values in UI or logs. Validate and parameterize inputs to reduce injection risk.
Traps candidates miss
A frequent trap is using an ARO when the requirement is conditional on data. ARO is broad and class-based; an access control policy is better for "only if Amount > 100000." Another trap is confusing authentication with authorization or assuming a hidden UI control enforces security. Client-side restrictions are not security controls. Also check precedence: deny conditions generally override allows, so an explicit deny can defeat an otherwise valid role permission.
Worked rule of thumb
For "only managers may approve claims over 100,000," assign the approval privilege or action to the manager role, then add an access control policy with a condition on claim amount. Do not rely on a read-only UI field or a role name alone.