Salesforce Marketing Cloud Engagement Foundations Practice Exam

Correct: A — A valid physical postal address. CAN-SPAM requires commercial emails to include the sender's physical mailing address, along with accurate header/subject lines and a working opt-out. It's one of the law's core, testable requirements.

Why not the others: a discount code (B) is a marketing choice, not a legal requirement — and a subject line that misleads about content actually violates CAN-SPAM; a recipient's purchase history (C) is unrelated to compliance and would raise privacy concerns rather than satisfy them.

Correct: B — A clear, affirmative opt-in with active consent. Consent-based (opt-in) lists are composed of people who actively chose to hear from you, which drives higher engagement and lower complaint rates — and it's what privacy regulations expect.

Why not the others: pre-checked boxes (A) are not valid affirmative consent under GDPR and erode trust; auto-adding all purchasers to every list (C) mixes transactional relationships with marketing consent and invites complaints and compliance risk.

Correct: A — Email Studio. Email Studio is the core application for creating, sending, and managing email in Marketing Cloud Engagement. Foundations expects you to know which Studio maps to which channel.

Why not the others: Advertising Studio (B) manages paid advertising audiences; Mobile Studio (C) handles SMS, push, and group messaging — both are cross-channel tools, not the email application.

Correct: B — Subscriber Key. The Subscriber Key is a unique identifier independent of the email address, so it can distinguish individuals who share an email. Understanding subscriber key vs. contact key vs. contact ID is a core Foundations topic.

Why not the others: the email address (A) is not guaranteed unique per person — that's exactly the problem the Subscriber Key solves; the reply-to address (C) is a send setting, not a subscriber identifier.

Correct: A — Subscriber preview plus a test send using a test data extension. Preview renders the email against a chosen subscriber's attributes, and a test send delivers to a small test audience so you can validate rendering before the real send — exactly the content-validation workflow Foundations tests.

Why not the others: a full production send (B) is the opposite of a controlled test and can't be undone; a global unsubscribe (C) removes a subscriber from all sends and has nothing to do with previewing content.

Correct: A — Data Extension entry source. A Data Extension entry source injects contacts into a journey from a sendable data extension, making it the standard choice for a welcome journey driven by new subscribers. Knowing the entry-source types is a Foundations focus.

Why not the others: "A/B test entry source" (B) isn't a journey entry source — A/B testing is an email-level feature; a manual CSV export (C) moves data out of the platform and wouldn't trigger journey entry.

Correct: A — Create a new version of the journey. Journey versioning lets you modify the flow (like reordering emails) while preserving the original version's structure and performance data, then activate the new version cleanly. Foundations tests the versions-vs-cloning distinction.

Why not the others: deleting and rebuilding (B) loses all history and is unnecessary; a running journey generally can't be restructured in place (C) — that's exactly why versioning exists.

Correct: A — Is Sendable. A data extension must be marked "Is Sendable" (with a send relationship mapped to the subscriber) before it can be used as the audience for an email send. Knowing data extension properties is central to the Data Management section.

Why not the others: "Is Testable" (B) relates to using the extension for test sends, not production audiences; "Is Read-Only" (C) is not a standard sendability property and wouldn't enable sending.

Correct: A — A scheduled Data Copy or Import activity in Automation Studio. Automation Studio's Data Copy/Import activity brings external data (such as CRM or point-of-sale files) into a data extension, and scheduling it automates the daily refresh. This is the standard import mechanism Foundations covers.

Why not the others: retyping records daily (B) is error-prone and defeats the purpose of automation; a global unsubscribe automation (C) removes subscribers from sends and does not import data.

Correct: A — A soft bounce. A soft bounce is a temporary delivery failure — a full mailbox, a server issue, or an oversized message — that may succeed on a later attempt. Distinguishing soft from hard bounces is exactly what the Reporting & Analytics section tests.

Why not the others: a hard bounce (B) is a permanent failure, such as an invalid or nonexistent address; a global unsubscribe (C) is a subscriber choice to stop receiving mail, not a delivery failure.