Explanation:

Why A is correct
Salesforce Engage (the sales-facing add-on for Account Engagement/Pardot) is priced at $50 USD per user per month (typically billed annually). This price is listed on Salesforce’s own properties:
AppExchange listing for Salesforce Engage explicitly shows “$50 USD/user/month.”
On Salesforce’s Account Engagement pricing page, the related add-on “Sales Emails and Alerts” (the current naming that maps to Engage capabilities) is listed at $50 USD/user/month.
Note: Salesforce pricing can change and is usually billed annually; the exam expects the canonical $50 figure for Engage.

Why the other options are not correct
B. $100 → Not the listed price for Salesforce Engage; official pages show $50.
C. It’s always free → Engage is a paid add-on, not free.
D. $15 → No official source lists Engage at $15; $50 is the documented amount.

Example
If a 12-person sales team wants Engage to send tracked one-to-one emails and get real-time alerts on prospect activity, they’d license 12 Engage seats × $50 = $600/month (usually billed annually) on top of their Account Engagement edition.

Explanation:

In Marketing Cloud Account Engagement (MCAE), when a user is provisioned across multiple Business Units (BUs) and has the same CRM username across those BUs, they can use the BU Switcher to toggle between environments without logging out.
This feature allows User A to:
Seamlessly switch from the North American BU to the European BU
Access Engagement Studio programs, assets, and settings in the target BU
Review or edit the program as needed without needing screenshots or separate logins
This is the recommended and most efficient method for cross-BU collaboration.

❌ Why Other Options Are Incorrect:
A. Screenshot and email → Inefficient and doesn’t allow direct interaction with the program.
C. Create a custom user role → Roles control permissions, but User A already has access if provisioned correctly.
D. Log out and log in again → Unnecessary if BU Switcher is enabled; adds friction and risk of error.

📌 Example:
User A logs into MCAE and sees the BU Switcher dropdown in the top navigation. They select “Europe” from the list, and the interface reloads with access to the European BU’s assets. They open the Engagement Studio program, review it, and leave comments for the European team — all without leaving the platform.

🔗 References:
Salesforce Help: Business Units in Marketing Cloud Account Engagement

Explanation:

The key requirements are:

A landing page for event registrations.
A drag-and-drop building experience.
No use of HTML or CSS.

Marketing Cloud Account Engagement offers two primary landing page builders: the "Classic" builder (which often requires HTML knowledge) and the "Enhanced" Landing Page Builder, which is a modern, drag-and-drop, WYSIWYG (What You See Is What You Get) editor.

B: Create a landing page using the enhanced landing page experience. Use the Marketing Cloud Account Engagement Form component to add a Marketing Cloud Account Engagement form to track submissions. This is the correct method.

The Enhanced Landing Page Experience is specifically designed for a drag-and-drop, no-code building process.
Within this builder, there is a dedicated "Form" component. You can drag this component onto the page and link it to an existing Account Engagement form or create a new one directly. This ensures all form submissions are tracked natively within Account Engagement, allowing for scoring, automation, and reporting, all without writing a single line of code.

Why the Other Options are Incorrect:

A: Create a custom layout template in Marketing Cloud Account Engagement that contains form elements. Creating a custom layout template is an advanced task that typically requires HTML and CSS. This directly violates the client's requirement for a no-HTML/CSS solution. This approach is meant for developers who need to create a custom, reusable structure, not for marketers wanting a simple drag-and-drop page.
C: Create a landing page using the enhanced landing page experience. Use the HTML component to iframe in a Marketing Cloud Account Engagement form. While this starts with the correct builder, it then incorrectly uses the "HTML" component and an iframe. Using the HTML component, even for an iframe, involves working with HTML code. This is more complex, less stable, and completely unnecessary since a native, drag-and-drop "Form" component already exists. This method would be a technical workaround, not the standard, recommended practice.
D: Create both a landing page and form using the enhanced landing page experience. This is very close, but it is incomplete and slightly misleading. While you can create the landing page in the enhanced experience, the form itself is not "built" directly on the page canvas in the same way. You use the Form component (as described in option B) to place and configure a form that is managed separately in Account Engagement's form tool. Option D's phrasing suggests the entire form is built from scratch within the page builder, which isn't the precise workflow. Option B provides the most technically accurate description.

