Which binding configuration ensures POL_2 is evaluated after POL_1 when attaching policies to a load-balancer vserver?

• A. bind lb vserver Ib.vsrv -policyName POL_1 -priority 110 -gotoPriorityExpression NEXT -type REQUEST bind lb vserver Ib.vsrv -policyName POL_2 -priority 100 -gotoPriorityExpression END -type REQUEST
• B. bind lb vserver lb_vsrv -policyName POL_1 -priority 90 -type REQUEST bind lb vserver lb_vsrv -policyName POL_2 -priority 100 -type REQUEST
• C. bind lb vserver Ib.vsrv -policyName POL_1 -priority 90 -gotoPriorityExpression NEXT -type REQUEST bind lb vserver Ib.vsrv -policyName POL_2 -priority 100 -gotoPriorityExpression END -type REQUEST
• D. bind lb vserver Ib.vsrv -policyName POL_1 -priority 100 -gotoPriorityExpression NEXT -type REQUEST bind lb vserver Ib.vsrv -policyName POL_2 -priority 100 -gotoPriorityExpression END -type REQUEST

Answer: (C)

Policies bound to a load-balancer vserver are processed in a defined order driven by their priority and flow control. Lower numeric priority values run earlier, and the gotoPriorityExpression determines what happens after each policy: NEXT moves to the next bound policy, END stops the chain. To ensure POL_2 is evaluated after POL_1, POL_1 must have a smaller priority than POL_2 and POL_1 should indicate to continue (NEXT) to the next policy. Then POL_2 can run and end the evaluation (END) afterward. In this setup, POL_1 has priority 90 with NEXT, and POL_2 has priority 100 with END, so POL_1 is evaluated first, NEXT sends control to POL_2, POL_2 runs, and END stops any further processing. If POL_1 had a higher value, or if the priorities were the same without explicit flow control, POL_2 might not be guaranteed to run after POL_1.