Salesforce Marketing Cloud Engagement Developer Practice Exam

Correct: B — A data extension. Data extensions are relational tables that can be queried with SQL, related to one another, and reused across channels and sends — the backbone of the Marketing Cloud data model for developers.

Why not the others: a subscriber list (A) is the legacy list model, not relational and not queryable with SQL joins; a publication list (C) governs commercial-vs-transactional subscription categories, not general data storage; a suppression list (D) holds addresses to exclude from sends, a narrow purpose rather than a reusable data store.

Correct: B — The contact enters a suppression period before final deletion. Contact Delete is a multi-step process: deletion is initiated, the contact is held through a suppression period (default 14 days) during which it can't be re-added, and only then is it finally deleted. This prevents accidental reintroduction of a deleted contact.

Why not the others: deletion is not instantaneous (A) — the suppression period exists precisely to prevent that; deletion applies across the contact model, not just the email channel (C); and there is no 90-day recovery list (D) — that value is invented.

Correct: A — Lookup(). Lookup() returns a single field value from the first row that matches the specified criteria — exactly the case of retrieving one value by key. It's the simplest data-extension read in AMPscript.

Why not the others: LookupRows() (B) returns an entire rowset that you then iterate over — more than needed for one value; InsertData() (C) writes a new row rather than reading; UpsertData() (D) updates or inserts a row, also a write operation.

Correct: B — LookupRows() with a FOR/NEXT loop using Row() and Field(). LookupRows() returns a full rowset; a FOR/NEXT loop iterates it, Row() selects each row, and Field() reads a column value — the standard AMPscript pattern for rendering repeating content.

Why not the others: Lookup() (A) returns only one value, so it can't drive a repeating block; RaiseError() (C) halts processing and isn't a looping construct; TreatAsContent() (D) renders stored content by reference and doesn't iterate a rowset.

Correct: B — Server-Side JavaScript (SSJS) using Marketing Cloud libraries. SSJS runs on Marketing Cloud servers at render time and uses platform-provided libraries (Core and Platform) to work with data extensions, messages, and applications — the right tool for heavier programmatic logic.

Why not the others: client-side JavaScript (A) runs in the browser and can't access Marketing Cloud server objects; Apex (C) and Visualforce (D) belong to the core Salesforce Lightning Platform, not Marketing Cloud Engagement, and aren't used to script SFMC content.

Correct: A — TreatAsContentArea(). TreatAsContentArea() takes stored content and processes it as a content area, allowing a reusable block to be rendered and its AMPscript interpreted inline — useful for centrally maintained, reusable content.

Why not the others: RedirectTo() (B) handles link redirection; AttributeValue() (C) returns a subscriber attribute value; BuildRowsetFromString() (D) parses a delimited string into a rowset — none of which render a stored content area.

Correct: A — An OAuth access token from the auth service using the client ID and secret. Both the REST and SOAP APIs share OAuth2 authentication: you POST the client ID and secret (from an Installed Package) to the auth service to get an access token, then pass it in the Authorization header as a Bearer token on subsequent calls.

Why not the others: a UI session cookie (B) authenticates the browser, not API calls; a SAML assertion (C) is for single sign-on to the app, not API token issuance; a named credential (D) is a core-platform Setup construct, not the Marketing Cloud API auth mechanism.

Correct: B — REST API, because it uses JSON and supports multi-channel features broadly. Marketing Cloud's REST API uses JSON request/response bodies and resource endpoints designed for multi-channel use, and all Marketing Cloud features implement REST — making it the natural default for a broad new integration.

Why not the others: SOAP (A) gives comprehensive access to email functionality but isn't the only way to send, and is XML-based; Bulk API (C) and Streaming API (D) are core Salesforce platform APIs, not the two Marketing Cloud Engagement APIs (REST and SOAP).

Correct: A — A SQL Query activity in Automation Studio. The SQL Query activity lets you write SQL that joins data extensions and system data views, then writes the output to a target data extension using Append, Update, or Overwrite — and it can run on a schedule inside an automation.

Why not the others: a Filter activity (B) copies a single data extension with row-level filters and can't perform a true multi-source join; a decision split (C) routes contacts within a journey, it doesn't produce a queried dataset; an A/B test (D) compares message variants, unrelated to segmentation via SQL.

Correct: B — Store the client ID, secret, and token securely and reuse the token until it expires. Salesforce guidance is to store credentials securely server-side and reuse each access token for its validity window rather than re-requesting one per call, which is inefficient and can trigger throttling.

Why not the others: requesting a token per call (A) is explicitly discouraged and causes throttling; exposing the secret in client-side JavaScript (C) or embedding it in a mobile app (D) leaks credentials and is called out as unsafe — secrets must never be exposed client-side.