Reference:
Salesforce documentation on "Build Landing Pages with the Enhanced Experience" explicitly promotes its drag-and-drop, no-code nature and details how to use the built-in "Form" component to add tracked forms to a page. This is the standard, out-of-the-box method for fulfilling this business requirement.

Explanation:

To assign prospects meeting specific criteria (completed “Product Interest” form, score > 100, grade > C, member of “Target Account” list) to one of five users in a round-robin fashion, LenoxSoft should use an automation rule combined with a user group in Marketing Cloud Account Engagement. Here’s why:

Automation Rule: This tool evaluates prospects against multiple criteria (form completion, score, grade, list membership) and applies actions like assigning to a user group. It runs continuously on all prospects, ensuring consistent application of the criteria.
User Group: Account Engagement’s user groups allow round-robin assignment, distributing prospects evenly among group members (the five users). This ensures balanced lead distribution without manual intervention.
Process: Create an automation rule with the criteria: “Form = Product Interest,” “Score > 100,” “Grade > C,” “List = Target Account.” Set the action to “Assign to user group” and select a group containing the five users. Account Engagement will rotate assignments among them.

Why Other Options Are Incorrect

A. Automation rule and user queue:
Queues are a Salesforce feature, not native to Account Engagement. While leads can sync to Salesforce queues, round-robin assignment within Account Engagement requires a user group.
C. Form completion action and user queue:
Completion actions on forms apply immediately after submission but can’t evaluate multiple criteria (e.g., score, grade, list membership) or support round-robin assignment to a queue, which isn’t an Account Engagement feature.
D. Form completion action and user group:
Completion actions are limited to form submissions and can’t check additional criteria like score, grade, or list membership. They also don’t support round-robin assignment to a user group natively.

References
Salesforce Help: Automation Rules
Salesforce Help: User Groups for Round-Robin Assignment

Explanation:

When you add a field to a Marketing Cloud Account Engagement form, you must assign it a "Data Format." This setting validates the information a prospect enters before the form can be submitted. The available, standard data formats are:

A. Text: Accepts any alphanumeric characters.
B. Number: Accepts only numerical digits.
C. Email: Validates that the input follows a basic email format (e.g., user@domain.com).
D. Phone: Formats the input into a standard phone number structure.
G. Date: Provides a date picker and validates the input as a valid date.

These five options are the core, out-of-the-box data formats available for any custom or default field on a form.

Why the Other Options are Incorrect:

E. Email with valid mail server:
This is not a standard data format. While Account Engagement can perform real-time email verification (checking for valid DNS MX records) as a separate process, this is not a selectable "Data Format" for a form field itself.
F. Email not from ISPs and free email providers:
This is not a built-in data format. Restricting domains (like gmail.com, yahoo.com) is typically done through other means, such as list segmentation or automation rules, not through the form field's data format setting.
H. Password:
This is not a data format for form fields. While a form can have a field whose HTML type is set to "password" (which masks the input with asterisks), this is a presentation attribute, not a data validation format. The data itself is still stored and validated as plain text.

Reference:
You can verify the available data formats in the Marketing Cloud Account Engagement interface. When editing a form and adding a field, the "Data Format" dropdown list will present the options: Text, Number, Email, Phone, and Date. The official Salesforce documentation on "Creating Forms" lists these as the available formats for field validation.

Explanation:

In Marketing Cloud Account Engagement (MCAE), the number of active automation rules you can create is limited based on your edition. These limits help ensure system performance and scalability.

Here’s the breakdown:

Growth Edition: 50
Plus Edition: 100
Advanced Edition: 150

Automation rules are used to evaluate prospect criteria and apply actions like assigning users, adding tags, or updating fields. These limits apply to active rules only — you can pause or archive rules to stay within your quota.

❌ Why Other Options Are Incorrect:
A. Always 100 → Incorrect. Limits vary by edition.
C. Advanced Edition: 200 → Overstates the actual limit; the correct cap is 150.
D. Growth Edition: 100 → Incorrect; Growth is limited to 50.

Reference:
Salesforce Help: Account Engagement Limits

📌 Example:
LenoxSoft uses MCAE Plus Edition. Their marketing team has built 95 automation rules for lead assignment, tagging, and segmentation. They want to add 10 more, but MCAE will only allow 5 more active rules. To proceed, they pause 5 older rules to stay within the 100-rule limit.

Explanation:

