D796 Unix and Linux, catalog number ICSC 5206, is the three CU graduate course in the WGU School of Technology introducing these operating systems with a focus on the skills used in system administration and development roles. It looks like a command course and is not. Commands are searchable; the model underneath them is what makes an unfamiliar system tractable, and that model is what gets assessed.
The model beneath the commands
Four ideas explain most of what these systems do. Everything is a file, including devices, processes and kernel state, which is why the same handful of operations work on almost everything. Small programs compose through streams, which is why a pipeline of simple tools replaces a bespoke program. Permissions and ownership are checked at every access, which is why a working command fails for another user. And configuration is text in known locations, which is why a system can be understood by reading rather than by clicking.
A submission that demonstrates those ideas explicitly scores better than one that lists more commands. When you explain a solution, name the principle it rests on: this works because the process exposes its state through a file interface, or this fails because the effective user lacks execute permission on a directory in the path.
The second scored theme is operational safety, and it separates people who have run systems from people who have read about them. Making a change reversible, taking a backup before editing configuration, testing a permission change on one file before applying it recursively, and knowing which command has no undo are all judgment rather than knowledge. Where a task involves administration, that judgment is usually assessed directly.
Turning scored aspects into a section plan
Scoring detail lives in your Course of Study rather than the catalog. Count the aspects and use them as headings in the rubric's own language. Each is judged independently against a three point scale and each needs a 2, so a working script with no explanation of why it works is a returned task.
Practical courses produce transcripts and scripts. Quote the relevant lines in the narrative rather than attaching a long capture, and explain what each does, since an evaluator scores the explanation.
The word budget, worked. Assume six scored aspects and about 1,900 words alongside the artefacts. Reserve 150 words for an opening that names the system and the objective, and 120 for a close. That leaves near 1,630, about 270 per aspect. Then move 60 words out of each of two procedural aspects into the aspect covering why the approach was chosen and the aspect covering verification. Listing steps is cheap; justifying and verifying them is the graduate material.
A structure that fits a systems administration task
Where your directions specify a structure, follow it. Where they leave it open, this ordering matches how practical aspects tend to be scored.
| Section | What belongs in it | How it gets read |
|---|---|---|
| Objective and environment | What must be true afterwards, and the distribution and version in use | Behaviour differs between distributions and versions |
| Approach | The method chosen and the alternatives rejected, with reasons | Several routes usually exist; choosing one is the assessed judgment |
| Implementation | Commands or scripts, with each non obvious option explained | Unexplained flags read as copied |
| Safety | Backups, dry runs, reversibility and what you did before the destructive step | The clearest marker of operational experience |
| Verification | Evidence the objective is met, from the system rather than from assumption | Checking the actual state rather than the absence of an error |
| Failure handling | What breaks this and how it would be detected | Expected at graduate level |
| Documentation | What another administrator needs to maintain this | Frequently thin and easy to strengthen |
Verify by querying the system rather than by noting that no error appeared. A command that returns silently has usually succeeded, but the aspect wants evidence of the resulting state, and that is a different check.
Evidence craft for practical systems work
The evidence here is what the machine says, and it is only useful when it is complete and attributable.
- State distribution, version and shell, since behaviour and available options differ.
- Include command output as well as the command, because the output is the evidence.
- Redact hostnames, addresses and anything identifying before including a transcript.
- Cite the manual pages or official documentation for behaviour you depend on, especially where an option differs between implementations.
- Explain every flag you use. An unexplained option in a graduate submission reads as borrowed.
- Use APA in the written portion and keep quotation short.
Show a check performed before a destructive action. A dry run, a listing of what would be affected, or a backup taken first is small in the transcript and large in what it signals about how you work.
What separates Competent from a submission sent back
Aspects score independently, so returns here are usually narrow.
- Every non trivial option is explained in the narrative.
- The approach section names at least one rejected alternative with a reason.
- A safety measure precedes any destructive or wide reaching change.
- Verification queries the system state rather than relying on absence of error.
- Documentation would let another administrator maintain the result.
Performance assessment work at WGU can be revised and resubmitted with no grade penalty, so a return costs calendar rather than standing. Terms run six months at a flat rate, and practical courses are among the quickest to close once the habit of explaining as you go is in place.
Six mistakes that cost time in D796
- Collecting commands instead of building a model. Memorised commands fail the moment the task differs slightly.
- Unexplained flags. They are the easiest thing for an evaluator to question and the easiest to fix.
- Recursive operations without a dry run. A misplaced argument on a recursive change is the classic irreversible mistake.
- Working as the superuser by default. Elevated privileges used routinely remove every safety net the permission model provides.
- Assuming success from silence. Verification means asking the system what state it is in.
- Ignoring distribution differences. Package managers, service systems and default paths vary, and stating your environment prevents a whole class of confusion.
- Editing a configuration file with no copy of the original. One saved copy costs a second and turns an unbootable service into a two command recovery, which is why experienced administrators do it without thinking about it.
Thinking in pipelines rather than in programs
The habit that most distinguishes fluent users of these systems is reaching for composition before reaching for code, and it is worth practising deliberately because it demonstrates the design philosophy the course is teaching.
The pattern is always the same. Get the data as text. Filter it down to the lines that matter. Extract the fields you need. Transform or aggregate. Then act. Each stage is a small tool doing one thing, and the value comes from the fact that any stage can be inspected by simply stopping there and looking.
That inspectability is the real advantage and it is worth writing about. A pipeline built one stage at a time, checking the output at each step, is debugged as it is constructed, whereas a script written whole has to be debugged afterwards with far less visibility. Describing that process in a submission demonstrates method rather than result.
Two disciplines make pipelines safe enough for real use. Quote variables, because a filename with a space will otherwise become two arguments and the failure is often silent. And separate the discovery step from the action step: first produce the list of things that would be affected, look at it, and only then feed it to the command that changes them. Doing that in two stages rather than one is the difference between a mistake you notice and a mistake you cannot undo, and it is exactly the operational judgment a graduate rubric is looking for.
How support works on this course
Send the rubric from your Course of Study and the task directions. What comes back is aspect mapped: approach sections with rejected alternatives, commands explained option by option, safety steps built in before destructive actions, verification that queries system state, and documentation another administrator could use. Where the course includes a proctored objective assessment, support is preparation only, never sitting it, and we never ask for portal credentials.
D796 is immediately useful outside the degree, which makes it one of the more satisfying courses in the sequence. Terms are six months at a flat rate, so a practical course cleared quickly leaves room for the theory heavy ones.
Questions students ask about D796
Is D796 the same course as ICSC 5206?
Do I need a dedicated machine to practise on?
Can you sit the exam or log into my systems?
Where D796 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.