Explanation:
The core challenge is managing multiple distinct customer profiles (individual accounts) that share the same email address. Marketing Cloud's fundamental architecture uses a composite key: the Email Address for delivery and the Subscriber Key as the unique, primary identifier for each individual record. The solution is to assign a unique identifier to each account and use that as the Subscriber Key, while storing the shared email in the Email Address field.

Correct Option:

A. Subscriber Key:
This is the essential component. The Subscriber Key must be a unique identifier for each individual account (e.g., AccountNumber_12345, CustomerID_A1B2C3), not the email address. This allows multiple subscriber records in All Subscribers to have the same Email Address but different Subscriber Keys. Each unique Subscriber Key can then be associated with its own set of attributes in Data Extensions, enabling separate tracking, preferences, and journeys for each account linked to the shared inbox.

Incorrect Options:

B. Contact ID:
This is typically a system-generated ID within a CRM. While it could be used as the Subscriber Key, the term itself is not the core Marketing Cloud component to discuss. The conceptual solution is the Subscriber Key model; a Contact ID is just one possible value for it.

C. Member Record:
"Member Record" is not a standard Marketing Cloud data model component. It may refer to a record within a Data Extension or List, but it doesn't address the architectural requirement for a unique identifier for shared emails.

D. Data Extensions:
Data Extensions are where the separate subscriber attributes would be stored, but they are not the enabling component. The ability to link the correct attributes to the right individual account is governed by the Subscriber Key, which serves as the primary key in those Data Extensions.

Reference:
Marketing Cloud data model fundamentals state that the Subscriber Key is the unique identifier for a subscriber and is the primary link for all related data. Documentation on managing shared email addresses explicitly recommends using a unique Subscriber Key (like an account number) for each individual, while populating the Email Address field with the shared address.

Explanation:
When a customer clicks the default Marketing Cloud Profile Center unsubscribe link, the system removes the contact from the All Subscribers list by default. If the business unit is configured to use Enterprise-level unsubscribe, unsubscribing in one BU will unsubscribe the user from all business units. This explains why customers stop receiving emails from every BU rather than just from the intended one.

Correct Option Explanation

D. Business unit unsubscribe setting causes an Enterprise level unsubscribe
Each business unit can be configured to unsubscribe at the BU level or the Enterprise level. If set at the Enterprise level, any unsubscribe action— including from the Profile Center—removes the subscriber from All Subscribers entirely. This results in the user being unsubscribed from every BU in the account. This is typical when default Profile Center settings are used without customization.

Incorrect Option Explanations

A. The user gets added to a blocklist that causes an Enterprise level unsubscribe
A blocklist occurs when Marketing Cloud suppresses a subscriber due to delivery issues or anti-spam measures. It is not triggered by clicking an unsubscribe link and does not explain the behavior described.

B. The user is getting deleted from the All Subscribers List
Unsubscribing does not delete a subscriber from All Subscribers. It updates the status to Unsubscribed, but the record remains for tracking and compliance.

C. Data in data extensions corresponding to the customer is removed
Unsubscribing does not remove or modify any data in Data Extensions. These remain untouched. The unsubscribe process only updates subscriber status within All Subscribers/List subscriptions.

Reference
Salesforce Documentation: All Subscribers List and Unsubscribe Behavior

Marketing Cloud Admin Guide: Enterprise vs. Business Unit Unsubscribe Settings

Trailhead: Marketing Cloud Subscriber Management

Explanation:
The core reason why the total contact count in the Contacts Counts Report (500,000) is significantly less than the sum of all individual channel and source counts (300k Email + 200k Synchronized + 75k Mobile = 575,000) is the principle of the unified Contact Key. Marketing Cloud Engagement uses one unique Contact Key (Subscriber ID) to represent a single person across all channels and data sources. If the same person is in all three sources, they are counted only once toward the total contact count.

Correct Option:

D. There are overlapping contacts in each of the channel
Contact Key Unification: Marketing Cloud counts a contact only once based on their unique Contact Key.

Overlapping Data: The 575,000 individual records across the three sources contain a large degree of overlap. For example, a single customer may have an email address (counted in the 300k Email Subscribers), be a synchronized contact from the CRM (counted in the 200k Synchronized Contacts), and also have a mobile phone number (counted in the 75k Mobile Subscribers).

