Summary:
This scenario describes a bundle with two components that have different scaling behaviors. The VPN License quantity should scale directly with the number of bundles purchased (5 licenses per bundle). The Classroom Training should be included only once, no matter how many bundles are purchased. In Revenue Cloud, this is controlled by the Quantity Scaling Method on the bundle's component lines. "Proportional" scaling multiplies the component quantity by the bundle quantity, while "Constant" scaling keeps the component quantity fixed.

Correct Option:

C: VPN License = Proportional, Classroom Training = Constant
VPN License (Proportional): Setting this to "Proportional" means that if a customer buys 2 bundles, the quantity of VPN Licenses becomes 5 (default) * 2 (bundle quantity) = 10. This correctly scales the licenses with the bundle purchase.

Classroom Training (Constant): Setting this to "Constant" means that even if the customer buys 2 bundles, the quantity of Classroom Training remains 1. The customer receives the training only once, fulfilling the requirement.

Incorrect Option:

A: VPN License = Proportional, Classroom Training = None
This is incorrect because "None" is not a standard Quantity Scaling Method. The correct method for a component that should not scale is "Constant."

B: VPN License = None, Classroom Training = Proportional
This is incorrect and reverses the logic. Setting the VPN License to "None" (an invalid option) or any non-proportional method would prevent it from scaling, resulting in only 5 licenses even if 2 bundles are purchased. Setting the training to "Proportional" would cause it to scale, giving the customer 2 training sessions, which violates the requirement.

Reference:
Salesforce Help: "Quantity Scaling for Bundle Components" - This documentation explains the Proportional and Constant scaling methods. Proportional means the component quantity is multiplied by the bundle quantity, and Constant means the component quantity remains the same regardless of the bundle quantity, which directly maps to the requirements for the VPN and Training components, respectively.

Summary:
Universal Containers wants to ensure that bulk discounts are only applied when selling to business customers and never to individual consumers. In Revenue Cloud, Volume-Based Pricing automatically applies discounts when quantities meet certain thresholds. To control who receives these discounts, Salesforce provides Sales Transaction Type, which allows the system to differentiate between B2B and B2C deals. By leveraging this field, the consultant can ensure bulk discounts only apply when the transaction is tagged as a business sale.

Correct Option:

B — By using Sales Transaction Type and Volume-Based Pricing
Sales Transaction Type is designed to categorize different types of sales motions such as B2B, B2C, renewal, amendment, or channel sales. By associating Volume-Based Pricing rules with a specific Sales Transaction Type—for example, “Business”—the system applies bulk discounts only when the quote belongs to a business customer. This ensures clean separation of pricing logic, prevents consumer buyers from receiving unintended discounts, and keeps the configuration scalable as sales channels expand.

Incorrect Option:

A — By using Quote Transaction Type and Volume-Based Pricing
Quote Transaction Type is not suitable for separating business customers from consumer buyers. It is typically used to categorize quotes based on purpose, such as New, Amendment, or Renewal. Since it does not inherently differentiate between B2B and B2C customers, it cannot reliably prevent volume-based discounts from being applied to consumer quotes, making it ineffective for this requirement.

C — By using Order Transaction Type and Volume-Based Pricing
Order Transaction Type occurs too late in the process to control discount application. By the time an order is created, all pricing and discount calculations have already been finalized at the quote stage. Using Order Transaction Type would not prevent discounts from applying earlier in the quote, which makes it an incorrect choice for controlling Volume-Based Pricing behavior.

Reference:
Salesforce Revenue Cloud Documentation — Sales Transaction Type Overview

Salesforce CPQ & Pricing Guide — Volume-Based Pricing & Conditional Pricing Configuration

Summary:
The requirement is to create a monthly installment price that varies based on two attributes: Memory and Contract Term. This is a classic use case for an Attribute-Based Price schedule, where the price is determined by the combination of selected attribute values. With 3 memory options and 2 contract term options, there are 3 x 2 = 6 unique combinations. The Attribute-Based Adjustments schedule must have a separate record to define the total price for each of these 6 combinations, which will then be divided equally over the term to calculate the monthly installment.

Correct Option:

A: 6
The number of required records is the product of the number of options for each attribute.

Memory Options: 128GB, 256GB, 512GB (3 options)

Contract Term Options: 12 months, 24 months (2 options)

Total Combinations: 3 memory options * 2 term options = 6 unique combinations.

