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.

Explanation:

Let’s examine each option:

✅ A. The Active checkbox is FALSE on the Product record.

→ Correct
Only products marked as Active appear in the Product Selection screen.
If Active = FALSE → the product is hidden from users when searching.

❌ B. The Product is missing a related Cost record.

→ Incorrect
Cost records (from Cost object) are used for margin calculations or cost-plus pricing.
Missing a cost does not prevent product visibility in product selection.

❌ C. The Optional checkbox is TRUE on the Product record.

→ Incorrect
The “Optional” flag affects how the product displays inside a bundle (i.e. as an optional feature).
It does not hide standalone products from the product selection screen.

✅ D. The Product is missing a Pricebook Entry for the Quote’s Pricebook.

→ Correct
CPQ loads products from the Pricebook tied to the Quote.
If the product has no pricebook entry for that pricebook, it won’t appear in the search.

✅ E. The Component checkbox is TRUE on the Product record.

→ Correct
If Component = TRUE, the product is considered a bundle component.
Components are not visible in standalone product searches because they’re only selected through bundles.

Explanation:

Lookup Price Rule Purpose:

Lookup Price Rules are used to modify prices before any discounts are applied.
Since the regional multiplier should be applied before discounts, the price action should update a field that influences the final calculated price but does not override the base List Price.

Why "Special Price"?

Special Price is designed to temporarily adjust the price (e.g., promotions, regional adjustments) before discounts are applied.
The regional multiplier should adjust the price before any further discounts, making Special Price the correct target.

Why Not Other Options?

B. Partner Price & C. Customer Price: These are typically used for final customer/partner pricing (after all adjustments), not intermediate steps.
D. List Price: This is the base price and should not be modified by regional multipliers (as it would affect all pricing, not just region-specific adjustments).

Correct Configuration:

Lookup Price Rule should update "Special Price" with the List Price × Regional Multiplier.
Discounts will then apply on top of the adjusted Special Price.