WGU D607: Cloud Databases

Where D607 Sits in Your Data Engineering Path

D607 Cloud Databases is the course where WGU stops asking you to think about data on a single machine and starts asking you to think about it at organizational scale. Per WGU's official course description, it covers applying cloud architectures to large-scale data systems, how cloud-native data architectures differ from smaller-scale systems, and applying cloud computing concepts to specific business scenarios. It appears in the Data Engineering specialization of the MS in Data Analytics and inside WGU's Data Engineering Professional Certificate, with no prerequisite listed.

Direct answer: D607 is not a multiple-choice exam — you pass it by completing two performance assessments to a Competent rating. Read each rubric line before you build anything, then design and document a cloud data storage solution that visibly answers every one of those lines in your own words. Students who treat the rubric as the assignment submit far fewer revisions.

You are probably taking this in the third term of the standard Data Engineering path, once foundations like Data Management and Analytics Programming are behind you (Deployment and Data Processing sit in that same third term). That sequencing matters: the course assumes you already know what a relational table is and what SQL does, and it spends its energy on the layer above — service models, deployment models, storage architecture, and the trade-offs between scaling up and scaling out. If your relational fundamentals feel shaky, a quick refresher (our D426 Data Management guide covers the same territory at the undergraduate level) will pay for itself in the first week.

The course is worth 3 competency units — a normal-sized course, not a capstone. The catch is that competency units measure content, not calendar time, and performance assessments consume calendar time in a way objective assessments do not. Plan accordingly.

What Cloud Databases Actually Covers

The official syllabus organizes the course into three modules. Each one feeds directly into what you will be asked to produce.

• Cloud Data Solutions. The differences between cloud service categories; public, private, and hybrid cloud architectures; basic disaster recovery terminology, principles, and resources; and the distinction between scaling up and scaling out.
• Cloud Data Storage. Designing big data storage; evaluating competing cloud solutions to find the best fit for a project; understanding how different data structures affect a solution; and designing databases that support business applications with scalability, security, performance, and reliability in mind.
• Cloud Data Storage Implementation. Designing a conceptual data model that defines the broad structure of data elements and their relationships, creating a logical data model, implementing a physical data model, and applying cloud solutions and concepts to a working design.

Alongside those, the course materials introduce Database as a Service (DBaaS), the differences between data warehouses, data lakes, and the newer lakehouse pattern, and the security, compliance, and legal dimensions of keeping data available in the cloud. The Data Engineering program as a whole is built around industry-standard platforms that WGU names publicly, including AWS Redshift, AWS DynamoDB, Google Cloud Spanner, and Apache Airflow, so expect work with real managed cloud services, not a purely theoretical read-through.

WGU's published competencies for the course are compact: explain the advantages of a cloud data solution, recommend a cloud data storage structure that addresses organizational requirements, and implement that structure. Notice the verbs. Two of the three are producing, not reciting. That is the whole character of this course in one line.

How Hard D607 Is and How Much Time to Budget

The syllabus describes Cloud Databases as an introductory course with no prerequisite, and the conceptual load genuinely is moderate — service models and deployment models are vocabulary you can learn in a few focused sessions. The difficulty lives elsewhere: in writing a justification an evaluator finds convincing, in producing data models that stay internally consistent from conceptual through physical, and in the ordinary friction of standing up cloud resources when one permission or region setting quietly breaks something.

In build-and-document courses, the learning tends to go faster than expected and the documentation slower. WGU's guidance for the Data Engineering program suggests dedicating roughly 15 to 20 hours per week — a reasonable anchor for a personal estimate. If you already work with cloud infrastructure, a couple of weeks of steady evening effort is a sensible target. If cloud consoles are new to you, give yourself more, and expect at least one revision cycle on at least one task — that is normal here, not a failure.

One structural detail that helps calm nerves: because assessment is by submitted work, nothing is timed and nothing is proctored — you cannot blank on a question. You can, however, stall for weeks by polishing instead of submitting, so set a hard date for a first submission and let the evaluator's feedback do the rest.

A Build-First Study Plan for D607

The most efficient approach inverts the usual order: skim, build, then study to fill the gaps your build exposed.

