Summary:
The requirement specifies a house must have 1-5 rooms, exactly two bathrooms, and that rooms should be instantiated in the order: Living Room first, then Bedroom. In Constraint Modeling Language (CML), cardinality is defined with [min..max], so [1..5] is correct for rooms and [2] for bathrooms. The order keyword defines the sequence in which related components are created or listed. The correct script must have the cardinality [1..5] and the order (LivingRoom, Bedroom).

Correct Option:

B: type House {relation rooms : Room[1..5] order (LivingRoom, Bedroom);relation bathrooms : Bathroom [2];}type Room;type LivingRoom : Room;type Bedroom : Room;type Bathroom : Room;
This script correctly implements all requirements:

rooms : Room[1..5] enforces a minimum of 1 and a maximum of 5 rooms.

bathrooms : Bathroom [2] enforces exactly two bathrooms.

order (LivingRoom, Bedroom) ensures that when rooms are instantiated, a LivingRoom is created first, followed by a Bedroom.

The type definitions correctly establish the hierarchy (LivingRoom : Room, etc.).

Incorrect Option:

A: type House {relation rooms : Room[0..5] order (Bedroom, LivingRoom);relation bathrooms : Bathroom [2];}type Room;type LivingRoom : Room;type Bedroom : Room;type Bathroom : Room;
This script has two critical errors:

The cardinality for rooms is [0..5], which allows for zero rooms. This violates the requirement that the house must have at least one room.

The order is (Bedroom, LivingRoom), which would create a Bedroom first. This is the reverse of the required order, which is Living Room first.

Reference:

Salesforce Help: "Define Relationships in Constraint Modeling Language" - This documentation covers the syntax for defining relations, including cardinality (using [min..max]) and the order keyword for specifying the sequence of related components, confirming the structure used in Option B.

Summary:
In Salesforce Revenue Cloud, the Opportunity is primarily a sales tool used for tracking deals and forecasting revenue. When managing asset amendments, the amendment process—such as updating subscription terms, quantities, or product configurations—does not require an Opportunity to directly update the Asset. The system relies on quotes, orders, and asset actions to automate asset changes, allowing amendments to proceed independently of the Opportunity record.

Correct Option:

A — It is an optional record used for forecasting purposes and does not directly participate in the asset update automation
This is correct because the Opportunity serves reporting and forecasting purposes. Revenue Cloud automates asset updates through quotes, orders, and asset lifecycle management, so the Opportunity is not required for the automation of asset amendments. This separation ensures that sales processes remain flexible while asset updates are handled consistently.

Incorrect Options:

B — It directly updates the Asset record as soon as the opportunity stage is changed to Closed Won
This is incorrect because asset updates are not triggered by Opportunity stage changes. Only actions through quotes and orders affect the Asset lifecycle.

C — It is only required for amendments that involve a price increase
This is incorrect. While Opportunities may be referenced for sales tracking, amendments—including price increases—are still executed through quotes and asset management processes. The Opportunity is never strictly required for the amendment workflow.

Reference:
Salesforce Revenue Cloud Documentation → Asset Amendments, Opportunity Role in Asset Lifecycle, Quote and Order Automation.

Summary:
When a customer wants to renew a subscription after its term has officially expired, the standard renewal process (which would create a contiguous term) is no longer applicable. The recommended approach is to create a renewal opportunity but then override the default term dates. This allows the consultant to set a new, specific start date (February 1, 2026) that reflects the customer's intent, even though there is a gap between the original expiration date (December 31, 2025) and the new renewal start date.

Correct Option:

A: Use Override Renewal Term and provide the start date of February 1, 2026
This is the standard and recommended method for handling renewals with a gap in service. The "Override Renewal Term" feature on the renewal quote allows you to manually set the start and end dates for the new term.

By setting the start date to February 1, 2026, the system will correctly generate a new contract and asset for that period, acknowledging the lapse in the previous subscription. This maintains the asset lineage correctly while accommodating the real-world scenario.

Incorrect Option:

B: Add the same asset as a new line on the renewal quote with a start date of February 1, 2026.
This is incorrect and would likely result in an error or a duplicate asset. The original asset is already present on the renewal quote as the source for the renewal. Manually adding it again would conflict with the standard renewal process and is not the supported method for adjusting dates.

C: Start a new initial sale with the same asset with a start date of February 1, 2026.
This is not the recommended practice. Creating a brand new initial sale severs the historical link to the original asset. This would break the asset lifecycle, make reporting on customer tenure inaccurate, and is not how renewal business is typically tracked in Revenue Cloud.

Reference:
Salesforce Help: "Renew a Subscription" - The documentation for the renewal process explains the ability to override the renewal term dates on the quote, which is the prescribed method for starting a renewal after a subscription has lapsed or for setting a non-standard start date.

Summary:
The final price is calculated by applying discounts sequentially to the adjusted price. The process starts with the list price, applies overrides, then discounts. The attribute-based price override sets the new base price to $12,000. The $1,000 bundle adjustment is a fixed-amount discount, reducing the price to $11,000. Finally, the 10% manual discount is applied to this amount ($11,000 * 10% = $1,100), resulting in a final net price of $11,000 - $1,100 = $9,900.

Correct Option:

A: $9,900
Step 1: Start with List Price: $15,000

Step 2: Apply Attribute Override: The price becomes $12,000.

Step 3: Apply Bundle Discount ($1,000): $12,000 - $1,000 = $11,000.

Step 4: Apply 10% Manual Discount: 10% of $11,000 is $1,100. $11,000 - $1,100 = $9,900.

The Net Price column in the Transaction Line Editor reflects this final calculated amount after all adjustments.

Incorrect Option:

B: $9,500
This miscalculation might result from applying the 10% discount to the original list price ($15,000 - $1,500 = $13,500) and then subtracting the fixed discounts ($13,500 - $1,000 - ???), or from an incorrect order of operations. The correct, sequential application of adjustments does not yield $9,500.

C: $1,800
This is a completely implausible result. It suggests a massive, incorrect discount was applied (e.g., 10% of $15,000 is $1,500, and then subtracting the other discounts). It does not follow the logical sequence of price overrides and discounts from the provided data.

Reference:
Salesforce Help: "How Salesforce CPQ Calculates Prices" - This documentation outlines the order of operations for price calculations, confirming that price overrides are applied first, followed by discount adjustments, which aligns with the sequential calculation used to arrive at $9,900.

Summary:
In Salesforce Revenue Cloud, Billing Treatment determines how and when a customer is billed for subscription products, such as in advance or in arrears. Billing Treatment can be assigned at both the Product Level and Order Product Level. When conflicting configurations exist, Revenue Cloud resolves the effective billing behavior by prioritizing the more specific configuration to ensure accurate billing according to the most granular setting applied to the order.

Option: B — Billing Treatment at the Order Product level overrides the Product Level Billing Treatment
This is correct because Order Product-level settings are more granular and specific than Product-level defaults. If a Billing Treatment is configured at the order product level, it takes precedence over the product-level setting, ensuring that the billing behavior for that particular order adheres to the desired terms, even if the product default differs.

Incorrect Options:

A — Billing Treatment resolution always prefers the Product Level over the Order Product level
This is incorrect because the system gives precedence to the more specific Order Product-level setting rather than the general Product-level default.

C — Billing Treatments are only evaluated when no Legal Entity is defined
This is incorrect. Billing Treatments are always evaluated based on their configuration and scope, independent of whether a Legal Entity is defined.

Reference:
Salesforce Revenue Cloud Documentation → Billing Treatment, Order Product Overrides, Subscription Billing Configuration.