D607 Cloud Databases, catalog number DTAN 6220, is the three CU course in the WGU Master of Science, Data Analytics that applies cloud architectures to large scale data systems and sets cloud native data design against the smaller scale architectures most students arrive already knowing. The assessed skill is not operating a particular managed service. It is choosing an architecture and then defending the choice against the alternatives you rejected.
Architecture choices, not console clicks
The habit that hurts students in DTAN 6220 is describing a platform instead of designing a system. A submission that walks through the steps of provisioning a managed database, screenshot by screenshot, has documented an afternoon rather than answered a question. What is being scored is the reasoning that made that database the right one.
Three distinctions carry most of the weight. Relational against non relational, decided by access pattern rather than by preference. Operational store against analytical store, decided by whether the system serves transactions or serves aggregation over history. And managed against self operated, decided by what the organisation can actually staff at three in the morning.
The second scored theme is what changes at scale. The contrast the catalog draws between cloud native and smaller architectures is the point of the course. Ideas that hold on one machine stop holding when data is partitioned across many: a join becomes a network event, a unique constraint becomes expensive, consistency becomes a spectrum rather than a guarantee, and the cost of a query becomes something a finance team notices. A submission that never mentions partitioning, replication or consistency has not engaged with the difference.
Turning scored aspects into a section plan
Scoring detail lives in your Course of Study rather than the public catalog, so start there and count the aspects. Each is judged independently against a three point scale and each needs a 2 for the task to pass. There is no averaging, so a sophisticated architecture paired with a thin justification is a returned task rather than a middling one.
Use the aspects as headings, worded close to the rubric's own nouns, and where an aspect is satisfied by an artefact such as a schema file or a configuration export, name that artefact in the narrative. Evaluators score what they can see, and a design decision that exists only inside a diagram is easy to miss.
The word budget, worked. Assume six scored aspects and roughly 1,900 words of narrative outside any diagrams or exports. Reserve 150 words for an opening that names the workload and the organisation, and 120 for a close. That leaves about 1,630, near 270 per aspect. Then rebalance: move 60 words out of each descriptive aspect and give the resulting 180 to the aspect covering architecture justification and the same again to the aspect covering cost or scalability. Those two are pure reasoning, they cannot be filled with platform description, and they are where thin submissions become visible.
A structure that fits a cloud data architecture task
Where your directions specify a structure, follow it. Where the shape is open, this ordering matches how architecture aspects are usually written and read.
| Section | What belongs in it | How it gets read |
|---|---|---|
| Workload description | Data volume, growth rate, read and write mix, latency expectations, users | Every later justification is judged against these numbers |
| Requirements | Availability, durability, consistency, recovery objectives and regulatory limits | Recovery objectives stated as numbers rather than adjectives |
| Architecture | Chosen services, data flow, storage layers, partitioning and replication approach | Scored on fit to workload rather than on how modern it looks |
| Alternatives rejected | At least two credible options with the reason each lost | The clearest evidence of graduate reasoning in the whole task |
| Data model | Schema or key design shown, with the access patterns it serves | Non relational designs are judged by access pattern fit, not normalisation |
| Cost and scaling | What drives cost, what happens at ten times the volume, where the ceiling sits | Frequently missing and frequently the difference between grades |
| Security and governance | Access control, encryption, retention, where data physically lives | Brief but expected; residency matters in regulated settings |
State the workload numbers first and refer back to them by name. An architecture defended against a described workload is a design. An architecture defended against general good practice is a brochure.
Evidence craft for an architecture submission
Architecture work is mostly claims about behaviour, and claims about behaviour need sources.
- Cite vendor documentation for any guarantee you rely on, especially durability figures, consistency models and throughput limits.
- Quote your own configuration rather than describing it. A schema definition or a partition key declaration proves what a sentence asserts.
- Attach numbers to scale claims. Saying a design scales is not evidence; saying it holds to a stated row count under a stated access pattern is.
- Show a cost estimate with its assumptions listed, even if approximate. An estimate with visible assumptions beats an unsupported adjective.
- Separate what you tested from what you read. Both are legitimate; conflating them is not.
- Use APA for all external sources including documentation pages, and note access dates because cloud documentation changes.
The sentence that lifts an architecture submission is the one naming the condition under which the design stops being right. Every architecture has a volume, a latency or a budget beyond which a different answer wins, and stating where yours sits shows you chose rather than defaulted.
What separates Competent from a submission sent back
Aspects score independently, so returns are usually narrow: one hollow section inside an otherwise solid design.
- Every architectural choice points back to a stated workload characteristic rather than to preference.
- At least two credible alternatives are named and rejected with specific reasons.
- The data model is shown, not described, and the access patterns it serves are listed beside it.
- Cost drivers are identified even if figures are approximate.
- Consistency and availability trade offs are addressed openly rather than assumed away.
Performance assessment work at WGU can be revised and resubmitted with no grade penalty, so a return costs calendar rather than standing. In a six month term charged at a flat rate, calendar is the only scarce resource in the degree.
Six mistakes that cost time in D607
- Describing a platform instead of designing a system. A tour of a console proves familiarity, not judgment.
- Choosing non relational by default. A schema with joins and ad hoc queries is often better served by a relational engine, and saying so is a legitimate finding.
- Ignoring the access pattern in key design. Non relational performance is decided by the key, and a key chosen for tidiness produces hot partitions.
- Leaving cost out entirely. Cloud architecture without a cost discussion misses one of the two reasons the cloud exists.
- Treating consistency as binary. Naming the consistency level you selected and what it means for your workload is a short paragraph with high value.
- No recovery objectives. Availability described as high, with no target and no recovery time, is an adjective standing where a number belongs.
Writing the trade off section that carries the task
Most of what distinguishes a strong D607 submission concentrates in one place: the section where you show that you understood what your architecture gave up. It is worth planning that section deliberately rather than letting it emerge.
Work through four trade offs explicitly. Consistency against availability, where the honest question is what your application does when a replica is stale and whether anybody would notice. Normalisation against read performance, where duplicating data to serve a query pattern is a legitimate choice with a stated maintenance cost. Managed service against control, where paying more per hour buys you fewer people on call and less ability to tune. And storage tiering against retrieval latency, where cheap archival storage is only cheap until somebody needs the data back quickly.
For each one, write the choice, the reason grounded in your stated workload, and the condition that would reverse it. Three sentences apiece. Twelve sentences total, and they do more for a graduate architecture task than another page of service description ever will, because they are the only part of the submission that could not have been written by someone who had merely read the documentation.
How support works on this course
Send the rubric from your Course of Study and the task directions. What comes back is aspect mapped: a workload description with real numbers, an architecture narrative that traces back to it, rejected alternatives with reasons, a data model shown against its access patterns, and a cost and scaling section that concludes something. Plus a walkthrough so the design is yours to defend.
D607 sits alongside the rest of the data engineering specialization, and the architecture vocabulary it builds carries directly into the courses that follow. Terms run six months at a flat rate, so clearing this one early lowers the effective cost of everything after it.
Questions students ask about D607
Is D607 the same course as DTAN 6220?
Do I need my own cloud account for D607?
Can you build the database and submit it for me?
Where D607 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.