Programming Fundamentals

Rule ordering mechanisms include 'literal' (explicit order), 'default' (no specific order), and 'sorted' (ordered by some criterion like priority or name). 'Numeric' is not a standard ordering mechanism in rule engines - the question correctly identifies it as the invalid option.

Exit criteria in rule tasks define conditions that halt rule execution. Valid exit criteria include 'Rule' (exit after a specific rule) and 'rule instance' (exit after a rule instance fires). 'Rule object' is not a valid exit criterion type - it's not a standard way to define when rule execution should stop. The question correctly identifies this.

append returns a NEW list with combined elements - it does not modify the original lists. list3 remains empty because append was not assigned back to list3. The correct expression would be (set! list3 (append list3 list1 list2)).

Inline functions are expanded in place by the compiler at compile time rather than being invoked via normal function call overhead at run time. This direct expansion reduces execution overhead, making compile time the correct phase for this mechanism.

Deleting a pointer twice causes undefined behavior, often manifesting as a CPU trap when the memory manager detects the invalid operation. The program may crash or corrupt memory silently.

Dynamic binding allows the program to determine which function implementation to call at runtime based on the actual object type, rather than the pointer/reference type. This enables runtime polymorphism through virtual functions.

Declare rules (like Declare Expressions, Constraints, and OnChange) execute automatically. They run during flow execution, at the end of activity steps, or upon database commits depending on the rule type, making 'All of the above' correct.

Declare rules in PRPC execute at multiple points: as flow processing advances between tasks, after activity step methods complete but before transitions, and when objects are committed to the database. This makes them versatile for maintaining data integrity throughout the application lifecycle.

Local variables in Pega are activity-specific. They exist only during the execution of that activity and are not stored persistently. They are not stored on the clipboard as temporary variables (A), cannot be stored in the database (C), and are not stored in automatically created named pages (D). Their scope is strictly limited to the activity context.

To branch to another flow without returning control, you simply do not have any connectors emanating from the Flow shape. This creates a one-way transfer - execution continues in the called flow and never returns to the original flow. The Flow parameters do not have a 'Branch' option.

Declare rules in Pega (like Declare Expressions, Constraints, OnChange, and Triggers) execute automatically based on their configuration: during forward/backward chaining as control advances, after activity steps before transitions, or upon database commits.

-> (arrow operator) is correct because it is used with pointers to access members of an object. The dot operator (A) is used with object references, commas (B) are separators, and > (D) is a comparison or stream operator. The this pointer is a pointer, so it uses -> for member access.