MCE-Con-201 Salesforce Certified Marketing Cloud Engagement Consultant Exam Topics and Questions

Discovery and Architecture sets the tone for everything that follows. Before you can recommend a solution, you need to know what questions to ask, and the exam tests exactly that instinct. This topic rewards candidates who understand that a half-specified requirement produces a half-working implementation. Expect to be put in a consultant's seat, handed an incomplete brief, and asked to identify what is still missing before any build decisions are made.

How Discovery and Architecture is tested

At 16%, this topic carries enough weight to shift your overall score meaningfully. Items place you inside a client scenario, give you a partial set of requirements, and ask what you still need to know or what solution fits the constraints you have been given. The traps are specific. One is moving to a tool recommendation before the data picture is clear. Another is defaulting to the most technically capable option when the customer's team cannot sustain it. Items reward matching the solution's complexity to the team that will own it long-term, not to what Marketing Cloud can theoretically do. A third trap is treating all requirements as equally settled: the exam distinguishes between requirements that are confirmed and gaps that need a follow-up question. Candidates who read the scenario carefully and resist the urge to fill in missing details from their own assumptions consistently outperform those who jump to architecture before the discovery is complete.

Where Discovery establishes what a customer needs, Integration determines how Marketing Cloud connects to the wider Salesforce ecosystem to deliver it. At 20%, this is one of the two heaviest topics on the exam. The cost here is in the details: candidates who know that a feature exists but cannot distinguish its constraints from those of a similar option will lose marks on scenarios that hinge on exactly that difference.

How Integration is tested

Items in this topic present a customer use case and ask you to select the right connector, extension product, or data model approach. The weight of 20% means you will see enough of these to feel the pattern if you are underprepared. Marketing Cloud Connect questions tend to test its boundaries: what it does in a multi-org environment, what breaks when configuration is wrong, and how you would isolate the fault. Extension product questions follow a similar shape: the scenario describes a requirement and you must match it to the product that actually addresses it, not the one that sounds closest. The data model sub-topic is the quieter trap. Items here reward understanding how subscriber identity and relationship structure affect what personalisation is possible downstream. Candidates lose marks by treating the data model as a storage question rather than a messaging enablement question. Read use cases for the outcome the customer is trying to achieve, then work backwards to the integration choice that supports it.

Account Configuration sits at 12% and covers the structural and operational decisions that underpin how a Marketing Cloud instance actually runs. The subject matter is less visible than journeys or data models, which is exactly why candidates underestimate it. Errors in account hierarchy, sender authentication, or reply mail handling do not announce themselves during a build; they surface later as deliverability problems or compliance gaps. The exam rewards knowing these failure modes before they happen.

– Account hierarchy and business unit design

The hierarchy question is deceptively simple on the surface: parent account or business unit? In practice, the exam presents scenarios where the wrong choice creates either excessive administrative overhead or an inability to share assets correctly across units. You need to know which sharing behaviours are controlled at the parent level and which are set per business unit, because the scenario will include a constraint that makes one option clearly unworkable. Sender Authentication Package questions follow a similar logic. SAP is not just a deliverability upgrade; applying it to a business unit changes link behaviour, from-address handling, and the scope of authenticated sending. Items test whether you understand the operational impact of that change on a unit that already has sends in flight, not just what SAP does in the abstract.

– Reply Mail Management and Mobile Studio

Reply Mail Management scenarios tend to involve something going wrong: replies routing incorrectly, unsubscribes not being honoured, or auto-replies creating loops. The exam asks you to identify what configuration choice caused the issue and what change resolves it. This is a troubleshooting framing, so knowing the feature at a conceptual level is not enough; you need to know the specific settings that govern each behaviour. Mobile Studio questions cover features and troubleshooting across SMS and push channels. Expect to be asked which capability fits a described mobile use case, or to identify why a mobile send is not behaving as expected. The trap is applying email-channel logic to mobile scenarios: the permission model, opt-out mechanics, and message structure differ enough that assumptions borrowed from email will produce wrong answers.

How Account Configuration is tested

At 12%, Account Configuration contributes a meaningful slice of your score without dominating the exam. Items are mostly scenario-based: a described business structure, a reported problem, or a proposed configuration change. What the exam rewards is the ability to trace a consequence. If a business unit has SAP applied, what changes for senders in that unit? If Reply Mail Management is configured a particular way, which reply types does that setting handle and which does it miss? Candidates lose marks here by treating configuration choices as interchangeable options rather than decisions with downstream effects. The Mobile Studio questions add a channel-specific layer: items test whether you know where mobile configuration differs from email configuration, not just that it exists. The overall pattern across this topic is that every question has a business context. Reading that context carefully, rather than jumping to the most technically correct-sounding option, is what separates the candidates who score well from those who know the features but miss the scenario detail.

Automation shares the top weight of 20% with Integration, and the two topics demand different thinking. Integration asks which tool fits the requirement; Automation asks how to build the right process with the tools already in scope. Journey Builder and Automation Studio each have a distinct operational model, and the exam is built around scenarios where choosing between them, or combining them incorrectly, produces a solution that fails in a specific and avoidable way.

