Free Salesforce-Essentials-of-Pardot-for-Digital-Marketers Practice Test Questions (2026)

Explanation:

This question tests knowledge of the required variable tags in Pardot (Account Engagement) layout templates used for landing pages. These tags act as placeholders so Pardot can dynamically insert the page title, meta description, and main content (including any form) when the landing page is built and rendered.

✅ Correct Option:

✅ A. %%description%%
This tag is placed in the < head > section of the layout template. It pulls in the meta description entered when creating the landing page, which helps search engines and appears in search results.

✅ C. %%tittle%%
This is the title tag (commonly written as %%title%%; the double-t spelling is a frequent exam-question typo). It inserts the landing-page title into the browser tab and search-engine results.

✅ E. %%content%%
This tag marks the location where the form and/or opening general content appear on the page. Pardot replaces it with the selected form and any additional content defined in the landing-page builder.

❌ Incorrect options:

❌ B. %%name%%
No such variable tag exists for layout templates. The landing-page name is an internal identifier and is not injected via a %%name%% tag.

❌ D. %%form%%
There is no standalone %%form%% tag in the layout template. Form markup lives on the Form tab and is automatically inserted inside the %%content%% placeholder.

🔧 Reference:
→ Salesforce Help: Layout Templates – Confirms the required variable tags (%%title%%, %%description%%, and %%content%%) that must be included so Pardot can populate title, description, and content for landing pages and forms.

Explanation:

This question tests how Pardot (Account Engagement) processes custom redirects and completion actions for both anonymous visitors and existing prospects. Completion actions trigger immediately upon link click only for existing prospects, while initial visitor activity is retrospectively assigned to the prospect record once identified.

✅ Correct Option:

✅ B. Bob’s prospect record will show him clicking on the link and filling out the form.
When the unknown visitor submits the form as Bob, Pardot converts the visitor tracking history into a prospect record. All previous activities, including the custom redirect click and form submission, are retroactively linked to Bob's new prospect activity audit trail.

✅ C. Kate’s prospect record will show her clicking on the link and filling out the form.
Because Kate is already an existing prospect, Pardot immediately logs all her engagements. Both the custom redirect click event and her subsequent form submission activity are directly recorded on her existing prospect activity history timeline.

✅ D. Kate’s prospect record will have a tag of “clicked” applied to it.
Completion actions on custom redirects execute immediately upon the link click for existing prospects. Since Kate was already a known prospect when clicking the redirect, the completion action fires right away and applies the "clicked" tag to her record.

❌ Incorrect options:

❌ A. Bob’s prospect record will have a tag of “clicked” applied to it.
Completion actions on custom redirects do not execute for unknown visitors at the time of the click. Because Bob was an unidentified visitor when clicking the link, the completion action tag was not triggered, and converting later via form submission will not retroactively fire it.

❌ E. Bob’s visitor record will have a tag of “clicked” applied to it.
Pardot tags can only be applied to prospect records, not visitor records. Furthermore, completion actions cannot execute on unidentified visitor sessions, making it impossible for a visitor record to hold or inherit a tag.

🔧 Reference:
⇒ Salesforce Help: Completion Actions Considerations
→ Confirms that completion actions on custom redirects only execute for existing, cookied prospects at the time of the click.

Explanation:

This question tests your understanding of where SPF (Sender Policy Framework) records are managed for email authentication in Pardot (Account Engagement). SPF is a DNS-based email authentication method that helps prevent email spoofing by specifying which mail servers are authorized to send emails on behalf of your domain .

✔️ C. Company's DNS
SPF records are published as TXT records in your domain's DNS settings. To change SPF entries, you must log in to your DNS management console and edit the existing SPF TXT record by adding include:aspmx.pardot.com to authorize Pardot as a permitted sender . This is a DNS-level change, not a Pardot configuration.

❌ A. Account Settings
While you can view or add email sending domains in Account Engagement Settings > Domain Management, this is where you generate the DNS entries to provide to your IT team. You cannot actually change SPF records here—you can only copy the required values .

❌ B. Dashboard
The Pardot Dashboard provides high-level overview metrics, reports, and recent activity. It does not contain any settings or configuration options for managing email authentication, SPF records, or DNS entries .

❌ D. CRM
Salesforce CRM settings manage internal email authentication for Sales Cloud emails, not Pardot (Account Engagement). Each Salesforce product has its own authentication setup, and configuring one does not configure the others .

🔧 Reference:
→ Salesforce Success: DKIM and SPF Email Authentication Implementation - This official guide confirms that DNS entries (including SPF records) must be added at your DNS server level, not within Pardot.

Explanation:

