Practice exam · AWS
AWS Machine Learning Specialty MLS-C01 practice exam
Short answer
The AWS Machine Learning Specialty MLS-C01 practice exam has 65 questions in 180 minutes, with a 75% passing mark, as configured here. The fastest way to know whether you are ready is to sit a full exam on the clock and read your score by domain, not only the total.
Domains covered
- Modeling
- Exploratory Data Analysis
- Data Engineering
- Machine Learning Implementation and Operations
Sample questions, with explanations
Three questions from the bank, open to read.
A ride-hailing platform feeds live GPS pings into an ML feature pipeline that computes a per-driver rolling average speed. Each driver emits roughly 30 events per second, and the data science team requires that all pings from the same driver be processed in the exact order they were generated so the rolling window is correct. The team uses Amazon Kinesis Data Streams to ingest the pings. Currently every producer call uses a freshly generated random value for the partition key, and the team notices that windows for individual drivers occasionally compute out of order. What change will guarantee per-driver ordering?
- Increase the number of shards in the stream so each driver effectively gets its own shard and ordering is preserved automatically.
- Switch the stream to on-demand capacity mode, which automatically routes records from the same producer to a single shard.
- Enable enhanced fan-out for the consumer so each consumer receives a dedicated throughput pipe that reorders records by timestamp.
- Set the partition key for every record to the driver's unique ID so all of a driver's pings hash to the same shard, where Kinesis preserves order. ✓ (correct)
Why this is correct
Kinesis Data Streams guarantees ordering only within a single shard, and the partition key is what determines which shard a record lands in. Using the driver's unique ID as the partition key ensures every ping from that driver maps to the same shard and is therefore consumed in arrival order, which is exactly what a correct rolling window requires. Using a random partition key (the current bug) scatters a driver's pings across shards, destroying per-driver order. Increasing shard count does not assign one shard per driver; the hash distribution still spreads keys, and a single random key would still scatter records, so more shards alone fixes nothing. Enhanced fan-out only gives each consumer a dedicated read throughput pipe; it does not reorder records and ordering is still per-shard. On-demand capacity mode changes how throughput scales, not how partition keys map to shards, so it does not route a producer's records to one shard or fix ordering.
A SaaS platform serves a separate churn model for each of its 2,000 tenants. Each model is about 200 MB, and at any given hour only a small, unpredictable subset of tenants generate prediction traffic. The team wants to serve all tenant models behind one endpoint, paying for shared infrastructure rather than 2,000 always-on endpoints, while still routing a request to the correct tenant's model by name. Which option meets this need?
- A separate real-time endpoint per tenant, each with autoscaling enabled
- A Batch Transform job per tenant scheduled hourly
- A multi-model endpoint that loads tenant models from S3 on demand and caches the hot ones in memory ✓ (correct)
- A single production variant hosting one shared model for all tenants
Why this is correct
A multi-model endpoint (MME) is built for exactly this case: many models that share a common framework live in S3, the endpoint dynamically loads a model into memory when first requested, caches frequently used ones, and routes each request to the right model by the TargetModel name — so you pay for one fleet instead of 2,000 endpoints, and rarely used tenant models impose almost no idle cost. Running 2,000 separate real-time endpoints is precisely the cost and operational explosion MME is designed to eliminate. A single shared production variant would serve one model to everyone, which violates the requirement that each tenant has its own model. Batch Transform is offline file scoring and cannot serve the per-request, by-tenant online predictions the platform needs, and scheduling 2,000 hourly jobs is operationally absurd for sparse, unpredictable traffic.
A team uses SageMaker linear-learner on a 500-feature dataset that is mostly zeros (sparse). They currently feed dense CSV and training is slow and memory-heavy. They want a more efficient on-the-wire format that the built-in algorithm reads natively and that exploits sparsity. Which format should they convert the training data to?
- Parquet with run-length encoding, which the linear-learner built-in algorithm reads natively for sparse input.
- JSON Lines with one object per record, since structured JSON compresses sparse data automatically.
- RecordIO-wrapped protobuf using the sparse tensor representation, which linear-learner reads natively and which avoids materializing zero values. ✓ (correct)
- A single dense NumPy .npy file uploaded to S3, which the algorithm memory-maps to skip zeros.
Why this is correct
RecordIO-protobuf is the optimized binary format for SageMaker built-in algorithms like linear-learner and factorization-machines, and its protobuf tensor encoding supports a sparse representation that stores only non-zero index/value pairs — exactly what a 500-feature mostly-zero dataset needs to cut memory and speed up training. JSON Lines is verbose text, is not a high-throughput training format for these algorithms, and does nothing special for sparsity. Parquet is a fine analytics/storage format and some algorithms accept it, but linear-learner's efficient training path and explicit sparse-tensor support is RecordIO-protobuf, not Parquet RLE — the premise that linear-learner reads Parquet sparse natively is the misconception. A dense .npy file by definition stores every zero, so it neither exploits sparsity nor is the recommended SageMaker input format; memory-mapping does not skip zeros that are physically present in a dense array.
Take the full practice exam
- 65 questions drawn from the bank, with a 180-minute timer
- Score by domain and a review of every question
- An AI tutor to talk through each question you miss
- What you miss feeds your study plan
Independent, unofficial practice exam. AWS and the exam name are trademarks of their owners; UpSkillScore is not affiliated with them. Format and passing mark are the exam's configuration in UpSkillScore, not an official statement.
Frequently asked questions
How many questions does the AWS Machine Learning Specialty MLS-C01 practice exam have?
It has 65 questions and a 180-minute limit. The passing mark of the practice exam is 75%.
Is this the official AWS Machine Learning Specialty MLS-C01 exam?
No. It is an independent practice exam built to match the structure of the real one. It does not replace the official exam.
Do I need an account to take it?
You can read the structure and sample questions without an account. Taking the full timed exam, scoring by domain and the AI tutor need one.