Media-Cloud-Consultant Practice Test Questions (2026)

Explanation:

In Salesforce Experience Cloud, when using page variations to display customized content (such as an OmniScript) to a specific subset of partner users, visibility issues often stem from configuration steps related to publishing, component versioning, and audience targeting.

B. Validate that the page variation is published — Page variations must be explicitly published in Experience Builder for changes to take effect on the live site. Unpublished variations remain in draft and are not visible to users.

C. Validate that the latest version of the omniscript is enabled — OmniScripts are versioned components; if an older version is active or cached, updates (or the script itself) may not appear. Activating the latest version ensures the current OmniScript renders.

E. Validate that the audience for the page variation is correctly defined as assigned — Audiences determine which users see a specific page variation. Incorrect criteria, missing assignments, or misconfigured audience rules prevent the targeted subgroup from viewing the variation.

Why the other options are incorrect:

A — This applies to FlexCards (which require specific publish targets like "Community Page" and "Community Default" for visibility in Experience Cloud). OmniScripts do not use the same activation targets and render directly as components without this requirement.

D — While OmniStudio runtime permissions are needed for partner users to execute OmniScripts in Experience Cloud, the "MediaCloudCCRuntime" permission set license is specific to certain Media Cloud contexts and not the standard requirement here. General OmniStudio runtime access (via permission sets) is typically configured separately, but the issue described is about page variation visibility, not script execution failure.

References:
Salesforce Experience Cloud documentation on audiences and page variations emphasizes publishing variations, assigning audiences correctly, and handling component versioning for visibility:

Experience Builder audience targeting and page variations (Trailhead: Personalize Experience Cloud Sites with Audience Targeting).

OmniStudio documentation notes that active/latest versions of components must be used in sites, with caching/publishing steps required after updates. Media Cloud leverages standard OmniStudio behaviors in partner portals without deviating from these core troubleshooting steps.

Explanation:

In Salesforce, when you need to grant access to records automatically based on a field value (like a status change), a Criteria-Based Sharing Rule is the most efficient, "minimal customization" approach.

How it works: You can define a rule on the Order object that says: "If Opportunity Status equals 'Closed Won', share this record with the 'Operations Team' Public Group."

Read/Write Access: The rule can specifically grant Read/Write access, allowing the operations team to perform the "Create and Submit Order" action.

Ownership Preservation: This solution allows the Sales Reps to remain the owners of the records, satisfying the reporting requirement.

Automation: Unlike manual sharing, this happens automatically the moment the criteria are met.

Incorrect Answers

A. Configure role hierarchy: While putting Operations above Sales in the hierarchy would give them access, it would give them access to all records (Draft, In Progress, etc.) at all times. The requirement specifically states they should only have access when the status is "Closed Won."

B. Share order records programmatically using Apex: While Apex sharing is powerful, it is considered "high customization." Salesforce best practices dictate using declarative features (Sharing Rules) before resorting to code.

C. Sales users will use manual sharing: This is prone to human error. Sales reps might forget to share the record, which would delay the operations process. It is not a scalable or "automated" solution.

References
Salesforce Help: Criteria-Based Sharing Rules
Salesforce Help: Sharing Considerations
Trailhead: Data Security - Use Sharing Rules

Explanation:

When integrating Media Plans with external ad servers (e.g., Google Ad Manager), some interactions must be bi-directional synchronous interfaces because they require immediate confirmation before proceeding:

Activate campaign in ad server (A) → This must be synchronous because ASM needs an immediate response from the ad server to confirm that the campaign has been successfully activated. Without synchronous confirmation, the campaign status could be inconsistent between ASM and the ad server.

Check ad inventory in ad server (D) → This is also synchronous because inventory availability must be validated in real time. Sellers need instant confirmation of whether requested placements are available before finalizing the media plan.

❌ Why not the others?

B. Campaign reporting from ad server → Reporting is asynchronous; data is typically pulled in batches or scheduled jobs, not in real-time synchronous calls.

C. Campaign performance feed to CPQ → Performance metrics are ingested asynchronously (via feeds or scheduled updates) since they don’t require immediate confirmation during transactional processes.

🔗 Reference:
Salesforce Help: Media Cloud → Advertising Sales Management → Ad Server Integration.
It specifies that campaign activation and inventory checks are synchronous, while reporting and performance feeds are asynchronous.

Explanation:

The Ad Ops (Advertising Operations) persona is a core user in the Advertising Sales Management (ASM) lifecycle. This role is responsible for the post-sale, fulfillment, and trafficking tasks—such as sending approved orders to the ad server, monitoring delivery, and managing creative assets. Their permission sets must grant them operational access to execute these tasks within the Media Cloud application, without giving them administrative design rights.

