Study guide
Dieser Inhalt ist noch nicht in deiner Sprache verfügbar.
Study guide for chapter 2 of the Data 360 Architect course. Read the six modules first; this page helps you check what stuck.
About this study guide. It’s built only from this course’s own content and the published Salesforce exam guide’s list of objectives. It is never based on real exam questions, and it doesn’t claim to know what’s on the exam. If you’ve taken the exam, please don’t send me questions from it: the certification agreement forbids sharing them, and memorizing answers is the wrong way to become an architect anyway.
This course covers the Data 360 Consultant exam, but the exam is just a step on the road. As architects, we go beyond it, to a deeper understanding of the mechanisms and capabilities underneath. This chapter shows that more than most. The exam asks you to know Data 360’s key terms and the value it brings (SP-1); it doesn’t ask about Parquet or Iceberg by name. But the behavior those foundations explain, why data comes in as loads, why a type can’t change, why real time is separate, sits under questions all through the exam, and under every design decision you’ll make. So the consultant part of this page is short, and the architect part is the bigger one.
For the Consultant Exam
Section titled “For the Consultant Exam”What this chapter covers of the Data 360 Consultant exam guide (opens in a new tab)’s objectives. Tick them off as you go. Each one links to where it’s taught.
SP-1: Data 360’s key terms and business value
- I can say why Data 360 isn’t built on core, a relational database or NoSQL: the job is history and volume at low cost, analysis across everything, data others can read without copying, and a fast answer about one person. (First, why not something we already have?)
- I know Data 360 has two layers: a lakehouse for “large volumes of historical and batch data”, and a real-time layer for low-latency access. (Two layers, not one)
- I know a data lake object is a table: files in cloud storage, organized as a table, with Salesforce’s names and relationships on top. (What this explains in Data 360)
- I know Data 360 is built for analysis, not transactions, so it isn’t the system of record: you change data by changing what you feed it. (What it explains in Data 360)
Supports ING-2 and ING-3 (taught in chapters 4 to 6 and 15)
- I know that after a data lake object or data model object is created, a field’s data type can’t change; the fix is a new field. (What this explains in Data 360)
- I know every change, even a delete, comes in through the stream, and that deleting ingested records needs an upsert refresh mode. (Why every change comes through the front door)
- I know open formats (Parquet, Iceberg) are why zero copy works in both directions. (Why open formats matter)
As an Architect
Section titled “As an Architect”The consultant exam is the floor. This is what an architect takes from this chapter, beyond it: the habits that shape designs, whether or not a question ever asks about them.
- Know what it’s built on, so you can work with its limits. Without that, people see only the negatives: why can’t I change an API name, why is deleting so hard, why can’t I edit one record? (What Data 360 Sits On)
- Columns make queries faster; rows make the bill. Data 360 bills mostly by rows processed, so the levers are filters, incremental runs and slower schedules. (What the engines explain)
- Incremental is the cheap path, by design. The change feed says exactly what changed; a change to the rules (not the data) can force a full rerun. (Why an architect should care)
- A changed field leaves baggage. You deprecate the old field and add a new one, and both stay in the model. Decide names and types before the first load. (What this explains in Data 360)
- Old snapshots aren’t an archive. If the business needs years of history, model it as data. (What that means in Data 360)
- Tiny, constant loads aren’t free, even when ingestion is: every small file is one more to merge later. (What that means in Data 360)
- Ask three questions before you open a support case: lake or real time? A change to data, or to the shape? Where are the rows? (How to use it)
Words to Know
Section titled “Words to Know”| Term | In one line |
|---|---|
| Lakehouse | Files in cheap cloud storage, organized as tables, so they can be analyzed like a warehouse |
| Apache Parquet | An open file format that stores data column by column; a file is written once and read many times |
| Apache Iceberg | An open table format: it says which files make up a table now, its columns, and its history |
| Snapshot | The state of an Iceberg table after one write; a new write makes a new snapshot |
| Change data feed | The record of exactly what changed between snapshots, so work can be incremental |
| Compaction | Housekeeping that merges many small files into a few large ones; Salesforce runs it for you |
| Spark | The open-source engine that runs most of Data 360’s processing: transforms, insights, segment membership |
| Hyper | Tableau’s SQL engine, used to answer analytical queries fast |
| Real-time layer | Memory plus the low latency store, for answers about one person in milliseconds |
| Low latency store | Salesforce’s “petabyte scale NVMe (SSD) storage layer”, under the real-time layer’s memory |
Check Yourself
Section titled “Check Yourself”Short scenarios in the style of the course. Decide your answer before you open it.
1. A team wants Data 360 to be the master copy of customer data, so people can correct a wrong value right there. What do you tell them?
Data 360 isn’t the system of record. Its lake is built for loads, not edits, and the next load from the source would bring the old value back. Fix the value at the source, and the stream carries the change in. Reread Why every change comes through the front door.
2. A field came in as text and should have been a number. Someone asks you to just change its type. What happens, and what do you do?
You can’t change a field’s type after the object exists. Add a new field with the right type, map it, and deprecate the old one, knowing both will stay in the model. Reread What this explains in Data 360.
3. To save credits, someone proposes cutting a transform's columns from 40 to 10. Will it help?
It makes the work faster, but it doesn’t cut the bill much: most of Data 360’s billing counts rows processed, not columns. Process fewer rows instead: filter early, run incrementally, schedule less often. Reread What it explains in Data 360.
4. A website needs to show an offer based on what the visitor did in the last minute. Is a calculated insight on the lakehouse the right tool?
No. The lakehouse works in minutes and hours; one person in milliseconds needs the real-time layer, with its own design and limits (chapter 13). Reread Why milliseconds need a second layer.
5. A small batch transform processing ten rows still takes several minutes. Is something wrong?
Probably not. Every run is a job: the platform finds machines, starts Spark, reads files and writes new ones, whatever the row count. Don’t expect seconds from a batch job. Reread What the engines explain.
6. Your company's data team says "our lake is Iceberg on S3." Why does that matter for a Data 360 design?
Data 360’s lake is built from the same open formats, so it can read their tables where they sit, and they can read Data 360’s: zero copy (chapter 15). The housekeeping on their tables is then their job. Reread Why open formats matter.
Explore
Section titled “Explore”- Salesforce Certified Data 360 Consultant Exam Guide (opens in a new tab), Salesforce Help (checked 2026-11-14): the official list of objectives and their weights. Always check the current version before you book the exam.
- Data 360 Architecture (opens in a new tab), Salesforce Architects: the chapter’s main source.