D602 Deployment, catalog number DTAN 5222, is the three CU course in the WGU Master of Science, Data Analytics that covers operationalizing an analysis inside a business: determining the requirements a running system has to meet, then implementing deployment pipelines and functions that meet them. It is the point where a model stops being a notebook someone ran once and becomes something an organisation depends on at nine on a Monday.
Requirements are the graded part
The word most students underweight in DTAN 5222 is requirements. It is tempting to read the course as a build exercise and treat the requirements section as preamble to the interesting part. The rubric usually reads the other way round. A pipeline that works is table stakes. A pipeline whose design traces back to a stated business need, a stated latency expectation, a stated failure tolerance and a stated ownership model is the graduate level artefact.
This is also the course where analytics students first meet the distinction between correct and operable. A model that takes eleven minutes to score a batch is correct and useless if the decision it feeds happens hourly. A transformation that assumes a column ordering is correct and fragile. Writing that distinction down, in the voice of someone who will have to support the thing at three in the morning, is what the scored aspects reward.
The third scored habit is thinking past deployment day. Monitoring, drift, retraining triggers, rollback and the question of who is paged when the job fails are not optional extras in a deployment course. A submission that ends at successful first run has answered half the question.
Turning scored aspects into a section plan
Scoring detail sits in your Course of Study rather than the public catalog. Open it, count the scored aspects, and treat that count as the outline. Each aspect is judged independently on a three point scale and each needs a 2 for the task to pass, so a strong implementation cannot rescue a thin requirements section.
Deployment tasks tend to mix artefact and narrative, which creates a specific mapping risk: work that exists only in a repository and is never described in the written submission. If an aspect is satisfied by a configuration file or a function, name the file and quote the relevant lines in the narrative. Evaluators score what they can see.
The word budget, worked. Take six scored aspects and around 1,800 words of narrative outside the code. Reserve 150 words for a framing opening that names the business process being served and 120 for a close that states what the deployment does and does not guarantee. That leaves about 1,530, near 255 words per aspect. Now rebalance: give the requirements aspect and the monitoring aspect 340 each, funded by trimming the aspects that merely describe the environment. Those two are where thin work is most visible, because both are pure reasoning and neither can be bluffed with a screenshot.
A structure that fits a deployment submission
Where directions specify a structure, follow it exactly. Where they do not, this order matches how deployment aspects tend to be scored.
| Section | What belongs in it | How it gets read |
|---|---|---|
| Business context | The decision or process the analysis feeds, and how often it happens | Sets the constraints everything downstream is judged against |
| Requirements | Functional and non functional needs stated as testable sentences, with owners | Vague requirements make every later justification unverifiable |
| Architecture | Components, data flow, where the model sits, what triggers what | Scored on fit to requirements rather than on sophistication |
| Pipeline implementation | The functions, transformations and orchestration, with error handling shown | Error handling is the fastest signal of production thinking |
| Validation | How you proved the deployed system produces the same answers as the analysis | Commonly skipped and commonly returned |
| Monitoring and maintenance | What is watched, what threshold triggers action, who acts, how to roll back | The section that distinguishes a deployment from a demonstration |
| Risks and limits | What breaks this, what is out of scope, what was accepted knowingly | Accepted risk named openly reads as engineering judgment |
Write the requirements before writing a line of pipeline code. Requirements reverse engineered from a finished build are recognisable, because they describe exactly what the build already does and nothing it fails to do.
Evidence craft for an engineering deliverable
Evidence in D602 is mostly artefact, which makes traceability the whole game.
- Number your requirements and reference the numbers in the architecture and validation sections. A reader should be able to follow one requirement end to end.
- Show configuration rather than describing it. A quoted block of orchestration definition proves what a paragraph only claims.
- Cite the platform documentation you relied on for any behaviour you depend on, especially retry semantics and failure modes.
- Record versions. A pipeline that works against one library version and silently changes behaviour on the next is a real hazard and naming versions shows you know it.
- Distinguish tested from expected. Say which behaviours you verified and which you inferred from documentation.
- Use APA for external sources including vendor documentation, and keep quotation short.
The sentence that marks out a strong submission is an honest statement of what the deployment cannot survive. A named single point of failure, with a reason it was accepted for now, is worth more than a claim of resilience nobody tested.
What separates Competent from a submission sent back
Aspects score independently, so returns here are usually narrow and specific.
- Every requirement is testable. A requirement nobody could fail is not a requirement.
- Every architectural choice points back to a numbered requirement rather than to preference.
- Validation compares deployed output against analysis output on the same input, and the comparison is shown.
- Monitoring names a metric, a threshold and a human. Two out of three reads as incomplete.
- The narrative alone tells the whole story; the repository confirms it rather than carrying it.
Performance assessment work can be revised and resubmitted with no grade penalty, so returns cost calendar time rather than standing. With six month terms at a flat rate, the meaningful number is courses closed per term, and a rebuild in a build heavy course is an expensive way to lose two weeks.
Six mistakes that cost time in D602
- Writing requirements after the build. They come out as a description of what exists and cover none of the failure cases an evaluator looks for.
- No error handling anywhere. A pipeline with no failure path is a script. The distinction is the course.
- Skipping validation. Proving that the deployed system reproduces the original analysis is a small section that is frequently missing entirely.
- Monitoring described as an intention. Saying performance will be monitored, with no metric and no threshold, scores nothing.
- Hard coded paths and secrets. Even in coursework this reads as inability to operate the system, and it is easy to fix before submission.
- Leaving the business context out. Without the decision the pipeline serves, no reviewer can judge whether any of the design choices were right.
Designing for the day it breaks
The section of a D602 submission that most reliably separates a passing task from a returned one is the part written from the assumption that the system will fail. Everything up to that point can be produced by following a tutorial. Failure thinking cannot.
Work through the failure modes explicitly rather than gesturing at reliability. The upstream source arrives late, or arrives on time with a column renamed. The model file is missing because a previous run was interrupted midway. A record contains a category the encoder has never seen. The scoring job succeeds but writes to the wrong partition. The volume of input triples on the first Monday of the quarter.
For each of those, a defensible submission answers three questions in a sentence or two. What does the system do: fail loudly, retry, or degrade to a previous result? Who finds out, and through what channel? And what is the recovery path, including whether a partial run has to be undone before a rerun is safe?
Two of those answers deserve special attention because they are where coursework usually goes quiet. Idempotency is the first: if the job runs twice on the same input, does the downstream table end up with duplicated rows? Saying plainly that reruns are safe, and showing the mechanism that makes them safe, is a short paragraph with a large effect on how the whole submission reads. The second is the difference between failing and failing silently. A pipeline that catches every exception and continues is worse than one that stops, because it produces confident output from incomplete data.
None of this needs to be elaborate at coursework scale. A table of failure modes with responses, alerting and recovery covers it, and it demonstrates the operational judgment the course exists to teach.
How support works on this course
Send the rubric from your Course of Study and the task directions. What comes back is aspect mapped: numbered requirements written as testable sentences, an architecture narrative that traces to them, a validation section that actually compares outputs, and a monitoring plan with metrics, thresholds and owners. Plus a walkthrough so you can defend the design rather than recite it.
D602 rewards planning far more than it rewards tooling, which makes it a course where a few hours of structure early saves a fortnight later. Terms are six months at a flat rate, so pace is the whole economics of the degree.
Questions students ask about D602
Is D602 the same course as DTAN 5222?
How much software engineering does D602 assume?
Will you build the pipeline for me?
Where D602 sits in WGU's programs
The July 2026 catalog places this code in 3 current WGU programs. 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.