Explanation:

✅ A. The total number of records on the lookup object. → Correct
Lookup queries run against the lookup object (e.g. a custom object you’ve created for pricing rules). The more records exist on that object, the more rows are scanned and potentially returned. Salesforce has limits on total rows returned across all queries, so larger datasets increase row counts quickly.

B. The total number of lookup objects. → Incorrect
Having multiple lookup objects doesn’t itself directly increase query rows. It may increase the number of queries, but the count of rows depends on records in each object and how often those objects are queried. Merely having many objects is not a direct multiplier of row count.

✅ C. The total number of quote lines on the quote. → Correct
Lookup rules often run once per quote line. So if you have 100 quote lines, and one lookup rule, that’s potentially 100 queries. Each of those queries might return multiple rows, multiplying the row count.

D. The total number of fields on the lookup object. → Incorrect
Fields don’t impact row count. More fields only affect query width (number of columns), not number of rows returned.

✅ E. The total number of lookup queries. → Correct
Each lookup rule equals at least one query. Multiple rules, or multiple lookups in a single rule, multiply the total rows returned. For example:
2 Lookup Queries × 100 Quote Lines × 50 records in the lookup object = potentially 10,000 rows considered.

✅ How Lookup Row Limits Work

Salesforce CPQ limits the number of rows retrieved across all Lookup Queries for a quote. Each lookup query multiplies by the number of quote lines. Hence, three factors directly impact row volume:
- How many records exist in the lookup object → A
- How many times lookup runs (e.g. per quote line) → C
- How many lookup queries fire → E

Explanation:

Let’s understand the scenario step by step:

❶ Flagship Bundle contains:

A product option: Premium Container
A nested bundle: Warranty
Within Warranty bundle:
Warranty Options: Gold, Platinum, Diamond
By default → none selected

❷ Business Requirement

If a user selects Premium Container (in flagship bundle)
And user has not already selected a warranty option
Then automatically select Diamond warranty in the Warranty nested bundle

This means:
Your rule’s condition lives in the parent bundle (flagship) → i.e. “Premium Container selected”
Your rule’s action needs to target a product option inside the nested bundle (Warranty) → i.e. check the box for Diamond warranty.

How Child Bundle Levels work

Child Bundle Condition Level

Controls whether your rule’s conditions look into nested bundles.
We want the condition to stay in the parent bundle.
So we set Child Bundle Condition Level = 1 so that the rule looks only one level down for conditions if needed—but in this case, it stays at the top level because the condition is on Premium Container.

Child Bundle Action Level

Controls whether your rule’s actions can reach into nested bundles.
We definitely need the action to select the Diamond warranty option inside the nested Warranty bundle.
So we must set Child Bundle Action Level = 1 to allow the rule to fire actions one level down into the nested bundle.

Hence:

✅ Child Bundle Condition Level = 1 → stay in flagship bundle (ok for this scenario)
✅ Child Bundle Action Level = 1 → reach into nested Warranty bundle

Thus, Option B is correct.

Why the other options are incorrect

A. Child Bundle Condition Level = 1; Action Level = None
Wrong → Action Level = None prevents actions in child bundles.

C. Condition Level = None; Action Level = 2
Action Level = 2 reaches two levels deep. Warranty is only one level deep. Not required.

D. Both = None
Won’t reach into nested bundles at all.

Explanation:

Cloud Kicks wants to:
Stop selling Product Option X to new customers
Migrate existing contracts from Product Option X → Product Option Y at renewal time

Salesforce CPQ offers an out-of-the-box feature specifically for this:
Renewal Product Field

Here’s how it works:

On Product X, set the Renewal Product lookup field to Product Y.

When CPQ generates a renewal quote from the contract:
It automatically swaps Product X for Product Y.
Pricing, configuration, and rules follow the new product (Product Y).

Additionally:

The Renewal Forecast checkbox ensures the contract contributes to renewal forecasting reports and processes.
You’d typically set this true on the Contract record to manage pipeline forecasting correctly.

Hence, Option A is correct.

Why other options are incorrect

❌ B. On the Subscription record, change the Product Lookup to refer to the new version of the Product. Not how CPQ works.
You don’t manually edit Subscription records to swap products for renewals.
Renewal logic runs off the Renewal Product field.

❌ C. Leverage a Selection Product Rule to remove the old Product, and automatically add the new Product.
A Selection Product Rule operates during quote configuration.
It doesn’t help automatically replace products at renewal time.
The question is specifically about renewals.

❌ D. Use a Price Rule to swap the Product Lookup on Quote Line when a Renewal Quote Line is generated.
Price Rules adjust prices or fields but cannot replace one product with another.
The correct mechanism for replacing products during renewals is the Renewal Product field.

Explanation:

✅ A. Expose the Subscription Type field in the Quote Line Editor, allowing reps to choose between Renewable and Evergreen.
This is required because sales reps must select the subscription model (fixed-term vs. perpetual).

✅ D. Expose the Default Subscription Term field in the Quote Line Editor, allowing reps to choose between selling monthly or annually.

This is also required because:
For Renewable (annual), the term should be 12 months.
For Evergreen (monthly), the term should be 1 month (auto-renews until canceled).

Why Not B or C?

B (Set to Renewable by default) → Not necessary because A already allows manual selection of Renewable or Evergreen.

C (Typo: "dfe the Renewable/Evergreen") → Invalid option (likely a misprint).

Final Answer:

A and D are the two correct actions because:
A controls subscription behavior (Renewable vs. Evergreen).
D controls billing frequency (annual vs. monthly).

Explanation:

Let’s walk through the scenario:
“UC allows clients to negotiate a discount for Product A until a specified date up to contract activation.”

This means:

The discount is specific to Product A → you must relate it to a Product.
It’s valid only until a specific date → need an Expiration Date.
It’s a discount value → need the Discount field.

Hence the three required fields:

✅ A. Product

→ Correct
Contracted Price records are linked to a Product so CPQ knows which product to apply the negotiated price or discount to.
Without the Product field, the system won’t know which product receives the special price.

❌ B. Contract

→ Incorrect
Contracted Price records are not directly tied to a Contract record.
They relate to the Account, Product, or Product Family, but not directly to a specific Contract.

✅ C. Expiration Date

→ Correct
The requirement states “until a specified date.”
The Expiration Date on the Contracted Price determines when this special pricing stops being applied.
After expiration, the system reverts to standard pricing.

✅ D. Discount

→ Correct
Since this is about a negotiated discount, the Discount field must be filled in to define the % discount for the product.

❌ E. Effective Date

→ Incorrect (not required here)
Effective Date defines when the Contracted Price starts being applied.
The question only says, “until a specified date,” so the Expiration Date is mandatory.
Effective Date could be used, but it’s not strictly required unless the discount is future-dated.

So, the three essential fields to meet the requirement are:
✅ Product → defines which product the discount applies to.
✅ Expiration Date → controls when the discount ends.
✅ Discount → sets the negotiated % off the price.