MKT-101 Build and Analyze Customer Journeys using Marketing Cloud Exam Topics and Questions

Marketing Cloud is a multi-studio platform, and the exam assumes you know which tool does what before you start building anything. The introduction covers the functional map: what Email Studio, Journey Builder, Automation Studio, Audience Builder and Contact Builder each handle, and where their boundaries sit. You also need to know where to find help when something breaks or behaves unexpectedly, because support channels and documentation structure are tested directly. This is orientation, but it is orientation that costs marks if you skip it.

How Introduction to Salesforce Marketing Cloud is tested

Questions present a business requirement or a technical problem and ask which studio or feature set handles it. The trap is choosing a tool that sounds plausible but operates one layer removed from the actual task. For example, selecting Automation Studio when the requirement is to design a triggered message flow, or picking Email Studio when the question describes audience segmentation. Another pattern tests your ability to locate the right support resource: whether a configuration issue belongs in help documentation, a case, or community forums. Candidates lose marks by conflating tools that share overlapping terminology but perform distinct functions, or by guessing at support workflows without knowing how Salesforce structures its help ecosystem.

Once you know what the platform does, you need to configure it so messages can leave the building. This topic covers account setup and the sending configuration that determines whether your emails reach an inbox or bounce before they start. You will work with business units, user roles, sender profiles, delivery profiles, and the authentication records that prove your domain is allowed to send on behalf of your organization. Miss a step here and your journey will build without error but fail silently at send time.

How Fundamentals of Administration is tested

Items present a sending failure or a permissions gap and ask what was misconfigured. The exam expects you to distinguish between sender authentication, delivery profiles, and user provisioning, because all three can block a send for different reasons. A common trap is selecting an answer that fixes the symptom but not the root cause: adding a user to a role when the real problem is missing SPF or DKIM records, or choosing a delivery profile adjustment when the sender profile is incomplete. Another pattern gives you a business unit structure and asks which configuration inherits and which must be set per unit. Candidates lose marks by assuming that default settings are sufficient, or by confusing the order in which authentication, profiles, and permissions must be applied.

Marketing Cloud runs on data extensions, not objects or tables in the CRM sense. You need to know how to collect contact data, structure it into extensions, segment it for targeting, and keep it synchronized when the source changes. This topic is where most journey failures start, because a missing field or a stale import breaks everything downstream. The exam tests your ability to design a data model that supports both one-time sends and automated journeys, and to recognize when segmentation logic will return the wrong audience.

– Building and populating data extensions

Data extensions are the contact storage layer. You define the schema, set primary keys, and decide whether the extension is sendable. The exam expects you to know when to use a sendable extension versus a non-sendable one, and what happens if you try to inject a journey from an extension that lacks a subscriber key. You also need to understand import activities: file sources, column mapping, overwrite versus update behavior, and what to do when a contact appears in multiple rows. A common mistake is building an extension with the right fields but the wrong relationship model, so segmentation returns duplicates or misses records entirely.

– Segmentation and synchronization

Segmentation pulls subsets of contacts using filters, SQL queries, or audience builder rules. The exam tests your ability to write filter logic that excludes the right people, and to recognize when a query will perform too slowly or return unexpected nulls. Synchronization keeps data extensions current when the source is Salesforce CRM or another integrated system. You need to know what synchronized data extensions can and cannot do, when they refresh, and how to troubleshoot a sync that runs but does not update records. Candidates lose marks by assuming that a filter applied at send time will catch data changes that happened after the audience was built, or by choosing a manual refresh when the scenario requires automation.

How Data management is tested

Questions describe a journey or send that fails to reach the intended audience, then ask what went wrong with the data model or segmentation logic. The exam expects you to identify whether the problem is in the extension schema, the import process, the filter criteria, or the sync timing. A frequent trap is selecting an answer that fixes the data after the fact when the real issue is that the extension was not sendable to begin with. Another pattern gives you a business requirement and asks which type of extension or segmentation method satisfies it, testing whether you know the constraints of each approach. Candidates lose marks by conflating filtered data extensions with SQL query activities, or by assuming that all synchronized data is available in real time.

With data in place, you build the message. This topic covers drafting email content, organizing assets in Content Builder, and creating reusable blocks and templates. You need to know how dynamic content works, when to use AMPscript versus a content block, and how to structure emails so they render correctly across clients. The exam assumes you can identify which content method solves a given personalization requirement, and that you understand the difference between a template, a content block, and a code snippet.

How Designing and creating email messages is tested

Items present a personalization requirement or a rendering problem and ask which content feature or method resolves it. The exam expects you to distinguish between dynamic content rules, AMPscript, and Guide Template Language, because each has different capabilities and constraints. A common trap is choosing AMPscript when the requirement can be met with a simpler dynamic content block, or selecting a content block when the logic requires a lookup function that only AMPscript supports. Another pattern describes a broken layout and asks what caused it: missing alt text, unsupported CSS, or a template structure that does not adapt to the data. Candidates lose marks by assuming that all email clients behave the same way, or by picking a content solution that works in the preview but fails in the live send.