B. MediaCloudRuntime: This is the key operational permission set for the Ad Ops persona. It grants the runtime permissions needed to perform day-to-day trafficking and operational tasks within the ASM module, such as executing the "Activate" action to send campaigns to the ad server, viewing order details, and managing line items. It provides the necessary access without the design/configuration privileges of an admin set.

C. Media Cloud Base User: This is the foundational license permission set required for any Media Cloud user to access the application, its tabs, and core objects. It is non-negotiable and must be assigned first.

Why the other options are incorrect:

A. OmniStudioAdmin: This is an administrative permission set for users who design, build, and configure OmniStudio components (OmniScripts, DataRaptors, FlexCards). This is not appropriate for an Ad Ops user who only needs to use the pre-built processes and interfaces. This is for developers or solution architects.

D. OmniStudioUser: While often required for Sales Representatives who run guided selling OmniScripts (like "Create Media Plan"), the Ad Ops role's primary interaction is with the operational aspects of the Order and its integration with the ad server, not with the front-end quoting OmniScripts. The MediaCloudRuntime set is more specific and critical for their duties. OmniStudioUser might be included in some configurations, but the question asks for the two managed permission sets that should be added, and the definitive pair for the operational Ad Ops role is Media Cloud Base User (license) + MediaCloudRuntime (operational rights).

Key Concepts: Media Cloud Personas, Permission Set Strategy, Ad Ops (Advertising Operations) Role. The Ad Ops user needs the base license (Media Cloud Base User) and the runtime permissions to fulfill orders (MediaCloudRuntime).

References: Salesforce Media Cloud implementation guides and permission set matrices specifically define Media Cloud Base User as the prerequisite and MediaCloudRuntime as a core set for operational teams like Ad Ops, distinguishing it from sales (MediaCloudSales) or administrative (MediaCloudAdmin) sets.

Explanation:

The key clue is: “Certain core components have been moved to the Media Service on the core platform to ensure easier upgrades.” In this model, the managed package primarily delivers the upgradeable “core app” assets—i.e., the components that are typically packaged and versioned cleanly:

Apex classes (server-side logic)
Lightning Web Components (UI components)
APIs / CPQ APIs (integration + orchestration interfaces)
OmniScript definitions (Industries runtime/config assets that ship with the product)

Meanwhile, items like FlexiPages, layouts, labels, and some data-model/config metadata are commonly treated as org-level configuration/UI setup that Salesforce often ships outside the “core code payload” (or expects customers to adjust), which is why they’re not the best match for “delivered as part of the managed package” in this upgrade context.

Why the other options are incorrect

A includes “media service” itself + data model; that’s not typically described as a “managed package component set” in this context.

B includes “Velocity integration settings” and “custom layouts” — those are more like configuration artifacts than the core package payload.

C mixes OmniScript + CPQ APIs with FlexiPages, which doesn’t align with the “core package moved to media service” concept the question is testing.

References:
Multiple Media Cloud Consultant exam practice sources documenting this exact Winter ’22 → Spring ’22 ASM upgrade question list D as the correct set of managed package components.

Salesforce Developer Docs (general): Packageable components in managed packages include items like Apex classes and Lightning Web Components, supporting why “Apex + LWC + core app artifacts” are the most realistic “managed package delivered” set.

Explanation:

In Salesforce Media Cloud's Advertising Sales Management (ASM), document generation (DocGen) for proposals, insertion orders, and other ad sales documents requires specific managed permission sets from the Industries Document Generation package tailored for Communications, Media, and Entertainment (CME).

A. DocGenInd CME Designer User — This permission set allows users to create and edit document templates (designer access for building and maintaining templates).
B. DocGenInd CME Runtime User — This permission set enables users to generate documents from existing templates (runtime execution for producing PDFs or other outputs in workflows).

These two sets together provide the full capability for both template management and document generation.

Why the other options are incorrect:

C. DocGenInd CME Digital Experience User — This is for external/partner users in Experience Cloud sites to generate documents, not for internal users needing template creation/editing.
D. MediaCloudPlus Runtime — This provides general runtime access for Media Cloud features but does not include specific DocGen permissions for template design or generation.

References:
Industries Document Generation in Media Cloud uses CME-specific permission sets (DocGenInd CME variants) for designer and runtime roles, as aligned with Salesforce Industries CME documentation patterns for CLM/DocGen in Communications, Media, and Entertainment clouds. Post-install steps for Industries packages require assigning these layered permission sets for full DocGen functionality.

Explanation:

This question tests knowledge of the Salesforce Industries CPQ (Communications, Media, & Energy) API, which is the engine behind product configuration and pricing in Media Cloud.

The priceCart API method is specifically designed to execute the pricing plan associated with a cart (or quote). When called, it takes the configured items in the cart, applies all relevant pricing rules, adjustments, discounts, and charges defined in the "out-of-the-box pricing plan," and returns the calculated pricing information (e.g., line totals, monthly recurring charges, one-time charges) back to the caller.

