Salesforce Marketing Cloud Administrator common mistakes
Salesforce Marketing Cloud Administrator · Understand the traps and how to avoid them.
When a scenario describes a new sending domain failing authentication or reply-handling problems, the candidate picks "purchase a dedicated IP" as the remedy instead of configuring a Sender Authentication Package.
Both features live under Setup/Admin and are marketed together as deliverability tools, so candidates collapse them into a single "deliverability" concept and pattern-match on the word rather than on the described symptom.
What to do instead
Learn the split function: an SAP authenticates the sending domain, configures account-level authentication (SPF/DKIM via a private/purchased domain) and enables reply mail management, while a dedicated IP isolates sending reputation from other senders. Before answering, restate the symptom (domain not authenticated vs. reputation pooling) and map it to exactly one of the two.
To give one user extra access, the candidate edits the role that user already holds, silently changing permissions for every other user in that role.
The Roles screen sits next to the User screen in Setup, roles look like per-user groups, and the exam stem rarely says the role is shared, so editing the role feels like the direct fix.
What to do instead
Decide first whether the change is for one user or for a job function: one user gets a permission set assigned to them alone (mapped permissions are additive on top of the role), and only a whole job function gets a role edit. Check whether the stem says "only this user" or "all users in this role" before choosing.
The candidate assumes a data extension, list, email, journey, or subscriber record created in one Business Unit is visible and usable from a sibling Business Unit in the same Enterprise account.
The Enterprise account shows one login and a single Business Unit switcher, so the UI looks like one shared workspace even though data is partitioned per Business Unit.
What to do instead
Memorize the isolation list: subscribers/All Subscribers, lists, data extensions, content, journeys, automations and tracking data are per-Business Unit. Treat the Shared Data Extensions folder (Enterprise accounts, requires explicit permission) as the narrow exception, and reject any answer that relies on data silently flowing between sibling BUs.
To resolve a complaint or an opt-out scenario, the candidate answers "delete the subscriber record from the sendable data extension" or "delete them from All Subscribers."
Delete is the most visible row-level action in the UI and reads as the cleanest way to "remove" a person, and deleting does immediately stop future sends from that one audience.
What to do instead
Fix the mental model: deletion is a data hygiene action, not a preference action. An opt-out or complaint requires the contact's status to become Unsubscribed or Held (in All Subscribers, or via a suppression list) so the status survives re-imports and applies to every send. Reject any answer where the only effect is removing the row, because the contact can be re-created as Active on the next import.
The candidate treats the Subscriber Key as interchangeable with the email address, or treats All Contacts and All Subscribers as the same list, and picks answers where changing the email address silently creates a new person or breaks opt-out history.
In a fresh account the Subscriber Key is often set to the email address, so the two look identical in every example, and both All Contacts and All Subscribers appear as "the list of people."
What to do instead
Anchor on the definitions: the Subscriber Key is the stable identifier a send relationship points at, and it must not change when the email address changes; All Subscribers is the email-channel subscription/status list, while All Contacts is the cross-channel Contact Builder record. When a stem mentions a changed email address, choose the answer that preserves the Subscriber Key so the existing status and history follow the person.
When a new long code or short code must capture and honor opt-outs, the candidate assumes STOP/HELP keywords and unsubscribe handling are created automatically with the code, or that only an opt-in keyword needs configuring.
Email unsubscribe behavior is largely automatic in Marketing Cloud, so candidates carry that assumption into MobileConnect, where keyword configuration is entirely manual per code.
What to do instead
Learn that MobileConnect keywords are created one by one per code, and that a working opt-out flow needs at minimum a response message, an opt-out keyword, a help keyword, and (for double opt-in) a confirmation message plus its confirmation response keyword, each mapped to the right action. If the stem asks what to configure for compliance, expect a list of several keywords, not one.
The candidate selects a plain standard data extension as a Journey Builder entry source, or assumes any data extension can be used as the audience without checking the send relationship.
The entry source picker lists data extensions by name with no visible warning, and the candidate's data extension was perfectly usable for SQL and imports, so it looks sendable.
What to do instead
Check for sendability before choosing: a data extension used as a contact-entry Journey source must be sendable, which means it has a send relationship tying a field to Subscriber Key and the required attributes. If the stem describes a non-sendable DE, the correct answer is to add the send relationship or route contacts through an API event or audience instead.
The candidate picks a Data Retention Policy as the fix when the requirement is to purge or limit records inside a data extension.
Data Retention Policy lives under Setup near the data management tools and has "data" in its name, so it reads as a global data-deletion setting.
What to do instead
Scope retention correctly: retention policies govern tracking and behavioral data (email, mobile, and related interaction data) and changes apply going forward, not retroactively to already-stored history. Data extension content is managed by scheduled automations using SQL or delete activities. Match the noun in the stem (tracking data vs. rows in a DE) to the tool.
The candidate sets up an API integration but omits the API Integration component with the required scopes in the installed package, or builds the package in one Business Unit and expects credentials to work in another.
The package screens are multi-step, the client ID and secret appear before scopes are confirmed, and installed packages sit at Business Unit level without an obvious warning in the UI.
What to do instead
Walk the package path in order: Package Manager, create package, add component, choose API Integration, choose Server-to-Server (not Web App) for a backend integration, select the exact scopes required, save, then install the package into the Business Unit that will make the calls. Verify the stem names the BU that owns the integration, because credentials from a package installed in a sibling BU will not authorize there.
The candidate assumes an unsubscribe link and a working preference page are on by default in every send, or confuses the Profile Center, Subscription Center and Preference Center when asked where subscribers manage list membership.
The three centers have overlapping names and all appear as "preference" options, and the candidate has seen unsubscribe links in live emails without knowing they were configured.
What to do instead
Separate them by function: Profile Center updates profile attributes, Subscription Center manages list and publication membership, and Preference Center combines both. These are configured in Setup and surfaced in the email through the corresponding personalization strings, and the footer/links are driven by the Delivery Profile and Send Classification rather than appearing automatically. Map the stem's requirement (change attributes vs. manage list membership vs. both) to exactly one center.