D610 Data Engineering Capstone, catalog number DTAN 6223, is the three CU capstone that applies the WGU Master of Science, Data Analytics core together with the data engineering specialization to examine a problem and build cloud native infrastructure as the solution. Unlike the analytics capstone, the deliverable here is a working system, and the report exists to prove that the system was designed rather than assembled.
A built thing plus the reasoning behind it
The characteristic failure in an engineering capstone is a system that works and a report that describes it. Description is not justification. An evaluator reading DTAN 6223 wants to see the decisions: what the organisation needed, what constraints followed from that, which architectures could have met them, why this one was chosen, and how you know it works.
The second characteristic failure is scope. Data engineering projects expand naturally, because every component suggests another. A capstone that promises ingestion, transformation, storage, orchestration, monitoring, a serving layer and a dashboard will usually deliver six of those badly. A narrower system delivered completely, with the omissions named as deliberate scope decisions, scores better and finishes sooner.
The third thing under examination is operational thinking, and it is what makes this a graduate capstone rather than a portfolio project. Who runs this after you leave? What does it cost per month? What happens when the source changes? How is a failure detected, and by whom? These questions have short answers and their absence is conspicuous.
Turning scored aspects into a section plan
Capstone rubrics live in your Course of Study and usually carry more aspects than ordinary courses. Count them before you build anything, because the aspect list tells you what the system has to demonstrate, which in turn tells you what to leave out. Each aspect is scored independently against a three point scale and each needs a 2, so a working system with a missing evaluation section is a returned capstone.
Capstones also arrive in stages with an approval step. Treat the approved scope as binding, and if the build forces a change, record the change and its reason at the time rather than explaining it retrospectively at the end.
The word budget, worked. Assume nine scored aspects and a report around 3,600 words alongside the artefacts. Reserve 250 words for an executive opening and 180 for a close, leaving about 3,170, near 350 per aspect. Then rebalance: the organisational problem aspect and the validation aspect go to roughly 480 each, funded by trimming the component description aspects to around 280. Capstones almost always over describe components and under argue need, and correcting that imbalance on paper is free.
A structure that fits an engineering capstone
Your capstone directions and any supplied template take precedence. Where the shape is yours, this order carries the reasoning the rubric looks for.
| Section | What belongs in it | How it gets read |
|---|---|---|
| Executive summary | Problem, solution, evidence it works, and what it costs to run | Written last, read first, checked against the body |
| Problem and stakeholders | Who is underserved by the current arrangement and what it costs them | The aspect that makes this a project rather than an exercise |
| Requirements | Volume, latency, availability, retention, security, budget, stated as numbers | Everything downstream is judged against these |
| Architecture and alternatives | The design, plus at least two rejected options with reasons | Rejected options are the strongest evidence of design rather than assembly |
| Implementation | Components built, configuration shown, code referenced by file | Scored on completeness against the stated scope |
| Validation | Evidence the system meets each numbered requirement | Requirement by requirement is the format that scores best |
| Operations | Monitoring, alerting, runbook, cost, ownership after handover | The section that distinguishes a graduate capstone |
| Limitations and next steps | What was scoped out, what would be built next and why | Named scope decisions read as control, not as gaps |
Number your requirements and reuse the numbers in validation. A validation section organised as a table of requirement, test, result and evidence is quick to write and unusually persuasive.
Evidence craft for a built system
A capstone runs long, and evidence collected as you go is the difference between an assembly week and an archaeology week.
- Keep a dated decision log. Every architectural choice, its reason and its alternatives. Most of the report writes itself from it.
- Capture evidence at the moment it exists: run outputs, timings, row counts, cost figures. Recreating them at the end is expensive and sometimes impossible.
- Version everything in a repository, including infrastructure definitions, so the build is reproducible rather than described.
- Record actual costs rather than estimates where you can. A real monthly figure is far more convincing than a calculator screenshot.
- Cite vendor documentation for every guarantee you rely on, with access dates.
- Use APA throughout and build the reference list continuously.
Include one genuine failure. A capstone that reports a component that did not work, the diagnosis and the change that fixed it reads as real engineering, and it supplies evidence for aspects about troubleshooting that are otherwise hard to satisfy.
What separates Competent from a submission sent back
With more aspects in play, the chance of one thin section rises, and that is what returns look like here.
- Requirements are numbered, measurable, and each one is validated explicitly.
- At least two rejected architectures are named with specific reasons.
- The operations section names monitoring, cost and an owner rather than gesturing at them.
- Scope decisions are stated deliberately rather than appearing as omissions.
- The executive summary matches the delivered system, including the numbers.
Capstone performance assessment work can be revised and resubmitted with no grade penalty, but the evaluation queue at capstone level is the longest in the degree. Terms run six months at a flat rate, so a single return late in a term is the most expensive event in the whole programme.
Six mistakes that cost time in D610
- Building before requirements are numbered. Requirements written afterwards describe what exists and validate nothing.
- Scope that keeps growing. Every additional component is another thing that has to be validated and operated in the report.
- No cost figure. Cloud native infrastructure with no monthly cost is an incomplete engineering answer.
- Manual configuration with no record. A system built by clicking cannot be reproduced or handed over.
- Validation as a paragraph. A table mapping requirements to evidence takes an hour and answers several aspects at once.
- Starting in month four. Build time is unpredictable and evaluation time is not yours to control.
- Leaving credentials or connection strings in the repository. It is easy to do while iterating quickly, it is a genuine security finding in a graduate engineering submission, and it is trivially avoided by reading configuration from the environment from the first commit onwards.
Choosing a scope you can actually finish
The most valuable decision in D610 happens in the first fortnight, and it is a subtraction. A capstone scope that can be completed, validated and documented inside the term is worth more than an ambitious one that arrives partly built.
A workable test is to write the validation table before building anything. List each requirement, then write the sentence you expect to put in the evidence column. If you cannot imagine collecting that evidence with the time and access you have, the requirement is out of scope, and better to discover that now than in month five.
Prefer depth over breadth in what remains. One ingestion path, properly incremental, quality checked, orchestrated, monitored, cost reported and documented, demonstrates every skill the specialization teaches. Three ingestion paths, none of them monitored, demonstrate that you can repeat yourself. Evaluators are reading for evidence of each competency, not for volume, and a narrow system leaves room to show operational thinking that a sprawling one never reaches.
Write the scope decisions into the report as decisions. A short section explaining what was deliberately excluded, and what would be built next given another quarter, converts what would otherwise look like an unfinished system into a planned one.
How support works on this course
Send the rubric from your Course of Study, the capstone directions and any template. What comes back is aspect mapped and staged: help scoping a project you can finish, numbered requirements written as measurable statements, an architecture narrative with rejected alternatives, a validation table, and an operations section that names monitoring, cost and ownership. Plus a walkthrough so the build is yours to defend.
The capstone is where term pacing decides everything. Six month terms at a flat rate mean a capstone that slips into a second term doubles the tuition cost of a three competency unit course.
Questions students ask about D610
Is D610 the same course as DTAN 6223?
How is D610 different from the data science capstone?
Can you build my capstone infrastructure?
Where D610 sits in WGU's programs
The July 2026 catalog places this code in 1 current WGU program. Open a program page for the complete standard path and term positions. The live Degree Plan remains authoritative after transfer credit, substitutions, and mentor planning.
The assessments, one by one
The public catalog does not publish this course's PA/OA identity or task count. WGU Tutors publishes at most one PA manual per course and only from a WGU-controlled public rubric. Until that source exists, PA help begins from the student's real Course of Study and OA support remains preparation only.