D316 IT Foundations runs under banner number ITEC 2013 and is worth 4 competency units. It is the hands-on hardware course: personal computer components and data storage, then classifying, installing, configuring, optimizing, upgrading and troubleshooting printers, laptops, portable devices, operating systems, networks and system security. Search D316 or ITEC 2013 and you land on the same course. It builds directly toward the diagnostic habits every support and infrastructure course later in the plan assumes you already have.
A course made of verbs, not topics
Read the course description and count the verbs: classify, install, configure, optimize, upgrade, troubleshoot. That list is the real syllabus. D316 is not asking whether you can recognise a solid state drive; it is asking whether you can decide that a drive is the problem, choose the replacement, fit it into a machine with a stated constraint, and say why the alternative was worse. Students who study it as a parts glossary find the assessment strangely hard, because the assessment lives one layer above the glossary.
The device sprawl is deliberate too. Desktops, laptops, portable devices and printers behave differently under the same fault, and the course wants that difference internalised. A thermal problem in a tower is a fan and airflow story; the same symptom in a thin laptop is a throttling and chassis story; in a printer it is a duty cycle story. Learning one troubleshooting narrative per device class is far more efficient than memorising specifications.
Storage deserves separate attention because it is the topic where intuition from consumer computing misleads people most reliably. Capacity is the number students know; the numbers that decide real cases are interface bandwidth, sustained write behaviour once a cache is exhausted, endurance under a write-heavy workload, and how a machine behaves when the boot volume is nearly full. A scenario that says a workstation slows after twenty minutes of editing is a caching and thermal question long before it is a capacity question, and reading it that way is the difference between a confident answer and a guess.
WGU measures the outcome as Competent or Not Competent, with no letter grades and no ordinary grade point average, and the 4 competency units simply size the course inside your six month term. Because the term price is flat, the practical value of closing a hardware course quickly is that it makes room for a heavier one later in the same term.
From scored aspects to a written procedure
If your version of D316 includes a performance assessment, the aspects your evaluator scores are the only reliable outline. Hardware tasks are especially prone to a drafting failure where a student writes a beautiful narrative of what they did and never separates the steps the rubric wanted judged individually. WGU requires a score of 2 in each aspect to pass a task, and every aspect is judged in isolation, so a narrative that buries three aspects inside one paragraph is asking the evaluator to do your structuring for you.
Convert aspects to a budget before writing. Suppose the rubric lists six aspects and the task suggests roughly 1,800 words. Set aside 130 words for a framing paragraph naming the device, the symptom and the constraint, and 110 for the close. That leaves 1,560, or 260 per aspect. Now weight by evidence load: aspects that require a justification, such as choosing between two upgrade paths, need about 340 words because they carry a comparison; aspects that require a procedure, such as documenting a configuration, are usually complete in 200 because the steps do the talking. Three justification aspects at 340 and three procedural aspects at 180 lands at 1,560 exactly.
Write the headings first with the numbers beside them, then fill. When a procedural block runs to 400 words you have almost certainly started explaining rather than documenting, and that is a signal to cut rather than a signal to expand the budget.
Shape for a hardware recommendation or repair write-up
Foundations-level tasks in this area usually produce either a build or upgrade recommendation, or a documented troubleshooting sequence. The proportions below fit both if you read "fault" as "requirement" in the second case.
| Section | Content | Share |
|---|---|---|
| Device and context | Make, class of machine, what it is used for, and the budget or compatibility constraint that limits your options. | 9 percent |
| Symptom or requirement | What is observed, stated in measurable terms. "Slow" is not a symptom; "boots in 190 seconds" is. | 10 percent |
| Component analysis | Each candidate component, what it would explain, and what it would not. This is where classification knowledge is proven. | 24 percent |
| Test or selection sequence | Ordered steps with the expected result at each one, so a reader can follow without you present. | 21 percent |
| Configuration and verification | Settings changed, firmware or driver state, and the check that confirms the fix or the fit. | 16 percent |
| Security and handling | Data protection during the work, safe disposal, and the access controls restored afterwards. | 11 percent |
| Close | Outcome plus the preventive action that stops a repeat. | 9 percent |
Citing in a subject where the vendor is the authority
Hardware writing has an unusually clean source hierarchy, and using it well is quick marks. Specifications belong to the manufacturer: cite the product documentation or the technical specification sheet, not a retail listing. Interface and standard behaviour belongs to the standards body that defines the connector or protocol. Operating system behaviour belongs to the vendor's own documentation, which is versioned, so name the version you relied on. Where the course materials supply a procedure, cite the course text; it is the closest thing to an assigned standard you have.
Storage is where sourcing discipline earns the most. Drive endurance ratings, sustained versus burst throughput, and interface ceilings are all published figures with defined test conditions, and students routinely quote the headline number without the condition attached. A sequential read figure taken from a marketing page and applied to a random workload is a factual error dressed as a citation. Quote the figure, name the condition, and if the condition does not match your scenario, say so and use the number that does.
Two habits separate a clean submission from a scruffy one. First, put the citation next to the number it supports, because in hardware writing the numbers are the claims. Second, never cite a forum thread for a fact, even when the thread is right; use it to find the vendor document and cite that instead. Follow whichever citation style your task names and apply it to figures and tables as well as prose, since a specification table with no source is the most conspicuous gap on a page.
Competent work versus work that comes back
Work that passes reads like a technician's record. Each aspect has its own heading, each claim has a number or a source behind it, and the decision points are explicit: this was chosen over that, for this reason. Work that comes back usually falls into one of three shapes. It describes components in general without applying them to the stated constraint. It performs a fix but never verifies it, leaving the evaluator unable to see that the problem is closed. Or it treats the security aspect as an afterthought, which in a course that names system security in its own description is a predictable return.
One more pattern worth knowing: evaluators in device courses read for internal consistency, and hardware write-ups are unusually easy to catch out. If the framing paragraph says the machine has 8 GB of memory and the recommendation later assumes a workload that needs 32, the whole document loses credibility even though every individual claim might be sourced correctly. Before submitting, read only the numbers in your draft, in order, and check that they tell one story. It takes five minutes and it catches the kind of error that no amount of rereading prose will surface.
Revision is free of grade consequence at WGU, so submit once the structure is complete rather than waiting for polish; evaluator comments are more specific than your own second guessing. Where D316 uses an objective assessment, remember that WGU objective assessments are proctored. Our role stops at preparation: component drills, symptom-to-cause practice, and a candid read on whether your preassessment result says schedule it or wait a week. We never sit an exam, do not assist while it is running, and we would refuse portal credentials if they were offered.
Hardware task refusing to close?
Send the D316 rubric and the device scenario. You get a headed procedure plan with word targets, usually the same day.
Six traps that cost time in D316
- Memorising specifications instead of practising decisions. The assessment asks which component and why, under a constraint. Flashcards do not build that.
- Vague symptom statements. Every diagnostic aspect gets weaker when the starting symptom is not measurable. Fix the first sentence and the rest of the section improves on its own.
- Skipping verification. A repair with no confirming test is an unfinished repair on paper, whatever happened in reality.
- Ignoring the mobile and printer material. Students focus on desktops because desktops are familiar, then meet a laptop or printer scenario that needs a different fault model.
- Sourcing specifications from retail pages. Retail listings are frequently wrong, and an evaluator who checks one finds a citation problem and a factual problem at once.
- Leaving system security to the last paragraph. Data handling and access restoration belong inside the procedure, not appended to it.
Three questions students ask about D316
Do I need my own hardware to get through IT Foundations?
Why does my Degree Plan show ITEC 2013 rather than D316?
How is this different from D317?
How support runs on this course
Send the D316 rubric or blueprint together with the device scenario your task supplies. Written work comes back aspect-mapped: each scored aspect under its own heading with a word target beside it, every component decision carrying the constraint it was made under, and the verification step written in rather than assumed. Preparation work comes back as component drills, symptom to cause practice across desktop, laptop and printer fault models, and a candid read on whether your preassessment result says schedule the attempt or wait. Either way the walkthrough matters more than the document itself, because the diagnostic habit this course installs is the one D317 and every later support course quietly assume you already hold.
The term arithmetic is worth stating plainly. A WGU term runs six months at a flat rate, so the number that decides your cost per course is how many you close inside the term, not how many hours each one took. Four competency units of hardware material cleared in the first month rather than the last leaves room for a heavier course in the same term at no extra price. That is the whole argument for treating D316 as a course to finish early rather than a course to leave open.
The last pass before you submit
Structural checks catch more returns than proofreading does. Run these in order once the draft is complete, and treat any failure as a reason to fix rather than a reason to submit and hope.
- Every scored aspect has its own heading, and the heading uses the rubric's noun rather than a synonym you preferred.
- Every number in the draft, read in order and out of context, tells one consistent story about one machine.
- Every specification traces to manufacturer or standards documentation, never to a retail listing.
- Every fix has a stated verification, and every verification names the result that would count as success.
- Data handling and access restoration sit inside the procedure where they belong, not appended as a closing paragraph.
- The constraint named in your opening still binds the recommendation at the end.
Where D316 sits in WGU's programs
The July 2026 catalog places this code in 7 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.