The estate, laid out by category
Lesson 2 of 4 in The Data Service Map.
Start by auditing the number in that title, because it is the first lesson of this page. The published in-scope list is organised into fourteen categories, and the figure of about ninety comes from counting every bullet on the page — including the fourteen in its own index at the top. Count only the service entries and there are 77; of those, two are duplicates (one analytics service is listed again under machine learning, and one storage entry appears twice in its own category), so the real figure is 75 distinct offerings. The number is not the point, but checking it is: this is the kind of page people quote from memory, and a study plan built on a number nobody verified is how you end up revising a service that is not on the exam.
What matters is that 75 names is unlearnable as a list and trivial as a map. Every one of them is standing at one of the seven stations from the previous lesson. So the useful exercise is not memorising the list — it is being able to answer, for any name you meet, which station is this, and what is the one job it does better than its neighbour.
A second thing the categories tell you, which the raw list hides: the estate is not fourteen equal parts. Analytics, Database and Storage between them hold 27 of the 75 entries and carry most of the paper. Four categories hold one, two or three entries each and are there because a pipeline touches them in passing.
| Category | Entries | Its job on the spine | What actually gets tested |
|---|---|---|---|
Analytics | 12 | Ingest, transform, catalog and serve — most of the spine lives here. | The pairs that compete: a durable stream against a managed delivery stream, a serverless job against a cluster, a lake query engine against a warehouse. Also stream processing in flight, and the permissions layer over the catalog. |
Database | 8 | Store — both the operational sources you ingest from and the stores you serve to. | Choosing between relational, key-value, in-memory, document and graph from the access pattern; the warehouse as the analytical store; and change data capture out of a relational source. |
Storage | 7 | Store — the lake’s floor, plus backup and the block and file stores a cluster mounts. | Storage classes and their retrieval bargains, lifecycle transitions and expiry, versioning, and object-level table storage. Roughly: if a question is about cost at rest, it is here. |
Management and Governance | 8 | Observe and govern — metrics, logs, configuration history, audit, and a data marketplace. | Which service answers which question: a metric and an alarm, an application log, an API call record, the configuration a resource had at a past moment. |
Application Integration | 6 | Orchestrate — the schedulers, the event router, the queues, the workflow engines. | The orchestrator comparison, event-driven triggers versus schedules, and a queue used to decouple a fast producer from a slow consumer. |
Migration and Transfer | 6 | Ingest — getting data in from somewhere that is not already AWS. | Database replication and ongoing change capture, bulk file transfer between on-premises and object storage, managed file-transfer endpoints, and physical transfer when the network cannot carry the volume in time. |
Developer Tools | 7 | Across the spine — how the pipeline gets defined, built and deployed. | Infrastructure as code for repeatable deployment, a build-and-deploy pipeline for data jobs, and the command-line and assistant tooling that appears in stems rather than being configured. |
Security, Identity, and Compliance | 6 | Govern — who may act, with which keys, over which data. | Roles for pipelines, key management for encryption at rest, credential storage and rotation, and sensitive-data discovery. Edge protection appears but is thin here. |
Compute | 4 | Transform — the engines that are not analytics services. | A function for small event-driven work and where it stops being the right answer; managed batch computing for container jobs; and an instance when a workload needs one. |
Networking and Content Delivery | 4 | Govern — keeping traffic off the public internet, and naming things. | Private connectivity to a service endpoint instead of an internet path, and the network boundary a job runs inside. Content delivery is background rather than examined depth. |
Containers | 3 | Transform — where a transformation ships as an image rather than a job. | Optimising container usage for a processing workload, and the registry that holds the image. Orchestrator internals are not the subject; the data job inside is. |
Machine Learning | 3 | Serve — the consumer the pipeline feeds, plus vector and assistant features. | Preparing data for a model rather than training one, vectorisation and vector index types, a managed search index, and using a foundation model as a processing step. Training and inference are out of scope. |
Cloud Financial Management | 2 | Observe — cost as an operational signal. | Noticing that a pipeline got expensive, and alerting on it before the invoice does. Two entries, and both are about watching rather than optimising. |
Web and Mobile | 1 | Ingest and serve — the API front door. | Consuming a data API, and exposing one over your own data. One entry, and it is there because "consume data APIs" is a named capability. |
Interactive sorting exercise: Place each service at the station where it does its one job. Several could plausibly sit at two — put it where it is *the* answer, not where it could appear.
Why are containers, machine learning and cost management even on this list?
Because a real pipeline touches them, and because the capabilities named for this exam say so.
Containers are there because a transformation sometimes ships as an image rather than as a managed job, and optimising container usage for a processing workload is named explicitly. You are not being asked to run a cluster; you are being asked why a job is slow inside one.
Machine learning is there in a deliberately narrow way: preparing data for a model, vectorisation and vector index types, a managed search index, and using a foundation model as a processing step. Training and inference are named as out of scope — so the ML entries are consumers of your pipeline, not work you do.
Cost management is two entries, and both are about noticing: a budget that alerts, and a tool that explains where spend went. Treat cost as an operational signal in the same bucket as a metric and an alarm.
The out-of-scope list is a usable filter — read it once
A second published list names what is out of scope, and reading it once is worth more than it sounds, because several entries are services you might reasonably expect: application hosting platforms, a distributed tracing service, a frontend data-synchronisation layer, media processing, and the whole device-management family. If an option proposes one of those for a data pipeline, it is almost certainly there to be rejected.
The list also records that a handful of names came off it because the services themselves were deprecated or renamed — which is a reminder that the service estate moves faster than any study guide, and that a name you cannot find in either list may simply have changed.
Two naming traps on the current list
The visualisation service answers to two names. The in-scope list carries the newer short name while the content that describes visualising data uses the older one. They are the same product; recognise both, because a practice item or a colleague may use either.
Schema conversion is still examined, and its standalone tool is not on the list. The capability — converting a schema when migrating between engines — is named, and the migration service performs it; the separate conversion tool was removed from the in-scope services. So learn the capability and expect it inside the migration service, rather than revising a tool that is no longer listed.
The general lesson is the one worth carrying: when a service list and a capability description disagree, the capability is the thing being tested. A question can ask you to convert a schema; it cannot ask you which console button a delisted tool used.
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.