Explanation:

Why these work:

C. Validate the email at the form level.
Using the form field’s Email data format (regex validation) blocks obvious fakes (e.g., missing “@”, bad TLDs) at submission, reducing junk leads right away.
D. Send the asset via autoresponder email.
Deliver the download link only by email (not on the thank-you page). If the address isn’t real, they won’t receive the content—effectively gating access to valid inboxes.

Why not the others:
A. Send autoresponder to “invalid” emails — If the address is invalid, the autoresponder won’t arrive. You also can’t reliably know it’s invalid at submit time beyond format checks; bounce detection happens later.
B. Mark as Do Not Email — Prevents future sends, but it doesn’t stop fake addresses from getting the asset at submission if you show it on the thank-you page.

Explanation:

LenoxSoft wants to use a repeating Engagement Studio program to send emails to prospects who complete a specific form, increase their scores based on email engagement, notify an assigned user when a call to action is completed, and allow prospects to re-enter the program only when they complete the form again. The key requirement here is that prospects should only repeat the program upon re-submitting the form, which makes a dynamic list the most suitable approach.

Here’s why C is the correct answer:
A dynamic list in Salesforce Marketing Cloud Account Engagement (formerly Pardot) automatically updates its membership based on predefined criteria, such as form completion. By setting the dynamic list criteria to include prospects who have completed the specific form, the list will automatically add prospects when they meet this condition (i.e., upon form submission or resubmission).
In Engagement Studio, the dynamic list can be used as the recipient list for the program. When a prospect completes the form again, they are automatically re-added to the dynamic list and can re-enter the program, satisfying the requirement for repeating the program only upon form re-submission.
Dynamic lists are ideal for scenarios where membership needs to change dynamically based on prospect actions, ensuring that only qualifying prospects (those who have completed the form) are included in the program at any given time.

Why the other options are incorrect:

A. By using a static list on the form's completion action that is used as the recipient list on the program, then remove prospects from the static list before every end step in the program:
This approach is inefficient and error-prone. Static lists require manual or automation-driven updates to add or remove prospects. Removing prospects at every end step in the Engagement Studio program adds unnecessary complexity, as it requires multiple completion actions or automation rules to manage list membership. Additionally, static lists do not automatically handle re-submissions, so prospects who complete the form again would not be re-added to the list unless additional automation is configured.

B. By using an automation rule to add prospects to a static list based on the form being completed, then use that list as the recipient list on the program:
While an automation rule can add prospects to a static list upon form completion, this approach does not inherently support the requirement for prospects to repeat the program only when they complete the form again. Static lists do not automatically update based on new actions, so re-submissions would require additional automation to re-add prospects, making this less efficient than a dynamic list. It also introduces unnecessary manual maintenance.

D. By using a static list on the form's completion action, then start the program with a "Form Completed" trigger so only prospects who completed the form will get the follow up actions:
This option is incorrect because Engagement Studio programs do not use "Form Completed" as a direct trigger for starting a program. Instead, Engagement Studio programs typically start with a recipient list (static or dynamic) or a specific action like a tag or custom field change. Using a static list also has the same limitations as in option A, where re-submissions are not automatically handled without additional automation.

How it works in practice:
Create a dynamic list with the criterion "Prospect Form = [Specific Form] = Completed."
In Engagement Studio, set the program to use this dynamic list as the recipient list.
Configure the program to send emails, increase prospect scores based on email engagement (e.g., opens or clicks), and notify the assigned user when the call to action is completed.
When a prospect completes the form again, the dynamic list automatically re-adds them, allowing them to re-enter the Engagement Studio program.

References:
Salesforce Help Documentation: “Dynamic Lists in Account Engagement” (explains how dynamic lists automatically update based on criteria like form completion).
Pardot Knowledge Base: “Using Lists in Engagement Studio” (details how dynamic lists can be used as recipient lists for programs).
Trailhead Module: “Pardot Engagement Studio Basics” (covers how to set up programs with dynamic lists and handle repeating actions based on prospect behavior).

Explanation:

A. If a prospect is removed from a list that a program uses, that prospect stops moving through the program — ✅ True
Salesforce’s FAQ spells this out explicitly: “If a prospect is removed from a list that a program is using, that prospect stops moving through the program.”

B. If you remove a prospect from a program’s recipient list, and then add the prospect back later, they start where they left off — ✅ True
From the same FAQ: “…if you remove a prospect from a program’s recipient list, and then add the prospect back later, they start where they left off in the program.” This includes honoring any remaining waits.