Before you send, you test. After you send, you follow the rules that keep your domain off blocklists. This topic covers test sends, preview methods, seed lists, and the sending practices that affect deliverability: list hygiene, engagement tracking, suppression logic, and compliance with CAN-SPAM and GDPR. The exam expects you to know which test method reveals which problem, and to recognize the sending behaviors that damage sender reputation even when they are technically possible within the platform.

How Best practices for testing and delivering messages, as well as email marketing is tested

Questions describe a deliverability problem or a compliance gap and ask what caused it or how to prevent it. The exam expects you to identify whether the issue is a missing unsubscribe link, a suppression list that was not applied, a sending frequency that triggered spam filters, or a test method that did not catch a rendering error. A common trap is choosing an answer that tests content but not logic, or that checks rendering in one client when the problem occurs in another. Another pattern gives you a sending scenario and asks whether it complies with regulations, testing your knowledge of opt-in requirements, suppression timing, and footer mandates. Candidates lose marks by assuming that a successful send means deliverability is fine, or by confusing a test send with a production-ready validation.

Automation Studio and Journey Builder take manual sends and make them conditional, scheduled, or event-driven. Automation Studio handles batch tasks: imports, queries, file transfers, and sends that run on a clock. Journey Builder handles triggered, multi-step campaigns where the path depends on contact behavior. You need to know which tool handles which automation pattern, how to configure entry sources and decision splits, and how to test a journey without sending live messages. This is the topic where data, content, and logic converge, so a gap in any of the earlier areas will surface here as a failed journey.

– Automation Studio workflows

Automation Studio chains activities into workflows that run on a schedule or trigger. You define the sequence: import a file, run a query, send an email, transfer a report. The exam expects you to know how to configure each activity type, how to handle errors in the chain, and when to use a scheduled automation versus a triggered one. A common mistake is building a workflow that depends on a file being present at a fixed time, when the business requirement calls for a file-drop trigger. Another trap is assuming that activities within an automation run in parallel when they are actually sequential, so a slow query blocks everything downstream.

– Journey Builder and testing

Journey Builder manages contact flows: entry events, wait periods, decision splits, and sends. You need to know how to set entry criteria, what happens when a contact qualifies mid-journey, and how to configure goals and exits. The exam tests your ability to design a journey that handles re-entry correctly, and to recognize when a split condition will send contacts down the wrong path. Testing a journey means using test contacts and checking that each branch fires as expected. Candidates lose marks by launching a journey without validating the entry source, or by assuming that a journey will pause when the underlying data changes, when in fact the contact continues on the path determined at entry time.

How Marketing automation is tested

Questions present an automation or journey that does not behave as intended, then ask what was misconfigured. The exam expects you to distinguish between an Automation Studio scheduling error, a Journey Builder entry problem, a decision split that evaluates the wrong field, and a send activity that references a broken data extension. A frequent trap is choosing an answer that fixes the journey logic when the real problem is in the data source, or selecting a test method that checks content but not the contact flow. Another pattern describes a business requirement and asks which automation type satisfies it, testing whether you know when to use a scheduled automation, a file-drop trigger, or a journey entry event. Candidates lose marks by assuming that all automation failures are logic errors, when timing, data availability, and entry criteria are equally common causes.

After the send, you measure. This topic covers tracking metrics, interpreting engagement data, and generating reports that show whether a campaign met its goals. You need to know which metrics matter for deliverability versus engagement, how to read Email Studio tracking reports, and how to pull journey analytics that show where contacts dropped off. The exam expects you to diagnose performance problems by reading the data, not by guessing.

How Analysis and troubleshooting is tested

Questions present a set of metrics or a report excerpt and ask what the data indicates, or what action to take next. The exam expects you to distinguish between a deliverability issue, an engagement problem, and a data or configuration error. A common trap is interpreting a low open rate as a content problem when the real issue is sender reputation or a missing preheader. Another pattern gives you journey analytics and asks which step caused the drop-off, testing your ability to trace contact flow through decision splits and wait activities. Candidates lose marks by focusing on vanity metrics instead of actionable ones, or by recommending a content change when the data points to a technical failure like a broken link or a suppressed segment.

The final topic consolidates everything: data, content, automation, and analysis in a single scenario. You are asked to evaluate a complete campaign or journey, identify what will fail, and recommend the fix. This is not new material. It is a check that you can apply the earlier topics together, under the constraint of a multi-step requirement where one misconfiguration cascades into several failures. The exam uses this to separate candidates who know individual features from those who can build and troubleshoot end-to-end.

How Summary is tested

Questions describe a campaign or journey from setup through reporting and ask you to identify the error, the missing step, or the metric that reveals the problem. The exam expects you to trace the failure across domains: a data extension that was not sendable, a journey entry condition that excluded the wrong contacts, a suppression list that was not applied, or a report that shows a broken link. The trap is fixing one part of the scenario when the question asks for the root cause, or choosing an answer that addresses the symptom but leaves the underlying misconfiguration in place. Candidates lose marks by treating this as a review of definitions when it is actually a test of diagnostic reasoning under complexity.