1. Days 1-2: read both task prompts and both rubrics first. Copy every rubric line into a document as a heading. That document becomes the skeleton of your submission. Anything the rubric asks for twice deserves double attention.
2. Days 3-6: work the first module fast. Use active recall on the vocabulary layer — close the material and write out, from memory, the differences between service categories, between public, private, and hybrid deployment, and between scale-up and scale-out. If you cannot explain scale-out to a non-technical colleague in three sentences, you do not have it yet.
3. Days 7-12: build something small in a real console. Provision a managed database, load a trivial dataset, and change one thing — add a replica, resize it, adjust an access policy. Availability and elasticity stop being abstractions the moment you have watched them behave.
4. Days 13-18: draft the recommendation and the models. Write your recommendation as a decision, with the alternatives you rejected and why. Then produce the conceptual, logical, and physical models in that order, and check that every entity in the conceptual model survives, renamed but recognizable, into the physical one.
5. Ongoing: use spaced repetition on the trade-off pairs. Warehouse versus lake versus lakehouse, relational versus non-relational, vertical versus horizontal scaling, recovery time objective versus recovery point objective. Three short review passes across two weeks beat one long cram — and these pairs are what your written justification leans on.

Security and compliance are woven through the rubric expectations rather than isolated in one section, so treat them as a lens you apply to every design choice. If access control, encryption, and data-protection obligations feel unfamiliar, our D430 Fundamentals of Information Security guide maps closely onto the vocabulary D607 expects you to use fluently.

Where D607 Submissions Usually Lose Points

• Describing instead of recommending. A paragraph explaining what DynamoDB is does not satisfy a rubric line asking you to recommend a storage structure for a stated organizational requirement. Name the choice, tie it to the requirement, and say what you did not choose.
• Models that drift. Entities that appear in the logical model but never existed conceptually, or attributes that materialize only in the physical model, read as three separate documents rather than one design.
• Ignoring non-functional requirements. Scalability, security, performance, and reliability are named explicitly in the course objectives. A design that addresses only what the data is, never how fast, safe, or available it must be, is incomplete by definition.
• Unlabeled or unreadable diagrams. Evaluators cannot infer relationships from an unlabeled arrow. Every entity, key, and relationship needs a legible label.
• Skipping disaster recovery. It is a stated objective and it is easy to forget when you are focused on the happy path.
• Uncited or unoriginal writing. Everything you submit goes through originality checking. Paraphrase and cite properly; borrowed passages are the fastest route to a returned task.

D607 Readiness Checklist

• Can you explain, without notes, the difference between public, private, and hybrid cloud deployment and give a business reason to pick each?
• Can you describe scale-up versus scale-out and name a situation where the cheaper option is the wrong one?
• Can you distinguish a data warehouse, a data lake, and a lakehouse, and say which workload each suits?
• Can you justify a specific cloud storage structure against a stated organizational requirement, including the alternatives you rejected?
• Can you produce a conceptual, logical, and physical data model that stay consistent with one another?
• Can you point to where your design addresses scalability, security, performance, and reliability — separately?
• Can you state a basic disaster recovery approach for your design using correct terminology?
• Have you mapped every rubric line to a labeled section of your document?
• Have you checked that all diagrams are legible, labeled, and referenced in the text?

D607 FAQ

Is D607 an objective assessment or a performance assessment?

It is assessed entirely by performance assessment. WGU's syllabus states that you demonstrate competency through two performance-based assessments and must earn a Competent rating on each to pass the course. There is no proctored multiple-choice exam.

How many competency units is Cloud Databases worth?

Three competency units, according to WGU's Data Engineering program guidebook, where it sits in the third term of the standard path.

Do I need cloud experience before I start?

No prerequisite is listed, and the syllabus calls it an introductory course. That said, comfort with relational database basics and a willingness to click around a cloud console will make the build portions dramatically less frustrating. Reviewing data fundamentals first — something like our D465 Data Applications guide — is a fair use of a weekend if you are coming in cold.

How long does D607 usually take?

It varies widely because it is submission-paced rather than exam-paced. WGU suggests roughly 15 to 20 hours per week for the Data Engineering program; at that pace, a few weeks is a reasonable planning assumption, with extra room if a task comes back for revision.

What happens if my task is returned?

You revise and resubmit. Returned tasks are routine at WGU, and the evaluator feedback tells you exactly which rubric line fell short — treat it as a specification, address it literally, and resubmit rather than rewriting from scratch.

Which cloud platform will I use?

The Data Engineering program publicly names platforms like AWS Redshift, AWS DynamoDB, and Google Cloud Spanner, but your specific environment and any accounts or sandboxes are set out on your live course page. Check there and confirm with your instructor before spending money on your own account.

Next Steps

Open the task prompts today, even if you plan to study for another week — knowing the deliverable's shape changes how you read everything else. From there, browse more School of Technology study guides or the full WGU course guide index to plan the rest of your term. For official program details, see WGU's Data Engineering specialization page.