This question tests the fundamental difference between dynamic and static lists in Account Engagement. Dynamic lists automatically add or remove prospects based on defined rules, while static lists are managed manually. Therefore, dynamic membership cannot be manually adjusted, whereas prospects can be manually added to or removed from static lists.

🟢 Correct Option:

A. Dynamic list membership CANNOT be manually updated but static list membership can be manually updated.
Dynamic lists automatically determine membership based on the criteria defined in their rules. When a prospect meets or no longer meets those criteria, their membership changes automatically. Administrators cannot manually override dynamic membership. Static lists, however, are manually managed, allowing prospects to be added or removed as needed.

🔴 Incorrect Options:

B. Dynamic lists are retroactive while static lists CANNOT be retroactive.
This does not describe the key difference between the two list types. The important distinction is how membership is managed. Dynamic lists use rule-based criteria to maintain membership automatically, while static lists require manual management.

C. Dynamic list membership can be manually updated but static list membership CANNOT be manually updated.
This reverses the actual behavior. Dynamic list membership is controlled automatically by its criteria and cannot be manually changed. Static lists are specifically designed to allow administrators to manually add or remove prospects.

D. An action can be added to a dynamic list that will trigger when a prospect is added but an action CANNOT be added to a static list to trigger when a prospect is added.
This is incorrect because the ability to use actions is not the fundamental distinction between dynamic and static lists. The defining difference is that dynamic membership is criteria-driven, while static membership is manually controlled.

🔧 Reference:
→ Salesforce Account Engagement Lists — Explains how static and dynamic lists manage prospect membership.

Explanation:

This question tests understanding of Engagement Studio (engagement programs) in Pardot/Account Engagement, specifically whether there is a per-action reuse limit within a single program’s logic. The platform allows actions to be reused freely as long as the overall program stays within step and performance limits.

✔️ Correct Option B:
Actions in Engagement Studio have no per-action reuse cap; you can add the same action type (email, wait, list change, score change, etc.) multiple times in one program. Official guidance emphasizes overall step limits (recommended <300) and edition-based program counts, not per-action restrictions.

❌ Incorrect Option A:
This incorrectly claims only email actions are unlimited while other actions are limited to once. In reality, all standard action types (emails, waits, list adds, score changes, tasks, etc.) can be reused multiple times in the same program.

❌ Incorrect Option C:
This adds pauses to the “unlimited” set but still wrongly restricts other actions to one use. Pauses (wait steps) are also reusable, but so are all other action types; there is no “one-time-only” rule for non-email/non-pause actions.

❌ Incorrect Option D:
This states every action can be used only once per program, which contradicts Engagement Studio design. Programs commonly reuse the same email or wait step across multiple branches or loops; the constraint is total steps, not per-action uniqueness.

🔧 Reference:
→ Considerations for Using Engagement Studio — Confirms edition-based program limits and re-entry settings, with no per-action reuse restriction.

Explanation

This question checks understanding of where Pardot allows custom field creation within its data model. Pardot supports custom fields tied to specific record types so that marketers can capture and use additional data points across automations, forms, and reporting.

✅ D. Account, Opportunity, Prospect
Pardot supports custom fields on Prospect records for lead-level data, custom Account fields for company-level details synced from the connected CRM, and custom Opportunity fields for deal-related data used in automation rules and reporting.

❌ A. Campaign, Opportunity, Prospect
Campaigns in Pardot are used for tracking source attribution and are not a record type that supports custom field creation. Only Prospect, Account, and Opportunity objects allow custom fields.

❌ B. Case, Contact, Lead
Case, Contact, and Lead are Salesforce CRM objects, not Pardot record types. Pardot custom fields exist on Prospect, Account, and Opportunity, which then map to these CRM objects during sync.

❌ C. Account, Prospect, User
User records in Pardot represent internal team members and do not support custom fields. Custom fields are limited to Account, Prospect, and Opportunity, not internal user accounts.

Reference
🔧 Create Custom Account Fields – Salesforce Help → official Salesforce documentation confirming Account, Prospect, and Opportunity as the record types supporting custom field creation in Pardot.

Explanation:

This question tests how Account Engagement (Pardot) matches and syncs prospect records with Salesforce Lead or Contact records. The connector uses specific matching criteria to link the records for bidirectional field and activity sync.

✅ Correct Option:

✅ A. Shared Contact or Lead ID
Once a prospect is linked to a Salesforce record, the CRM ID (Lead or Contact ID) becomes the primary matching key. Subsequent syncs use this shared ID to keep the records aligned.

✅ C. Shared email address
When no CRM ID exists on the prospect, Pardot matches on email address (checking Contacts first, then Leads). This allows initial linking or matching when the CRM ID is not yet present.

