Explanation:

NTO is the holding company with three distinct subsidiaries: Universal Containers, Ursa Major Solar, and Cloud Kicks. The requirements are:

• NTO employees need access to all subscribers and aggregate reporting. This means the parent BU must exist as the central oversight layer.
• Each subsidiary runs campaigns with its own branding, content, and subscribers. This requires true isolation of data, assets, and sending identity, which Business Units are designed to provide.
• NTO does not plan to execute campaigns itself. The parent BU serves purely as an administrative and reporting hub, not an active sending unit.

Recommended Architecture:
• One Parent BU at the enterprise level for the NTO holding company, providing central oversight, aggregate reporting, and shared assets if needed.
• Three Child BUs, one for Universal Containers, one for Ursa Major Solar, and one for Cloud Kicks, each with its own Sender Authentication Package (SAP) to ensure independent sending domains, branding, and deliverability reputation.

This is the standard pattern for multi-brand enterprises: a parent enterprise account with child Business Units for each brand that needs operational independence.

Why Other Options Are Incorrect:

A. One parent BU and one child BU: A single child BU would force all three subsidiaries to share data, content, and sending identity. This violates the requirement that each subsidiary should have its own branding, content, and subscribers. It also fails to provide the isolation needed for independent campaigns.

C. One parent BU and two child BUs with their own Sender Authentication Packages: NTO has three subsidiaries, not two. With only two child BUs, one subsidiary would have no dedicated BU and would either share with another subsidiary or operate from the parent BU. Neither approach meets the isolation and branding requirements.

D. One parent BU with three additional private domains: Private Domains only handle authentication, such as SPF, DKIM, and DMARC, for sending domains. They do not create isolation for data, content, subscribers, or user permissions. The subsidiaries would still share the same Business Unit, meaning their data and assets would not be separated.

Key Takeaway:
When a holding company owns multiple subsidiaries that each require independent branding, content, and subscriber management, the architecture is one parent BU for central oversight plus one child BU per subsidiary for operational isolation. Each child BU should have its own Sender Authentication Package to maintain independent sending identity and deliverability.

Explanation:

Since the two brands have contrasting target groups and identities and require complete separation, including different styles, no cross-mention of the other brand, and essentially distinct experiences, the appropriate solution is to create a new Business Unit for the new brand.

A separate Business Unit provides:

• Isolated content, templates, and assets, ensuring the new brand's emails and landing pages do not inadvertently reference or resemble the existing brand.
• Separate sender profiles, From Names, and potentially separate sending domains, reinforcing distinct brand identity in outbound communications.
• Independent management of subscriber lists, journeys, and campaigns specific to the new brand, without mixing them with the existing brand's data, content, or setup.

This is the standard recommended approach when an organization is managing multiple distinct brands that need to operate independently within the same Marketing Cloud account, particularly when brand separation and distinction are stated business requirements.

Why the other options are wrong:

B. A Private Domain: A Private Domain only addresses the sending domain and URL branding aspect, such as customized links. It does not provide the broader separation needed for content, templates, sender identity, and the overall brand experience. It is a partial solution rather than a comprehensive one.

C. A second SAP (Sender Authentication Package): A second SAP for the existing Business Unit would provide an additional dedicated IP and sending domain, but it does not inherently separate content, templates, or the overall brand experience. A new dedicated IP might not even be necessary depending on sending volume, and it does not solve the core requirement of distinct brand identity and content separation.

D. An SSL Certificate: An SSL Certificate relates to security and encryption for domains, such as securing landing pages or tracking domains. It does not provide brand separation or distinct content and styling between two brands.

Reference:
Salesforce Help — Enterprise 2.0: Business Unit Structure documentation, which recommends creating separate Business Units when an organization manages multiple distinct brands requiring independent content, sender identities, and audience management to maintain brand separation and prevent cross-brand contamination.

Explanation:

Multi-Location Franchise Architecture: In Salesforce Marketing Cloud, structuring an account for a franchise network requires balancing central brand governance with localized autonomy.

Why Separate Child Business Units: Creating one parent business unit managed by corporate alongside individual child business units for each franchise owner allows the corporate office to maintain control over global messaging, master subscriber lists, and overarching brand standards. Simultaneously, it grants individual franchisees a secure, segregated space to access their local data, manage regional customer relationships, and append localized content or offers to campaigns without interfering with other franchise locations.

Why the other options are incorrect:

Option A is incorrect: Combining all franchise owners into a single shared child business unit destroys data isolation, making it impossible to separate local customer bases, permissions, or localized messaging per franchise location safely.

Option B is incorrect: A single business unit provides zero isolation or granular permission controls, risking cross-contamination of local data and giving franchisees unrestricted access to global administrative settings.

Option D is incorrect: Shared folders within a single business unit only organize content assets. They do not enforce security boundaries, permissions, or data segregation between independent franchise owners.

Reference:
Salesforce Marketing Cloud Documentation: Multi-Org and Business Unit Design Best Practices

Explanation:

NTO's marketing team has very little coding experience and currently relies on Excel and VLOOKUP to create audience segments. They need a solution that allows marketers to create and maintain segments without SQL or programming knowledge.

Data Filters are designed for this type of marketer-friendly segmentation. They allow users to define filtering criteria through the Marketing Cloud interface, such as:

• Customer attributes
• Demographic information
• Engagement-related fields
• Other Data Extension values

This makes Data Filters a good fit for long-term self-service segmentation because the marketing team can modify segmentation criteria without depending on a technical resource to write SQL queries.

Why the other options are incorrect:

A. Query Activities — Incorrect: Query Activities use SQL to select, transform, and segment data. They are powerful and scalable, but they require SQL knowledge, which conflicts with NTO's requirement for a team with very little coding experience.

B. Publication Lists — Incorrect: Publication Lists manage subscriber subscription preferences, such as allowing subscribers to opt out of a particular type of communication. They are not intended to replace Excel or VLOOKUP-based audience segmentation.

C. Data Filters — Correct: Data Filters provide a point-and-click segmentation method that marketers can manage themselves. This reduces reliance on technical resources and supports long-term self-sufficiency.

D. Attribute Groups — Incorrect: Attribute Groups are used in Contact Builder's data model to define relationships between Data Extensions and organize contact data. They do not provide the marketer-friendly audience segmentation functionality required here.

Explanation:

For password reset emails, speed and reliability are critical.

The Transactional Messaging API in Marketing Cloud is purpose-built for real-time, API-driven sends such as order confirmations, password resets, and account alerts.

It ensures:
• Immediate delivery of the email.
• Notification back to the web server via the Event Notification Service (ENS), confirming when the email is sent or if it fails.

This combination makes it the best solution for NTO's requirement.

Why not the other options?

B. Multi-Step Journey with API Event entry source: Journeys introduce orchestration delays and are not suitable for urgent transactional sends such as password reset emails.

C. Triggered Send Definition: This is a legacy approach and is generally less flexible compared to the Transactional Messaging API for modern real-time transactional messaging requirements.

D. Email Send Activity: Email Send Activity is used in Automation Studio for batch sends rather than real-time transactional messages.

Reference:
Salesforce Help: Transactional Messaging API
Salesforce Help: Event Notification Service (ENS)