Skip to main content

Practice exam · AWS

AWS Data Analytics Specialty DAS-C01 practice exam

65
questions
130
minutes
75%
to pass the practice exam
137
questions in the bank

Short answer

The AWS Data Analytics Specialty DAS-C01 practice exam has 65 questions in 130 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

  • Analysis and Visualization
  • Collection
  • Processing
  • Security
  • Storage and Data Management

Sample questions, with explanations

Three questions from the bank, open to read.

Question 1 · Analysis and Visualization

A retail analytics team stores 4 years of clickstream data as Parquet in Amazon S3, totaling 60 TB. Analysts query the data with Amazon Athena, almost always filtering by event_date and country. Current queries scan the entire dataset because the table is unpartitioned, producing 30-second runtimes and high per-query cost. The team wants to minimize both query latency and the amount of data scanned with the least ongoing operational effort. Which approach best achieves this?

  1. Convert the Parquet files to CSV and enable Athena result reuse so repeated queries return cached results without rescanning S3.
  2. Recreate the table partitioned by event_date and country, write data into the matching Hive-style S3 prefixes, and run partition projection (or periodic MSCK REPAIR) so Athena prunes to only the relevant partitions. ✓ (correct)
  3. Index the full dataset into Amazon OpenSearch Service and have analysts run the date/country filters as OpenSearch queries for low latency.
  4. Load the entire 60 TB dataset into an Amazon Redshift cluster and add country as the DISTKEY so analysts query through Redshift instead of Athena.
Why this is correct

Partitioning the table by the exact columns used in WHERE filters (event_date and country) lets Athena prune to only the matching S3 prefixes, so a query touching one day and one country scans a tiny fraction of the 60 TB instead of all of it — this directly cuts both latency and scanned-bytes cost, and partition projection eliminates the operational overhead of catalog maintenance. Loading 60 TB into Redshift adds a cluster to provision and manage for what is an ad-hoc S3 query workload, and DISTKEY governs node distribution, not the scan reduction the question needs — it is heavier operationally, not lighter. OpenSearch is built for full-text search and log analytics with high ingest/storage cost; ingesting 60 TP of historical Parquet just to apply equality filters is an expensive, wrong-engine choice. Converting Parquet to CSV makes things worse — CSV is row-based and uncompressed relative to columnar Parquet, so Athena would scan far MORE data; result reuse only helps identical repeated queries, not the varied date/country filters described.

Question 2 · Collection

A data engineer is sizing an Amazon Kinesis Data Streams stream for a new pipeline. Producers will write 4 MB of data per second across roughly 3,000 records per second, and a single application will consume the data using the standard (shared-throughput) GetRecords API. Each shard supports 1 MB/s or 1,000 records/s for writes and 2 MB/s for shared reads. What is the minimum number of shards required to avoid throttling?

  1. 3 shards, because the 3,000 records/s divided by the 1,000 records/s per-shard limit is the binding constraint.
  2. 2 shards, because the 4 MB/s read demand divided by the 2 MB/s per-shard read limit determines the requirement.
  3. 1 shard, because Kinesis Data Streams automatically scales shard capacity to match producer load.
  4. 4 shards, because the 4 MB/s write rate divided by the 1 MB/s per-shard write limit is the binding constraint. ✓ (correct)
Why this is correct

Shard sizing must satisfy the most restrictive (binding) limit across all dimensions. Writes need ceil(4 MB/s ÷ 1 MB/s) = 4 shards and ceil(3,000 rec/s ÷ 1,000 rec/s) = 3 shards; shared reads of 4 MB/s need ceil(4 ÷ 2) = 2 shards. The maximum of these is 4, so 4 shards is the minimum to avoid throttling — the data-volume write limit dominates. The 3-shard answer is wrong because it only satisfies the records-per-second constraint (3 shards) and ignores that 4 shards are needed for the 4 MB/s write volume, so producers would still be throttled. The 2-shard answer is wrong because it sizes only for read throughput and ignores the larger write requirement. The 1-shard answer is wrong because standard (provisioned) Kinesis Data Streams does not auto-scale shards to match load; you must provision shards (or use the separate on-demand mode), and a single shard caps at 1 MB/s, far below the 4 MB/s ingest.

Question 3 · Collection

An application ingests events through Amazon Kinesis Data Streams. Five separate downstream teams each need to consume the full stream independently and in real time, and each consumer must receive its own dedicated read throughput of up to 2 MB/s per shard without competing with the others or increasing read latency as more consumers are added. Which configuration meets this requirement?

  1. Register each consumer as an enhanced fan-out consumer so each gets a dedicated 2 MB/s per-shard throughput pipe via the SubscribeToShard API. ✓ (correct)
  2. Switch the data stream to on-demand mode, which automatically gives every consumer isolated read throughput.
  3. Have all five consumers share the standard GetRecords API and increase the shard count fivefold to compensate for contention.
  4. Place an Amazon Kinesis Data Firehose delivery stream between the data stream and each consumer so Firehose multiplexes reads.
Why this is correct

Enhanced fan-out is the Kinesis Data Streams feature designed exactly for multiple consumers needing isolation: each registered consumer gets its own dedicated 2 MB/s-per-shard pipe pushed via SubscribeToShard (HTTP/2), so adding consumers does not reduce throughput or raise latency for the others. The shared-GetRecords option is wrong because the standard read limit of 2 MB/s per shard is shared across all consumers; five consumers on shared reads contend for that bandwidth, and merely multiplying shards is costly and still does not give each consumer guaranteed isolated throughput the way enhanced fan-out does. The Firehose-in-between option is wrong because Firehose is a delivery service to fixed destinations, not a mechanism to give five independent real-time consumers their own isolated read streams. The on-demand mode option is wrong because on-demand only changes how shard capacity for writes is provisioned and billed; it does not, by itself, grant each consumer dedicated read throughput — you still register enhanced fan-out consumers to get per-consumer isolation.

Take the full practice exam

  • 65 questions drawn from the bank, with a 130-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
Start the practice examStudy the path first

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 Data Analytics Specialty DAS-C01 practice exam have?

It has 65 questions and a 130-minute limit. The passing mark of the practice exam is 75%.

Is this the official AWS Data Analytics Specialty DAS-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.