Explanation:

Cardinality on a child product within a promotion (or any bundle) defines the quantity constraints for that child item as part of the offer.

A. Correct (Minimum)
The Minimum Cardinality sets the lowest quantity of that child product that must be included when the promotion is selected. If Min = 1, the product is required. This directly answers the minimum amount that can be purchased.

B. Correct (Maximum)
The Maximum Cardinality sets the highest quantity of that child product that can be included in the promotion. This answers the maximum amount that can be purchased.

D. Correct (Optionality)
By setting Minimum Cardinality = 0, you make the child product optional for purchase within the promotion. If Min > 0, it is mandatory. Therefore, cardinality determines whether the product is optional.

Why C is incorrect

C. Whether the price of the product rolls up into the total for the promotion
Price roll-up (whether a child's price contributes to the parent bundle's total) is controlled by a different setting, typically a Roll-up Price or Include in Total checkbox on the bundle member relationship, or by the pricing plan's roll-up logic. It is not governed by cardinality, which only controls quantity.

Summary
Cardinality = Quantity Rules (Minimum, Default, Maximum).
Price Roll-up = Separate Pricing Configuration.

Reference
Salesforce Industries CPQ Documentation: Configure Bundle Members or Set Product Cardinality. The documentation for adding child products to a bundle or promotion explains the Minimum, Default, and Maximum cardinality fields, which control optionality and quantity limits.

Explanation:

In Salesforce Industries CPQ (Vlocity CPQ), Attribute Categories are used to group related attributes and control how they appear in the Vlocity Cart during order capture.

At run-time, the Cart UI displays the Display Name field of the Attribute Category:
This is the user-friendly label shown to CSRs and end users
It is intended specifically for UI presentation

The Name field is primarily for internal reference and configuration, not for run-time display.

Why the other options are incorrect

A. Name ❌
The Name field is a system or technical identifier and is not shown in the Cart UI at run-time.

C. Category ❌
Category is not a run-time display field for Attribute Categories.

D. No fields are displayed at run-time ❌
Attribute Categories are clearly visible during order capture to organize attributes, so this is incorrect.

Key Exam Tip
If the question asks:
What is displayed at run-time?
👉 Always choose Display Name, not Name.

Salesforce often tests this distinction to ensure you understand design-time vs. run-time behavior in Industries CPQ.

Reference
Salesforce Industries CPQ Attributes & Categories Documentation
Trailhead: Industries CPQ Attribute Configuration

Explanation:

In Salesforce Industries CPQ, large product bundles with many levels and child products can generate massive JSON structures. This can negatively impact the performance of the Vlocity Cart and API response times.

The "Collapse Hierarchy" Flag
When this flag is enabled on a product bundle, the CPQ engine changes how it stores and processes the hierarchy. Instead of a fully expanded, nested JSON structure, it collapses or flattens the data.

Performance Benefit
This reduces the payload size and the processing overhead required by the browser and the server, making the Cart much more responsive when handling complex bundles (for example, a Triple Play bundle with dozens of optional components).

Why Other Options are Incorrect

❌ A. Enables a Search Item dialog
This is typically controlled by the Virtual Item property or the specific UI template used in the cart, not the hierarchy flag.

❌ C. Inherit parent product's cardinality
Cardinality (Min/Max/Default) is managed within the Product Structure settings on each individual child item, not through hierarchy collapsing.

❌ D. Restricts retrieving cardinality settings
Cardinality inheritance is a function of Object Types and the EPC hierarchy, which remains active regardless of how the data is flattened for performance.

Explanation:

Why "B" is Correct
In this scenario, the discount is a retention offer applied to a customer who is already using a service.

Relationship Persistence:
Since Sarah is an existing customer and the discount is applied to her monthly charges for a future duration (12 months), the discount is associated with her Account or her existing Assets.

Billing Integration:
Account-based discounts are typically applied to the billing profile so that every subsequent invoice generated for that account reflects the 20% reduction, regardless of whether she creates a new order or not.

Customer Lifecycle:
This is a classic Retention use case where the goal is to improve the Customer Experience (CX) at the account level to prevent churn.

Why Incorrect Answers are Wrong

A. Order-Based
An order-based discount is a one-time event tied to a specific transaction (for example, "$50 off your setup fee today"). Once that order is completed, the discount's logic is finished. While the CSR might use an order to initiate the change, the fact that it lasts for 12 months on her recurring charges makes it an account-level benefit.

C. Contract-Based
While the 12-month duration sounds like a contract, a contract-based discount specifically requires a legal Contract record to be active and associated with the line items. If Sarah just accepts the verbal offer over the phone and the CSR applies it to her account profile, it is an Account-Based discount. Contract discounts are usually negotiated during the signing of a formal B2B agreement.

References
Salesforce Help: Types of Discounts in Industries CPQ
Vlocity Documentation: Refer to the CME EPC Guide under Discounts, which distinguishes between Order, Account, and Service-level discounts.
Trailhead: Manage Customer Retention with Discounts

Explanation:

In Salesforce Industries CPQ, the Digital Commerce APIs (DC APIs) rely on a cached layer (stored in the CachedAPIResponse object) to deliver high-performance responses for product offers, pricing, eligibility, and promotions in customer-facing/self-service scenarios.

When you update something that affects pricing — such as:
Changing a product's base price in a Price List Entry
Updating pricing plans, matrices, or attributes used in pricing
Modifying promotions or adjustments

the cached responses become stale. The system does not automatically invalidate or refresh every cached entry for performance reasons.
To force the cache to reflect the latest pricing changes, the developer must run the Regenerate Cached API Records job.

This job re-evaluates and regenerates the cached API responses for the affected APIs (e.g., Get Offers, Get Offer Details, Get Price) based on the current catalog, rules, and pricing data.
It is specifically designed for scenarios where product/pricing data has been updated and the cache needs to be refreshed without clearing everything.

Why the other options are incorrect:

A. Populate API Cache job
This is the initial seeding job — run the first time you enable cacheable APIs or after a full clear. It does not refresh existing cached records after changes.

B. Migrate Cache Records job
This job is used during upgrades or data migrations (e.g., moving from old to new cache formats) — not for refreshing pricing after a product update.

C. Delete Expired API Cache job
This only removes expired cache entries (based on TTL/expiration settings). It does not regenerate or update stale-but-still-valid cached responses after a price change.

Correct sequence after updating pricing:
Make the price change (Price List Entry, promotion, etc.).
(Recommended) Run Product Hierarchy Maintenance (if product structure/attributes changed) + Refresh Platform Cache.
Run Regenerate Cached API Records to update the DC API cache specifically for pricing/offer responses.

Reference
Salesforce Help: "Regenerate Cached API Records" — "Run this job after making changes to products, pricing, promotions, or rules that affect Digital Commerce API responses."
Trailhead: "Optimize Industries Cloud Cache Management" — Explicitly recommends Regenerate Cached API Records when prices or eligibility change but old values are still returned by DC APIs.