Explanation:

The scenario describes a classic use case for a relational data model. The core principle is to separate distinct data subjects into their own tables to maintain data integrity, simplify updates, and avoid creating a single, monolithic, and difficult-to-manage table.

Separate Data Extension: The new dataset, which is updated via separate data feeds, should reside in its own Data Extension (DE). This isolates its update cycle and schema from the main contact DE.

Linking via Relationship: This new DE must be linked to the existing contact DE within Contact Builder. This is done by defining a relationship using a shared key (e.g., SubscriberKey or CustomerID). This link allows you to query and reference data across both DEs as if they were joined, enabling integrated segmentation and personalization without physically combining the data.

This configuration is optimal because:
- Maintains Data Integrity: Updates to contact info don't affect the new dataset, and vice versa.
- Optimizes Performance: Independent data feeds can update their respective DEs efficiently.
- Enables Scalability: Additional related datasets (e.g., purchase history, survey responses) can be added using the same pattern.

Why the Other Options Are Incorrect:

A. Create additional attribute fields in the main contact data extension: This is the "wide table" anti-pattern. It leads to a bloated, inflexible main DE. Every time the new dataset updates, it would require updating potentially hundreds of fields in the main DE, which is inefficient, prone to error, and difficult to maintain. It also doesn't handle scenarios where a contact has multiple records in the new dataset (e.g., multiple purchases).

B. Create new Salesforce data extension and link it to the other data extensions: A "Salesforce Data Extension" is a specific type of DE that is a synchronized, read-only copy of a Salesforce object. The scenario describes generic "data feeds," not necessarily a sync from Salesforce. Therefore, recommending this specific type is incorrect; a standard Data Extension is what's needed.

D. Create a new data extension and link It as a new population: The phrase "link it as a new population" is not standard terminology in Marketing Cloud data modeling. In Contact Builder, you link DEs to establish data relationships, not to define them as populations. A "population" in Contact Builder refers to the set of all contacts defined by the attribute groups and relationships, not the act of linking tables.

References:
Marketing Cloud Contact Builder Documentation: "Create a Data Relationship" – Details the process of linking Data Extensions via a primary key to build a relational model.

Trailhead Module: Marketing Cloud Consultant > Data Modeling in Marketing Cloud – Teaches the principles of relational design, emphasizing the creation of separate, linked Data Extensions for different data subjects and update frequencies.

Architect Best Practices: "Marketing Cloud Data Architecture" guides consistently advise against wide, flat tables and recommend a normalized, linked structure for scalability.

Explanation:

Why B is the recommended hierarchy

The restaurant franchise has the following key requirements:

- Corporate wants to create and control the main campaign content and strategy.
- Each franchise owner must be able to add a localized/custom message (e.g., store-specific offer, address, phone number, manager’s note) to the same email.
- Franchisees should not see or modify each other’s local content, subscriber data, or tracking.
- Corporate needs oversight and brand consistency.

In Marketing Cloud Enterprise 2.0, the only scalable way to allow local users to safely insert their own content into a corporate-approved email while keeping everything isolated is:

Parent BU – Corporate headquarters:
- Owns master content templates, images, main campaign logic, sender profiles, SAP/IP, etc.

One child BU per franchise owner:
- Franchisee logs in only to their own BU.
- Corporate shares the base email (via Content Builder “Shared” folders) or uses Dynamic Content Blocks + Slot-based templates.
- Franchisee edits only their local slot/block (e.g., “Local Offer” content block) inside their BU.
- When the send is executed from the parent (or from the child BU using the shared template), the franchisee’s localized version automatically appears for subscribers routed to that BU.

This model is the standard Salesforce-recommended franchise setup.

Why the other options fail

A. One parent + only one child for all franchise owners ❌
All franchisees share the same BU → they can see and overwrite each other’s local messages → not acceptable.

C. One business unit only ❌
No isolation at all. Every franchisee sees everyone else’s content and subscriber data → major security and branding risk.

D. A parent business unit for each franchise owner ❌
Impossible and unnecessary. You can only have one parent (top-level) BU per account.

Reference
Salesforce Help – Business Units for Franchises and Multi-Brand Scenarios

Therefore, the correct and recommended hierarchy is B.

Explanation:

Here’s why:
The scenario is about designing a custom dynamic template that lets a small team build and send a daily promo email in under an hour, highlighting new inventory every day. The key to making that efficient is how flexible (or fixed) the layout needs to be.

✅ B. How often will the layout of the content in a content area change?
This is directly relevant to template strategy:
If the layout rarely changes, you can:
Build a rigid, highly automated template with predefined content blocks.
Let users just swap products (images, prices, links) quickly.