Custom Objects in Marketing Cloud Account Engagement allow you to bring in and synchronize data from related records in Salesforce to gain a more complete view of prospect and customer activity.

A: You can create and sync a custom object from anything that is linked to a contact, lead, or account in your CRM. This is the correct and most accurate statement. A Custom Object record in Account Engagement must have a relationship (either directly or indirectly) to a core Salesforce object that syncs with an Account Engagement prospect—namely, a Lead, a Contact, or an Account. For example, you can sync a "Project__c" object if it has a lookup relationship to the Account, or an "Event_Attendance__c" object that is related to a Contact.

Why the Other Options are Incorrect:
B: You can create and sync a custom object from any object in Salesforce. This is too broad and therefore incorrect. You cannot sync a Custom Object that is completely unrelated to the core marketing and sales entities (Lead, Contact, Account). For instance, you could not sync an object that only relates to a Case or an Opportunity Product if it has no path back to a Lead, Contact, or Account.

C: You can create and sync a custom object from anything that is linked lead and contact, but can't be linked to account due to high risk of errors. This is false. You absolutely can create Custom Objects linked to an Account. A common use case is syncing an "Asset" or "Location" object that is a child of the Account. There is no inherent "high risk of errors" that prevents this.

D: You can create and sync a custom object from anything that is linked to a contact, lead and account in your CRM at the same time. This is incorrect and describes an impossible relationship in standard CRM data modeling. A single Custom Object record cannot be simultaneously and directly linked to a Lead, a Contact, and an Account. It must be related to one of these core objects, which then defines its relationship to the others (e.g., a Custom Object related to a Contact is inherently related to that Contact's Account).

Reference:
This functionality is defined in the official Salesforce documentation for "Custom Objects in Account Engagement." The setup requires mapping the Salesforce object to a corresponding Account Engagement Custom Object and defining the "Base Object" (Prospect, Account, or Opportunity) that serves as the root of the relationship. This confirms that the connection must flow through Leads, Contacts, or Accounts.

Explanation:

Why A is correct
In Account Engagement, the Testing tab lets you send to test lists (and to individual addresses). A test list is a special list of internal “prospect” records specifically for testing. Using a test list is the supported way to preview an email as a prospect would see it, including rewritten links and personalized fields/variable tags.

Reference docs:
• Trailhead shows the Testing tab supports sending to test lists.
• Salesforce Help explains how to create an Email Test List and use it for testing.
• “Preview and Test Emails” covers testing steps to troubleshoot personalization.
(Practitioner note: many deliverability/blog guides add that test lists, not basic one-off tests, are the reliable way to see links/variable tags exactly as prospects do. )

Why the others are not correct

B. Dynamic list as the recipient in the Sending tab — That would be an actual send to a live audience, not a controlled test. The goal is to test safely before going live. Use the Testing tab with a test list.
C. One-off test send to a typed email — A “basic” one-off test often won’t fully replicate prospect-level personalization/link rewriting. A test list is the recommended path to validate links and variable tags as a real prospect.
D. Static list as the recipient in the Sending tab — Same issue as B: that’s a live send, not a preflight test. Testing should be done via the Testing tab with a test list.

Example
Create a list called “Internal Email Testers” (check Email Test List) and add internal prospect records for your reviewers. In the email → Testing tab → Send to Test Lists → select “Internal Email Testers.” Review that links resolve and all HML/variable tags (e.g., {{Recipient.FirstName}}) render as expected before the real send.

Explanation:

To sync Salesforce custom objects with Marketing Cloud Account Engagement (formerly Pardot) prospects for use in automation rules, the first step is to ensure the Salesforce custom object has a lookup relationship to a lead, contact, or account. This relationship is critical because Account Engagement uses it to associate custom object records with prospects, enabling data syncing and automation. Without this link, Account Engagement cannot map the custom object to prospect records.

Why Other Options Are Incorrect
A: Account Engagement custom objects are not created at the “prospect level” or “prospect Account level”; they are mapped to Salesforce custom objects with a lead, contact, or account relationship.
C: Adjusting sync behavior comes later, after the custom object is mapped in Account Engagement.
D: A full database sync is not required before creating the Salesforce custom object, and the object’s relationship must be set up first.

References
Salesforce Help: Custom Objects in Account Engagement – States custom objects must have a lookup to lead, contact, or account as the first step.

Explanation:

C. Dynamic Content
Dynamic Content in MCAE allows marketers to personalize blocks of content based on prospect field values (e.g., industry, location). HML is used to evaluate conditions and render the appropriate content. For example, you can show different product images or messaging based on {{Recipient.Industry}}.
D. User Signatures
User Signatures use HML to pull in sender-specific details like name, title, and phone number. This ensures that emails sent by sales reps or marketers include personalized contact information using merge fields like {{Sender.FirstName}}.
E. Email Templates
Email Templates are the most common use case for HML. You can personalize subject lines and body content using merge fields such as {{Recipient.FirstName}} or conditional logic like {{#if Recipient.Industry}}. This enhances engagement and relevance.

❌ Incorrect Options:
A. User Notifications
User Notifications are internal alerts triggered by prospect activity (e.g., form submissions). These do not support HML personalization because they are not designed for external communication or dynamic rendering.
B. Social Posts
Social Posts in MCAE are static and do not support merge fields. HML is not applicable here because social platforms do not allow dynamic personalization based on prospect data.

References:
Salesforce Help: Handlebars Merge Language Overview
SalesforceBen: What is HML in Pardot?
Salesforce Help: Dynamic Content in Account Engagement

Explanation:

Why D is correct
In Account Engagement (Pardot), when AMPSEA (Allow Multiple Prospects with the Same Email Address) is enabled, list emails are deduplicated by email address. If multiple prospects on the recipient list share the same email, only one email is sent to that address, and the send activity is recorded on the prospect with the most recent activity. So, if another prospect record had the same email as the AM’s prospect, that other record would have received the message—and the AM’s prospect would appear not to have been sent the email.
Example:
Two prospects, Prospect A and Prospect B, both have john@example.com and are on the “2019 Tradeshow” list. On send, Pardot deduplicates by the email address and sends one copy to the record with the most recent activity (say, Prospect B). Prospect A will show no send for that email.

Why the other options are not correct

A. “Prospect already received another email within the past business day.”
There isn’t a native, automatic “per business day” throttle that blocks a prospect from a standard list email. You can build recency/frequency suppression logic yourself (e.g., dynamic suppression lists), but it’s not an automatic blocker as described here.
B. “Dedicated IP wasn’t warmed properly.”
IP warmup issues impact deliverability (inbox placement, bounces), not whether a send is attempted to a specific prospect. Poor warmup wouldn’t selectively prevent a single addressed prospect from being sent to. (You’d see delivery/bounce, not “no send.”)
C. “Prospect not a member of the list.”
The scenario claims the prospect was a member. While dynamic list membership is evaluated at send time (and a change in membership could indeed exclude someone), this answer doesn’t fit the question’s premise and is less likely than the well-documented AMPSEA deduplication behavior.

References
Allow Multiple Prospects with the Same Email Address (AMPSEA) — “When you send a list email, Account Engagement deduplicates by email address…”
Guide/Explainers on AMPSEA list email behavior — one email per address; the most recent activity record receives and logs the send.

Final:
D is the expected cause—AMPSEA deduplication meant another prospect record sharing the same email address received the list email instead.

Explanation:

The goal is to determine which leads are most likely to buy based on their engagements.
Einstein Behavior Score (B): This feature uses artificial intelligence (AI) to analyze a prospect's historical and recent engagement patterns (clicks, forms, page views, etc.) to predict their likelihood to convert or purchase. This directly addresses the requirement for insights based on engagement to predict buying intent.

Why the Other Options Are Not the Best Fit

Einstein Lead Score (C): While also an AI feature, the Einstein Lead Score predicts how likely a lead is to convert to a Contact on a standard Lead conversion path, not necessarily their likelihood to purchase. It focuses more on demographic fit and standard lead quality rather than direct engagement-based buying intent.
Marketing Cloud Account Engagement Score (D): This is a traditional lead scoring method based on explicit rules defined by the user (e.g., +10 points for a form submission, -5 points for an unsubscribe). It measures a prospect's interest (the quantity of their engagement) but is not an AI-driven predictive feature for buying likelihood.
Marketing Cloud Account Engagement Grade field (A): The Grade field measures a prospect's fit (how well they match your ideal customer profile) based on demographic criteria (e.g., company size, industry, title). It is not based on engagement and does not predict buying likelihood.