AWS Certified Data Analytics – Specialty (DAS-C01) is a retired certification. AWS ended the exam in April 2024, with April 8, 2024 as its last testing day. You cannot book a new DAS-C01 appointment or renew it by taking the same examination. That does not make the architecture behind the credential obsolete: teams still need reliable ingestion, transformation, storage, analytics, access control and monitoring. The useful question in 2026 is how to turn those skills into demonstrable work—and which currently offered credential, if any, matches your role.
Why this exam is historical, not a current booking route
The former Specialty exam combined a broad cross-service perspective with deep operational decisions. It rewarded knowing when an ingest pipeline needed buffering, when batch and stream computations diverged, and how security and cost assumptions changed at scale. Old DAS-C01 courses may remain a useful conceptual index, but question pools and vendor naming can lag behind today’s offerings. Label practice materials historical, check each service’s current documentation and never treat a score on a retired mock exam as evidence of readiness for a different certification.
AWS introduced its Data Engineer – Associate pathway as part of the portfolio shift. That exam is a separate certification with its own published blueprint and eligibility rules, not a rebadged DAS-C01. A data analyst who mainly prepares dashboards might instead benefit more from working knowledge of SQL, dimensional models and business metrics than from pursuing an infrastructure-heavy credential. A platform engineer should prioritize failure recovery, least-privilege roles and pipeline observability. Choose by responsibilities rather than by similarity of the exam names.
Model a real ingestion problem before choosing services
Consider an ecommerce team receiving purchase events from applications and hourly catalog snapshots from suppliers. It needs a near-real-time operational dashboard and an auditable month-end report. Draw the data path from producers through buffers to durable raw storage, processing and curated output. Specify who may publish data, the expected event volume, late arrival tolerance, and how duplicates are identified. The first architectural decision is not which logo goes on the diagram; it is what data the business can afford to lose or count twice.
An event stream may be attractive when latency matters, but continuous processing introduces state, replay, checkpoint and schema-evolution questions. For modest scheduled feeds, a simpler batch process can reduce operational complexity. Compare both against measured latency, recovery and cost requirements. If a producer retries after a timeout, decide whether the consumer can recognize an event ID and make writes idempotent. An “exactly once” marketing phrase should never substitute for inspecting where acknowledgement, storage and downstream side effects occur.
Separate raw, curated and serving data
Retain the original events with controlled retention, partitioning and provenance where policy permits. Then build curated tables with explicit definitions for returns, currency conversion, test transactions and late cancellations. A dashboard query that sums raw purchases can look plausible while overstating revenue. Data correctness depends on business semantics just as much as on AWS service selection. Build data-quality checks that flag duplicate keys, impossible timestamps, unexpected nulls and disagreements with the transaction ledger.
Use a workload-based choice among object storage, interactive query engines, warehouses and operational databases. Object storage is flexible and durable but does not automatically provide a low-latency serving model. A warehouse improves governed analytic workloads but needs distribution and query design. A low-latency operational lookup may require a different access pattern. Document why a given consumer uses a particular store; avoid copying every dataset into every technology by default.
For a realistic architecture exercise, assume orders arrive continuously while fulfillment updates arrive in hourly batches. Sketch the full path from event producer to durable raw storage, transformation, cataloging and authorized consumption. Define an event identifier so that a retry cannot double-count a sale, and decide which records remain immutable when an upstream correction arrives. Query two representative partitions to confirm that the ingestion timestamp and business event timestamp are not confused. If a late event arrives after the daily report is published, specify whether the report is restated, annotated or held pending reconciliation. These are operational decisions a data engineer must defend; a diagram with service logos is not enough.
Make access controls testable
Data pipelines frequently handle identifiers, customer attributes and commercially sensitive information. Define who can read raw personally identifiable data, who can see aggregated reports, and which service identity can write curated tables. Use resource and identity policies according to the service’s actual authorization model. Encryption at rest does not by itself prevent a broadly privileged analyst from reading confidential rows. Test an expressly unauthorized role and retain evidence of the denial alongside authorized use-case tests.
For shared analytics data, consider catalog metadata, column-level restrictions, lifecycle rules and cross-account boundaries. Revalidate access whenever a dataset is joined or copied into a new serving system. A privacy classification made on a raw table is not automatically enforced after someone exports a CSV. A governance process is credible only when permissions follow the actual data path and failures trigger a response.
Access design should be demonstrated with three identities: an ingest service that can append incoming objects, a transformation role that can read raw data and write curated data, and an analyst who can only query approved outputs. Try a negative test in which the analyst requests a restricted customer column. A correct result is a denial enforced by the appropriate service and catalog policies, not a prompt asking the analyst to behave responsibly. Record the boundary between storage permissions and query-layer grants. For multi-account work, test what happens when a resource policy grants access but an identity policy or encryption-key policy does not. This exercise connects least privilege to observable authorization behavior rather than to an unverified checklist.
Practice recovering a failed analytics job
Run a controlled lab where the extraction succeeds but the transformation fails halfway through a partition. Before retrying, determine whether the failed step already created output. Can a replay overwrite only the affected partition? Will it double count records? Is the checkpoint tied to the same input offset and schema? Restore from a known-good dataset and compare source-to-target counts or hash totals. Write down your observed recovery time and the completeness of recovered records instead of simply declaring the pipeline resilient.
A second exercise should simulate a late schema change: an optional value becomes required or an upstream field is renamed. Capture the alert, quarantine the incompatible input, preserve the raw payload and test the corrected transformation before resuming. This gives better evidence of professional competence than memorizing a generic “best analytics service” answer. It also reveals whether you have reliable runbooks and enough telemetry for incident diagnosis.
Make the recovery rehearsal falsifiable. Interrupt a transformation after it writes some output, re-run the job, and compare row counts, duplicate keys and aggregate totals to a known reference. Then inject a schema change that is compatible for one consumer but breaks another. Your recovery design might use a quarantine location, validation before publishing a partition, replay from durable raw data and an operator-controlled promotion step. Explain why each step is safe under partial failure. Keep a log of input versions, job parameters, rejected records and completion signals so another engineer can reconstruct a bad result. The important competency is preventing silent corruption when automation reports success but the data is wrong.
Choose evidence, not an obsolete badge, for your portfolio
A concise portfolio project can demonstrate an architecture diagram, input contract, data-quality tests, a permission matrix, sample analytical queries, an operational dashboard and a documented recovery drill. Include cost drivers such as storage retention, scan volume, compute concurrency and network movement. Estimate spend from observed usage rather than unsupported universal cost comparisons. Keep sensitive test data synthetic and document any service quotas or regional behavior your exercise depends on.
Someone who previously earned the Specialty credential can still accurately list the award with its earned date and current credential status; they should not imply that the exam is bookable. For new study, consult AWS’s presently published data-engineering certification objectives and align preparation to the role you actually intend to perform. The durable outcome is the ability to explain trade-offs, protect data and recover bad results—not a promise that a retired examination will return.
When presenting this work, show evidence rather than a claim that one credential replaced another. An annotated system diagram should identify data movement, trust boundaries, retention decisions and measurable recovery behavior. Include one failed run and its corrected outcome, such as duplicate orders eliminated through idempotent processing. Compare the responsibilities demonstrated by the project with the published objectives of an active credential such as AWS Certified Data Engineer – Associate, but check AWS’s current exam guide before selecting any preparation materials. A candidate moving from the retired Specialty exam to a different role may need additional skills in orchestration, infrastructure automation or warehouse modeling. The right next step follows the job, not the historical label.
Cost analysis belongs beside correctness. Estimate how storage, data scans, transformation frequency, streaming throughput and warehouse concurrency change when a dataset grows or a reporting deadline moves. Test whether partition pruning actually reduces the amount of data scanned, rather than assuming a partitioned folder is automatically efficient. Consider what happens if a delayed upstream export forces a complete reprocessing run. The strongest architecture argument makes its assumptions explicit: acceptable reporting delay, recovery window, retention need, security boundary and expected query patterns. A portfolio can state which metrics were measured, which were estimated and which design options remain untested. That transparency is more useful than an unsupported promise of unlimited scalability or universally lowest cost.