C. If a prospect opts out of a list used for a program, they still move through the program, but don’t receive program emails — ✅ True
Salesforce clarifies: “Opt-out status only applies to marketing emails. If a prospect opts out of a program list, they move through the program but don’t receive emails from that program.” Note: if the prospect is still on another list that feeds the same program, they could receive emails via that other list.

D. When no new prospects are added to or processed in a program for 30 days, it becomes inactive — ✅ True
Official guidance: “Engagement programs are considered inactive when no new prospects are added or moving through the program for 30 days.”

E. When merged prospects are members of the same engagement program, it’s possible to skip steps or repeat a step; the new master restarts from the most recently touched step — ✅ True
Salesforce’s FAQ: after a merge, “the new primary prospect starts from the step that any of its merged prospects touched most recently… it’s possible for the primary prospect to skip steps or move through the same step twice.”

F. A single rule step can evaluate up to five conditions — ✅ True
This is listed as a core limitation/feature: “A single rule step can evaluate up to five conditions.”

G. When no new prospects are added to or processed in a program for 365 days, it becomes inactive — ❌ False
As above, the inactivity threshold is 30 days, not 365

Explanation:

For Marketing Cloud Account Engagement (MCAE) to be fully authenticated and authorized to send emails on your behalf, it must pass specific technical checks related to email deliverability and domain authentication. These are critical to prove to Internet Service Providers (ISPs) like Gmail and Outlook that the emails are legitimate and not spam.

Why A is Correct (Domain Key Policy):
This refers to DKIM (DomainKeys Identified Mail) authentication. A green check mark here confirms that MCAE has been successfully configured to cryptographically sign outgoing emails. This signature proves that the email came from your authorized domain and was not tampered with in transit. It is a fundamental requirement for email authentication.

Why D is Correct (SPF Record):
The SPF (Sender Policy Framework) record is a DNS (Domain Name System) record that lists which mail servers are permitted to send email for your domain. A green check mark next to the SPF record indicates that you have successfully added MCAE's sending IP addresses to your domain's SPF record. This tells receiving mail servers that emails coming from MCAE's infrastructure are legitimate.

Why B is Incorrect (FBS Registration ID):
"FBS" is not a standard acronym or feature related to MCAE email authentication. It is likely a distractor and does not represent a valid component of the setup process.

Why C is Incorrect (Salesforce Connected User):
A green check mark next to the Salesforce Connector indicates that the integration between MCAE and the core Salesforce platform is active and healthy. This is crucial for syncing prospects, leads, contacts, and campaign data, but it is not a direct indicator that the system is ready to send emails. You can have a perfectly connected connector but still have failed email authentication.

Key Concepts:
Email Authentication: The process of verifying that an email message is from the claimed sender. The primary protocols are SPF, DKIM, and DMARC.
SPF (Sender Policy Framework): A DNS record that authorizes specific IP addresses to send mail for a domain.
DKIM (DomainKeys Identified Mail): An encryption standard that adds a digital signature to an email's headers, ensuring integrity and authentication.
The presence of green check marks for both SPF and DKIM in the MCAE Admin > Domain Management section is the definitive indicator that the necessary steps for email authentication are complete.

Explanation:

When an organization integrates Salesforce and Marketing Cloud Account Engagement (formerly Pardot), a key step is often enabling User Sync. This feature is designed to centralize user management in Salesforce, making it the "source of truth" for user records.

Here's why option B is the correct and necessary step:

User Sync's Purpose: User Sync automatically creates and updates Marketing Cloud Account Engagement user records based on their corresponding Salesforce user records. The goal is to ensure that users have a single login (via Salesforce) to access both platforms.
The Linking Mechanism: The sync process relies on a unique identifier to match users. When a user has an entry in the "CRM Username" field in their Account Engagement user profile, the system recognizes that this user is already connected to a Salesforce user.
The Conflict: If you enable User Sync, it will attempt to take control of all user records. For users who need to maintain their separate, direct login to pi.pardot.com (for example, a consultant or a user who doesn't have a Salesforce license), this presents a problem. If their "CRM Username" field is populated, the sync will try to link them to a Salesforce user, which can disrupt their existing direct login access.
The Solution: To prevent this disruption and allow a user to continue logging in directly to Marketing Cloud Account Engagement, you must ensure their CRM Username field is empty before you enable User Sync. This tells the system that this user is not meant to be synced and should be managed as an independent, direct-access user. The sync will simply ignore them and their login credentials will remain valid.

This is a critical preparation step to ensure that you do not accidentally lock out users who require a direct login, particularly in situations where not all Marketing Cloud Account Engagement users are also Salesforce users.