If the layout changes frequently (e.g., different product grid each day, different hero structure):
You’ll need a more modular, flexible template.
Possibly more dynamic rules, multiple content areas, or even different template variants.

This question helps decide how sophisticated and flexible the custom template needs to be to keep build time under an hour.

❌ Why the others are correct:

A. Will image URLs be available publicly?
Usually, website CMS images used in emails must be public, and they already said images are hosted on the CMS.
This is more of a technical hosting question, not a driver of template design strategy.

C. What is the maximum file size of the images being used?
Important for load times and deliverability best practices, but it doesn’t shape the structure or modularity of the template.

D. How often will email content be image-only with text overlaying images?
Somewhat design-related, but more about creative style than about how to architect a dynamic daily-use template.

E. What from name will be used for these emails?
That’s a send configuration detail, not related to designing the template itself.

So the most relevant question for designing the custom dynamic template is:
B. How often will the layout of the content in a content area change?

Explanation:

✅ Why A is correct
Marketing Cloud + Service Cloud (via Marketing Cloud Connect) provides native Salesforce Activities inside Journey Builder, including the ability to:
- Create a Case in Service Cloud
- Update Salesforce records
- Trigger Salesforce automation
Since NTO wants to leverage as much native functionality as possible, Journey Builder is the correct solution.
The recommended flow:
- Collect feedback (via CloudPage, email click, survey link, etc.).
- In Journey Builder, use an Engagement Split or Decision Split to check whether feedback is “unhappy.”
- Use a Salesforce “Create Case” Activity to automatically open a case in Service Cloud for unhappy customers.
This uses native, out-of-the-box integration—no coding or custom integration needed.

❌ Why the others are incorrect
B. Use Automation Studio + Case Activity
Automation Studio doesn’t support Salesforce “Create Case” activities.
Salesforce Activities are only available in Journey Builder.
Automation Studio is for data processing—not for Service Cloud object creation.

C. Use an AppExchange package for a custom API integration
Unnecessary.
Salesforce already provides native integration for creating Cases using Journey Builder.

D. Engagement Split + Custom Activity
A Custom Activity requires development (node.js + MC app).
This is not “using as much native functionality as possible.”
Native Salesforce “Create Case” Activity already exists—no need to build custom.

Explanation:

Why C is correct
The requirements:
All email open and click activity must be pulled daily.
Use system data views like _Open and _Click in a SQL Query Activity in Automation Studio.
Schedule this automation to run daily and query all relevant engagement since the last run (or within a specific time window).
Output files must meet the specific requirements for the data warehouse.

With a SQL Query Activity, you can:
Choose exactly which fields to include.
Rename columns.
Cast/format data types to match DW specs.
Combine opens and clicks into one target data extension if needed (e.g., via UNION or mapping an “ActivityType” column).
The query writes into a staging data extension that matches the exact schema required by the data warehouse.

All the activity must be provided via SFTP in one file.
After populating the DE with the query:
A Data Extract Activity (Data Extension Extract) creates a file (e.g., CSV) from that DE.
A File Transfer Activity then moves that file to the customer’s SFTP location.
Since the DE is already shaped for “one file,” the extract gives you exactly that: one daily file with all required rows and columns.

So the flow is:
SQL Query (data views → DE)
➜ Data Extension Extract (DE → file)
➜ File Transfer (file → SFTP)
Which is exactly option C.

Why the others are not right
A. Data Extract Activity of Tracking Extracts that combines data into required file > File Transfer Activity ❌
Tracking Extracts:
Output fixed-format files (one per activity type like clicks, opens, bounces, etc.).
Do not let you fully control the schema to arbitrary DW requirements.
Typically generate multiple files, not “one combined file” with custom structure.
You also can’t “combine into required file” purely inside the Tracking Extract step the way the option suggests.

B. Report activity that generates Recent Send Summary report > Report delivered directly to SFTP ❌
Recent Send Summary is a summary report, not detailed open & click activity per event.
It does not provide all open and click events at the granularity usually needed for a data warehouse.
Limited flexibility in field selection and format, so it won’t meet “specific requirements” in most DW scenarios.

D. Data Extract Activity of data view tables > SQL Query Activity to create the required file > File Transfer Activity ❌
You cannot run a Data Extract directly on data view tables; they are only accessible via SQL queries.
Also, SQL Query Activities work on data extensions, not on flat files created by a Data Extract, so the order in this option is backwards.

So the only workflow that truly matches daily, custom schema, and single SFTP file is:
✅ C. SQL Query Activity → Data Extension Extract → File Transfer Activity