This is the method used to trigger the pricing calculation and get the results, which is exactly what the question describes.

Why the other options are incorrect:

B. putCartsItems / C. postCartsItems:
These methods are for adding, updating, or removing items (CartsItems) from the cart. They modify the cart's composition but do not trigger or return the final pricing calculation. Pricing is typically invoked after these operations.

D. createCart:
This method is for initializing a new cart/quote object. It sets up the cart structure but does not involve pricing calculations.

Key Concepts:
Industries CPQ API, Pricing Calculation, Integration Procedures (IPs). The standard flow is to build a cart (createCart, postCartsItems) and then call priceCart to run the pricing engine and get the final price results.

References:
This is a fundamental aspect of the Vlocity/OmniStudio CPQ architecture. The priceCart method is documented as the primary API for invoking pricing logic and returning price details. Integration Procedures that need to fetch calculated prices will call this method.

Explanation:

In the Salesforce Media Cloud architecture, while Industries CPQ handles the "commercial" side of the deal (pricing and quoting), Industries Order Management (IOM) is the engine designed for "technical" fulfillment and external system integration.

Order Orchestration: IOM uses Orchestration Plans composed of Orchestration Items. To integrate with a custom ad server, a consultant would create an Orchestration Item of the type "Callout."

System Interface: Within IOM, you define a System Interface and a System Record that point to the external ad server’s API endpoint.

Separation of Concerns: This approach is superior to custom Apex because IOM natively handles retries, error handling, and state management. If the ad server is temporarily down, IOM will queue the order and retry automatically based on defined policies, ensuring the integration is resilient.

Workflow: When a media plan is "accepted," a Quote-to-Order process triggers. The resulting Order is then "decomposed" by IOM into fulfillment requests that are sent to the ad server via the custom Callout orchestration item.

Incorrect Answers

A. Custom Apex: While you could write Apex to call an API, it is considered a high-maintenance "anti-pattern" in Media Cloud if not used as a last resort. Apex does not natively provide the visual tracking, decomposition, or automated retry logic that comes out-of-the-box with Industries Order Management.

B. Industries CPQ: CPQ is used for Configuring, Pricing, and Quoting. Its job ends once the order is captured. It is not designed to manage the long-running downstream fulfillment tasks or the "handshake" logic required to activate a campaign in an ad server.

D. Flow Builder: While Salesforce Flow can handle simple integrations, it lacks the complex Decomposition and Orchestration capabilities required for advertising orders, which often involve multiple line items that may need to be activated or updated at different times.

References
Salesforce Help: Industries Order Management Orchestration
Salesforce Help: Create a System Interface for Integration
Trailhead: Order Management Overview

Explanation:

In Media Cloud (Advertising Sales Management), when building a linear TV media plan, the TV program / TV content is represented using an Ad Space Specification. This object is used to define the inventory specification for TV ad placements (the “what/where” the ad runs), and it’s explicitly required when setting up TV ad products and selecting inventory for TV placements.

Salesforce documentation for setting up TV ad products states you must create an Ad Space Specification record for your TV content.

When adding TV placements to a media plan, users select the channel and the ad space specification, indicating the program-level inventory is chosen via Ad Space Specification, not the placement itself or the creative.

Why the other options are incorrect

A. Media channel — Media Channel is the broader distribution/container (e.g., TV channel/network), but the specific program inventory spec is handled via Ad Space Specification.

C. Ad creative — This is the creative asset (the ad), not the program/inventory definition.

D. Media plan placements — Placements represent the planned/booked spots, but the program definition comes from selecting the relevant Ad Space Specification.

References:
Salesforce Help: Set Up TV Ad Products — requires creating an Ad Space Specification record for TV content.

Salesforce Help: Add TV Placements to Your Media Plan — instructs selecting channel and ad space specification when building TV placements.

Explanation:

The question is straightforward: The advertisement is for a particular TV channel. This describes Linear Television advertising.

Linear TV refers to traditional, scheduled television programming where content is broadcast at a specific time on a specific channel, and viewers watch it as it airs (or via DVR). Advertising purchased on a specific TV channel for a scheduled program is the classic example of Linear media.

Why the other options are incorrect:

A. Out of Home (OOH): This refers to advertising outside the home, such as billboards, transit ads, or digital signage. It is not television.
C. Print: This refers to physical printed media like newspapers, magazines, or flyers.
D. Digital: This refers to online advertising (display ads, social media, streaming video/audio). While a TV channel might have a digital streaming presence, the question specifically says "on a particular tv channel," which is the defining attribute of the Linear channel type in media planning.

Key Concepts: Media Cloud Channel Types, Linear Television. In Media Cloud's classification, "Linear" encompasses traditional broadcast and cable TV inventory.

References:
This is basic media industry terminology. Salesforce Media Cloud's channel model includes "Linear" as a primary channel for TV and radio advertising sold based on scheduled airtime.