The difference (575,000 - 500,000 = 75,000) represents the number of records that are duplicates across the sources (i.e., 75,000 contacts are present in more than one of the listed data sources).

Incorrect Options:

A. Synchronized contacts are only counted after sending:
Synchronized Contacts are immediately counted in the Contacts Counts report as soon as they are synchronized and available in Contact Builder, regardless of whether a send has occurred.

B. Only active email subscriber discounted:
The Contacts Counts report typically includes all contacts with a unique Contact Key, regardless of their status (Active, Bounced, Unsubscribed). While the billable contacts might be slightly different, the overall Contact Count includes contacts from all sources, not just active email subscribers.

C. Mobile subscribers are not counted as contacts:
Mobile subscribers (specifically those with a unique Mobile Phone/Contact Key combination) are absolutely counted as contacts in the Contacts Counts report, as they represent a unique individual in the data model.

Reference:
Salesforce Marketing Cloud Documentation on Contact Counts and the Unified Contact Key

Explanation:
When Marketing Cloud Connect is used, the standard and recommended practice is to synchronize the Salesforce Contact ID (or Lead ID) as the Subscriber Key in Marketing Cloud. This creates a consistent, unique, and non-changing identifier across both systems. Salesforce IDs have both a 15-digit case-sensitive version and an 18-digit case-insensitive version; using the 18-digit version ensures reliable matching.

Correct Option:

C. 18-digit Contact ID:
This is the correct identifier. The 18-digit Salesforce Contact ID is the case-insensitive version of the ID, which is the safest to use for system integrations and searches. Marketing Cloud Connect typically uses this 18-digit ID as the Subscriber Key to ensure a perfect, stable one-to-one match between the Salesforce record and the Marketing Cloud subscriber.

Incorrect Options:

A. 15-digit contact ID:
While the 15-digit ID is valid in Salesforce, it is the case-sensitive version. Using it in integrations can sometimes lead to matching errors due to case sensitivity. The 18-digit version is the standardized, case-insensitive format used for integrations like Marketing Cloud Connect to prevent such issues.

B. Numeric Subscriber ID:
The Subscriber ID is an auto-generated, sequential numeric ID internal to Marketing Cloud. It is not synchronized from Salesforce and is not a reliable key for finding a specific Salesforce contact. The Subscriber Key is the field used for the external identifier.

D. Email Address:
While you can search by email address, it is not the definitive key for identifying a specific Salesforce contact. Email addresses can change, and multiple contacts might share the same email (e.g., in B2B). The Subscriber Key (18-digit Contact ID) provides a unique and immutable link to the exact Salesforce record.

Reference:
Marketing Cloud Connect implementation guides and best practices specify that the Salesforce Record ID (the 18-digit ID) should be used as the Subscriber Key. This is configured in the Contact Synchronization settings, ensuring that the Marketing Cloud All Subscribers list uses the Salesforce ID as the primary identifier for synchronized contacts.

Explanation:
To meet security requirements, encrypted files placed on the SFTP must be decrypted before import. Marketing Cloud provides this capability through the File Transfer Activity, which supports decrypting PGP-encrypted files using keys configured in Setup. The activity prepares the file for use by subsequent Import Activities in an automation. Other activities (Import or Data Extract) do not handle decryption, making File Transfer the correct and only supported method.

Correct Option Explanation

C. File Transfer Activity
The File Transfer Activity is designed to decrypt PGP files, unarchive files, and move files on the SFTP. When subscriber files are encrypted, this activity uses the Private Key stored in Marketing Cloud to decrypt them before import. It is the recommended and supported method for secure SFTP-based workflows.

Incorrect Option Explanations

A. Import Activity
Import Activities can pull files from the SFTP and load them into Data Extensions, but they cannot decrypt encrypted files. The file must already be decrypted or in plain format before the import process begins.

B. Data Extract Activity
Data Extract Activity is used for extracting data from Marketing Cloud, generating tracking extracts, or converting formats. It does not perform decryption, nor is it used for preparing inbound encrypted files.

D. Decryption Activity
Marketing Cloud does not have a standalone "Decryption Activity". Decryption is performed exclusively through the File Transfer Activity, making this option invalid.

Reference
Salesforce Documentation: Automation Studio – File Transfer Activity

Marketing Cloud Security Best Practices: PGP Encryption & Decryption