How Automation is tested

The 20% weight means Automation questions will appear frequently enough that a systematic gap in your understanding will show up in your score. Items split between two demands. The first is classification: given a described business process, identify the correct automation type and the specific activities it should use. The second is design: given a more complex requirement, construct the logic across Journey Builder and Automation Studio that satisfies it. The classification questions catch candidates who know both tools but have not internalised when each one is the right choice. Journey Builder and Automation Studio overlap in ways that make the decision feel arbitrary until you understand the contact-entry model and the data-trigger model that separates them. The design questions are harder. They reward candidates who can hold a multi-step process in mind and identify where a handoff between tools is necessary, or where a single-tool approach breaks down. The trap in both question types is over-engineering: the exam rewards the solution that is correct and maintainable, not the most elaborate one available.

Data Modeling and Management is the heaviest topic on the exam at 21%, and it earns that weight. Every personalisation decision, every segmentation strategy, and every reporting output depends on choices made here. The exam does not test data modeling in the abstract; it tests whether you can look at a described customer scenario and identify which data object, which contact identity approach, or which reporting mechanism fits it, and why the alternatives do not.

– Reporting tools and when to use each

Standard reports, data views, and tracking extracts each serve a different purpose, and the exam expects you to know the boundary between them. Standard reports are the right choice when the metric exists in the out-of-the-box report library and no custom logic is needed. Data views give you SQL access to system-generated engagement data that standard reports cannot expose. Tracking extracts move data out of Marketing Cloud for processing elsewhere. The scenario will include a constraint, such as a required field that standard reports do not surface, or a downstream system that needs raw send data, and your job is to match that constraint to the right mechanism. Candidates who treat all three as equivalent ways to get reporting data will miss the specific detail that makes one option correct and the others wrong in context.

– Data objects and the Marketing Cloud data model

Marketing Cloud has several data objects: lists, data extensions, shared data extensions, publication lists, suppression lists, and the subscriber object itself. The exam tests whether you understand the functional difference between them, not just their names. Data extensions are more flexible than lists, but that flexibility comes with configuration decisions around the primary key, the sendable field, and the relationship to the All Subscribers list. Items will describe a data requirement and ask which object structure supports it. The trap is defaulting to data extensions for everything: some scenarios call for a list-based approach, and others require a specific combination of objects. Knowing when a suppression list is the right tool versus a query-based exclusion, for example, is the kind of distinction the exam rewards.

– Contact identity and its downstream effects

Contact identity is where data modeling decisions become irreversible in practice, and the exam reflects that. Choosing the wrong contact key or subscriber key structure creates problems that are expensive to fix after launch: duplicate contacts, broken journey re-entry logic, and suppression records that do not match across channels. Items in this area ask you to evaluate a proposed identity approach against a described scenario and identify the implication of that choice. The key skill is tracing the consequence: what happens to deduplication, to unsubscribe handling, and to cross-channel contact resolution when a particular identity field is used as the primary key? Candidates who see identity as a setup task rather than a design decision lose marks on these questions consistently.

How Data Modeling and Management is tested

At 21%, this topic will define your result more than any other. Items are scenario-heavy and consequence-focused. The exam does not ask you to define a data extension; it asks you to evaluate whether a proposed data model supports a described personalisation or segmentation requirement. The reporting questions follow the same pattern: the scenario includes a specific output requirement, and the item tests whether you can identify which tool produces it. Candidates lose marks by selecting the most capable tool rather than the most appropriate one for the constraint given. Contact identity questions are the most unforgiving. The exam rewards candidates who understand that identity decisions affect every downstream process: journey entry, suppression, channel resolution, and reporting. A candidate who knows the mechanics of each data object but has not thought through the cross-object implications of identity choice will find these items difficult. Work through varied scenarios, not just feature definitions, to build the judgment this topic demands.

After the structural depth of Data Modeling, Messaging brings the focus to the subscriber-facing output: what the customer actually receives and how it is shaped. At 11%, this is the lightest topic on the exam, but light weight does not mean easy marks. The two sub-topics cover a broad surface area, from content individualisation techniques to channel selection, and the exam expects you to apply both with precision against a described scenario.

How Messaging is tested

Items in this topic split between content and channel. On the content side, the exam tests your knowledge of individualisation techniques: AMPscript, dynamic content, personalisation strings, and content blocks each have a scope and a use case, and scenarios will include a requirement that makes one approach more appropriate than the others. The trap is reaching for AMPscript when a simpler mechanism solves the problem, or assuming dynamic content rules can handle logic that actually requires scripting. On the channel side, items describe a customer scenario and ask which messaging option fits it. Email, SMS, push, and in-app messages have different permission models, different timing constraints, and different content limitations. The exam rewards candidates who match the channel to the described requirement rather than defaulting to email. Candidates lose marks by treating channel selection as a preference question: in the scenarios given, one option is clearly supported by the constraints and the others are not. Read the scenario for the constraint before evaluating the options.