D386 Hardware and Operating Systems Essentials appears under banner number ITEC 2022 and carries 3 competency units. It covers computer architecture and the history of computing architectures, operating systems, and the decision that pulls both together: choosing hardware and software stacks that satisfy functional and non-functional business requirements. Whether your search says D386 or ITEC 2022, it is the same single requirement, and it feeds the systems reasoning that later development and infrastructure courses take for granted.
Architecture is taught here as a justification skill
Two thirds of D386 looks like a theory course and the last third turns it into an argument. You learn how processors, memory hierarchies and storage interact, how operating systems mediate between programs and that hardware, and how the designs got to be the way they are. Then the course asks you to choose a stack for a business that has stated needs, and to defend the choice. That final move is where students who read passively come unstuck, because a defensible recommendation requires knowing what a design costs, not just what it does.
The functional versus non-functional distinction is the load-bearing idea in the whole course. Functional requirements say what the system must do: process this many transactions, run this application, support these file types. Non-functional requirements say how well: availability, latency, maintainability, power draw, cost of ownership. Most weak submissions answer the functional list confidently and then treat the non-functional list as adjectives. Non-functional requirements are usually what actually decides between two technically adequate stacks, and rubrics tend to reward students who show that.
The memory hierarchy is the single idea that repays study most in this course, because so many later questions collapse into it. Registers, cache levels, main memory and persistent storage differ by orders of magnitude in both speed and cost, and almost every architectural decision is an attempt to keep the working set as high up that hierarchy as budget allows. Once you can explain a slow application as a hierarchy problem rather than a general performance problem, the operating system material stops being a list of features: scheduling, paging and file caching are all the same story told at different levels.
Results here are Competent or Not Competent, in line with every WGU course. There is no letter grade and no ordinary grade point average, and the 3 competency units describe course size within your six month term. Terms are flat priced, so closing this one early converts directly into capacity for a heavier course later.
Turning the aspect list into a defensible outline
If your D386 assessment is a performance assessment, the aspects your evaluator scores are your outline and the scenario is your data. WGU requires a score of 2 in each aspect for a task to pass, and no aspect borrows credit from another, so a strong architecture discussion cannot rescue a missing requirements analysis.
Here is a budgeting pass for a small task. Say the rubric shows four scored aspects and the deliverable is meant to run near 1,600 words. Reserve 140 words for a scenario summary that states the business, its workload and its constraints, and 100 for a close. That leaves 1,360 across four aspects, or 340 each at a flat split. Then weight by argumentative load. A requirements analysis aspect and a justification aspect both need room to compare alternatives, so give them 420 apiece. The two descriptive aspects, architecture explanation and operating system selection, drop to 260. Total: 1,360. Now every heading has a number, and when the architecture section reaches 500 words you know it is stealing from the justification that carries the same weight.
The weighting principle to carry forward: aspects whose verb implies a comparison need roughly one and a half times the words of aspects whose verb implies a description. In this course that ratio is unusually reliable, because comparison is what the subject is really about.
Shape for a stack recommendation
The deliverable D386 tends to produce is a technical recommendation written for someone holding a budget. The table below is a working shape for that document.
| Section | Purpose | Share |
|---|---|---|
| Business context | What the organization does, the workload in question, and the decision being asked for. | 9 percent |
| Functional requirements | A numbered list of what the system must do, each item testable rather than aspirational. | 12 percent |
| Non-functional requirements | Availability, performance, security, maintainability and cost targets, each with a number or a threshold. | 14 percent |
| Architecture options | Two or three candidate stacks described at component level, with what each design optimises for. | 22 percent |
| Operating system fit | Which operating system suits each option and why, covering support model, licensing and administration effort. | 16 percent |
| Justified recommendation | The choice, mapped item by item to the requirements above, including what you accept as a tradeoff. | 19 percent |
| Close | The decision restated in one paragraph with the first procurement or deployment step. | 8 percent |
Where architecture claims should come from
Architecture writing fails on sourcing more often than on understanding. Performance and capability claims belong to the manufacturer's technical documentation or to a published benchmark with a stated method, never to a marketing page or a comparison blog. Operating system support timelines, licensing terms and administration models belong to the vendor's own lifecycle documentation, and those documents are dated, so give the date. Historical material about the evolution of architectures is one of the few places where a textbook or a peer-reviewed source is genuinely the best evidence, and using one signals you did more than skim a summary.
Total cost of ownership is the claim students source worst. A licence price is easy to find and is rarely the number that decides anything; support contracts, administration hours, training, and the cost of the skills you would need to hire are the parts that move a decision. You do not need a finance qualification to handle this well. You need to state each cost component, name where the figure came from, and be explicit when a figure is an estimate rather than a published price. An honest estimate labelled as one is stronger evidence than a precise number with no provenance.
Follow whichever citation style your task names and cite where the claim sits. In a recommendation document there is a further discipline worth adopting: separate the sourced capability from the applied judgment in adjacent sentences. State what the documentation says the component does, then state what that means for this organization's non-functional target. Evaluators can score both halves when they are visible and can score neither when they are fused into one confident sentence with a citation dangling off the end.
The difference between Competent and returned
Competent submissions in D386 read as decisions, not surveys. Requirements are stated in testable terms, options are genuinely different from one another, and the recommendation refers back to specific requirement items by name. Returned submissions usually show one of these shapes: a requirements list with no numbers in it, two "options" that are minor variations of the same design, or a recommendation that arrives without ever revisiting the non-functional targets it is supposed to satisfy.
Since performance assessment work can be revised and resubmitted without any grade penalty, the efficient path is to submit as soon as every aspect has a real answer. Evaluator feedback tells you which requirement link was too thin far faster than rereading your own draft will. If your version of D386 includes an objective assessment, that exam is proctored and our boundary is absolute: we build preparation, including architecture drills and practice questions, and a straight read on whether your preassessment says go. We do not sit exams for anyone, take no part once one begins, and portal sign-in details stay with you at all times.
Recommendation not defensible yet?
Send the D386 rubric and the scenario. We map requirements to aspects and hand back a headed plan with word targets.
Five mistakes that cost time in D386
- Treating non-functional requirements as adjectives. "Fast and reliable" is not a requirement. A latency target and an availability percentage are, and they are what decides the recommendation.
- Building straw options. If one candidate stack is obviously unusable, the comparison aspect has nothing to score. Give every option a real advantage.
- Benchmarks without method. A performance number with no test conditions attached is not evidence, and evaluators in this subject know it.
- Letting the history section run long. The evolution of architectures is interesting and rarely carries much rubric weight. Budget it and hold the budget.
- Recommending without tradeoffs. Every real choice gives something up. Naming what you gave up is the strongest single sentence available in this deliverable.
- Choosing an operating system on preference. Familiarity is not a criterion. Support lifecycle, licensing model and administration effort are, and each of them can be sourced.
- Leaving the requirements list unnumbered. Numbered requirements let the recommendation refer back to specific items, which is exactly what a justification aspect wants to see.
Three questions students ask about D386
Is D386 a programming course?
What does ITEC 2022 mean next to my course code?
How many stack options should I compare?
Where D386 sits in WGU's programs
The July 2026 catalog places this code in 4 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.