❌ Incorrect options:

❌ B. Shared Assigned User ID
Assigned User controls ownership and assignment rules but is not used as a matching criterion for syncing the prospect to a Lead or Contact record.

❌ D. Shared tracking pixel
A tracking pixel is used for email open tracking and does not play any role in matching or syncing prospect records with Salesforce Leads or Contacts.

🔧 Reference:
→ Salesforce Help / Account Engagement Salesforce Connector documentation – Confirms that records sync primarily on CRM ID, with email address used as a secondary match when no CRM ID is present.

Explanation:

This question tests your understanding of how Engagement Studio (Pardot) treats prospects when edits are made to a program that is already running. Engagement programs evaluate prospects as they move through the steps, and the logic applies to individual prospect paths based on their progress. Once a prospect has passed a specific step, they cannot go back to receive an email from an earlier step.

✔️ B. Only prospects in the engagement program who have NOT reached that step will receive the email.
When a new email step is added to the middle of a running engagement program, only prospects who have not yet progressed past that point in the program's logic will receive the new email. Prospects who have already passed that step have already been evaluated and moved along their path, so they will not go back to receive it.

❌ A. All prospects in the engagement program will receive the email, even those who have already reached the end.
This is incorrect because prospects who are already at or beyond the new step are not retroactively pulled back. The program evaluates each prospect based on their current position in the journey, not the entire program's history.

❌ C. All prospects in the engagement program who have NOT reached the end will receive the email.
This is incorrect. Only prospects who have not yet passed the specific step where the email was inserted are eligible. Prospects who are further along but not yet at the end will not be sent back to receive it.

❌ D. A new email CANNOT be added to an engagement program.
This is incorrect. You can pause a running engagement program to edit it and add new steps, including email actions. The edit then applies to all future prospects who reach that step.

🔧 Reference:
→ Salesforce Help: Create an Engagement Studio Program - This official guide confirms that if you'd like to make changes after you start your program, you must pause it to access the Build tab for edits.

Explanation:

This question tests the relationship between Account Engagement prospects and Salesforce records. When an Account Engagement prospect is assigned and synced with Salesforce, Salesforce can create a corresponding Lead record by default when no matching Salesforce record exists.

🟢 Correct Option:

A. Lead
By default, a new Account Engagement prospect that is assigned and synchronized with Salesforce is created as a Lead when there is no existing matching Salesforce record. This allows the prospect's information and marketing activity to be connected to a Salesforce sales record. The Lead can later be converted into a Contact and Account when the sales process requires it.

🔴 Incorrect Options:

B. Opportunity
An Opportunity represents a potential sales deal and is normally associated with an existing Account and Contact. A newly assigned Account Engagement prospect does not automatically create an Opportunity by default because the prospect has not necessarily reached an opportunity stage.

C. Content
Content is not the Salesforce record automatically created when an Account Engagement prospect is assigned. Content can be used for marketing assets, but it does not represent an individual prospect's Salesforce record.

D. Account
An Account represents a company or organization in Salesforce. A newly assigned prospect does not automatically create an Account by default. Account creation depends on the organization's Salesforce processes and matching or conversion rules.

🔧 Reference:
→ Salesforce Account Engagement Salesforce Connector — Explains how Account Engagement prospects synchronize with Salesforce records.

Explanation:

This question tests your understanding of visitor conversion mechanisms in Pardot (Account Engagement). An anonymous visitor becomes an identified prospect when an explicit action ties their browsing session and browser cookie directly to a specific email address and prospect profile.

✅ Correct Option:

✅ A. Submitting a form on a landing page.
When an anonymous visitor fills out and submits a Pardot form or form handler on a landing page, they provide explicit contact details (such as an email address). Pardot immediately uses this information to convert the visitor into an identified prospect record.

✅ D. Clicking on a tracked link in an email.
When a recipient clicks a tracked link inside an email sent through Pardot, the redirect URL passes a unique tracking parameter. This action instantly associates the visitor's current browser session and tracking cookie with their existing email record, identifying them in the system.

❌ Incorrect options:

❌ B. Matching an automation rule.
Automation rules in Pardot evaluate and run actions only on existing, identified prospects. Because anonymous visitors do not have prospect records, they cannot be evaluated by or matched against automation rules to trigger a conversion.

❌ C. Viewing more than one web page.
Simply browsing multiple website pages generates tracking history for an anonymous visitor session, but it does not supply an email address or identity. Page views alone cannot convert an anonymous visitor into an identified prospect.

🔧 Reference:
⇒ Salesforce Help: How Visitors Become Prospects
→ Confirms that form submissions and clicking tracked links in Pardot emails are primary methods for converting visitors into prospects.