The Attribute-Based Price schedule needs one record for each combination (e.g., 128GB/12mo, 128GB/24mo, 256GB/12mo, etc.) to specify the total price for that specific configuration.

Incorrect Option:

B: 3
This number is incorrect. It might represent only the number of memory options, ignoring the impact of the contract term. Each memory option can have a different price for a 12-month term versus a 24-month term, requiring separate records.

C: 5
This number is also incorrect. There is no logical basis in the scenario for 5 records. The systematic way to calculate the required records is to multiply the number of options for each price-impacting attribute, which definitively results in 6.

Reference:
Salesforce Help: "Define Attribute-Based Pricing" - This documentation explains that for attribute-based pricing, you create a price record for each combination of attribute values that results in a different price. With two attributes having multiple values, you must create a record for each permutation in the matrix.

Summary:
The customer's primary concern is ensuring a seamless transition for their existing subscription base to support critical Amendment and Renewal processes. The core of this functionality in Revenue Cloud revolves around the Asset and its related objects, which track the subscription's lifecycle, state, and history. Migrating just the product data is insufficient; the complete asset lineage, including its historical states and the actions that caused them, is essential to avoid business disruption for post-sales operations.

Correct Option:

Option A: Asset, Asset Action, Asset State Period, Asset Action Source
This is the correct set of objects. These are the fundamental objects that represent the installed base and its lifecycle in Revenue Cloud.

Asset: Represents the active subscription itself.

Asset State Period: Tracks the history of the asset's state (e.g., quantity, term) over time, which is critical for amendments and proration.

Asset Action & Asset Action Source: Log the events (like activations and amendments) that caused changes to the asset, preserving the audit trail and business logic for future renewals.

Incorrect Option:

B: Asset, Subscription, Subscribed Asset, Order
This is incorrect. "Subscription" and "Subscribed Asset" are not standard primary objects in the Revenue Cloud (CPQ/Billing) data model for representing the install base. The core object is the Asset (with HasLifecycleManagement = true), and its related objects are Asset State Period and Asset Action.

C: Quote, Quote Line, Order, Order Product
These objects represent the sales process that leads to the creation of an asset. However, for migrating an existing install base, the focus must be on the assets themselves and their state history, not the historical sales transactions that created them (which may not even be in Salesforce).

Reference:
Salesforce Help: "Asset State Periods" and "Asset Actions" - This documentation explains the relationship between Assets, Asset State Periods, and Asset Actions, emphasizing that they work together to represent the subscription lifecycle, which is the foundation for amendments and renewals. A successful migration must accurately map data into this structure.

Summary:
The requirement involves two key actions: 1) Defining a special price for a bundle that is different from the sum of its individual components, and 2) Applying conditional discounts on top of that bundle price. The Bundle-Based Price is the element used to set the specific price for the entire bundle. The Price Adjustment Matrix (PAM) is the tool used to apply conditional discounts (like customer segment or deal size) to any product, including bundles, making it the correct combination for this advanced pricing logic.

Correct Option:

B: Bundle-Based Price and Price Adjustment Matrix
Bundle-Based Price: This pricing element is used to define the specific price for the entire Premium Suite bundle, establishing the discounted price compared to the sum of its parts.

Price Adjustment Matrix (PAM): This is the powerful and flexible tool used to apply different discounts based on custom conditions (e.g., if "Account Type = Enterprise," then apply a 15% discount). The PAM can be configured to look up the appropriate discount for the bundle based on these conditions and apply it within the pricing procedure.

Incorrect Option:

A: Attribute-Based Price and Volume Discount
Attribute-Based Price is used to adjust the price of a configurable product based on selected attributes (e.g., more RAM costs more). Volume Discounts are based solely on the quantity of a single product ordered. Neither is designed to set a price for an entire bundle or to handle the complex conditional logic required.

C: Bundle-Based Price and Product Selling Model
While Bundle-Based Price is correct for the first part, the Product Selling Model defines how a product is sold (e.g., as a one-time charge, a subscription, or a consumption model). It does not define conditional discount logic. The Selling Model is a foundational setting, not a tool for applying dynamic discounts.

Reference:
Salesforce Help: "Bundle-Based Pricing" and "About the Price Adjustment Matrix" - These documents confirm that Bundle-Based Pricing sets the price for a bundle, and the Price Adjustment Matrix is used to apply conditional discounts to products, including bundles, based on defined criteria.