E032 BSCNE-Cisco Capstone Project carries the banner number ITCL 4204 and is worth 4 competency units. The catalog describes it as the Cisco track variant of the network engineering capstone, sharing the same task set and the same deployed environment evaluation as the other track versions. E032 and ITCL 4204 are one requirement. This is the track where the evidence is device configuration and verification output, which means an evaluator can check your work almost line by line, and vagueness has nowhere to hide.
Addressing decided badly will follow you for the whole capstone
On a network track the first hour matters more than any other. An addressing plan that assigns ranges by function, leaves room to grow and is written down before any device is touched makes every later task straightforward. An addressing scheme improvised device by device produces overlaps, confusing routes and a documentation problem that grows every day. Draw the topology and write the address table first, even if it feels premature.
Configuration on this track is a sequence with dependencies, and the sequence is unforgiving. Interfaces before addressing, addressing before routing, routing before anything that has to reach across the topology, and access control last so you are not troubleshooting a routing problem through a rule that is quietly dropping your test traffic. Students who apply security policy early spend hours diagnosing a network that is working exactly as they configured it to.
Verification on this track has a well established vocabulary. The state of interfaces, the contents of routing and address tables, the results of reachability tests and the counters showing what a rule matched are all things you can capture directly. That is a considerable advantage: your evidence is exact, it is textual, and it demonstrates behavior rather than intent.
Configuration management deserves attention that student projects usually skip. Saving a working configuration before making the next change, keeping a copy off the device, and noting what each change was for turns a capstone into something recoverable. It also gives you an honest record of the diagnosis you did, which is stronger evidence than a clean final state.
Outcomes read Competent or Not Competent at WGU, there is no letter grade and no ordinary grade point average, and these 4 competency units sit within a six month term billed at one flat rate. On a build capstone that flat term is best spent starting early, because network faults consume time in unpredictable blocks.
Turning scored aspects into a configuration and evidence plan
If your version of E032 is assessed by a performance assessment, the aspects your evaluator scores tell you what must be configured and shown working. WGU requires a score of 2 in every aspect for a task to pass and judges each aspect on its own, so a correctly routed network will not carry an aspect on security policy that has no verification behind it.
Plan the write up before you configure. Consider a rubric of five scored aspects with a target near 1,850 words of written material accompanying your artifacts. Reserve 150 words for the topology and addressing overview and 100 for the close, leaving 1,600. Two aspects usually carry the technical weight, typically the core network configuration and the security policy application, and they take 425 words each for 850, because each needs the design, the configuration, the verification and the result. The three remaining aspects, typically covering automation or orchestration, troubleshooting, and operational considerations, take 250 each for 750. Adding 850 to 750 gives 1,600 exactly.
Present the address table once, early, and refer to it everywhere else. Repeating addresses inline invites transcription errors between the document and the devices, and a mismatch between the two is one of the easiest things for an evaluator to notice.
Reserve budget for one fault you diagnosed. A short account of a symptom, the commands you used to narrow it, what you found and what you changed is the most persuasive paragraph in a network capstone, because it shows method rather than luck.
Shape for a Cisco track capstone package
E032 submissions pair a working configured network with documentation that lets someone verify it. These proportions carry the written part.
| Section | What belongs there | Share |
|---|---|---|
| Topology and addressing | The diagram, the address table, and the logic behind the allocation. | 14 percent |
| Device configuration | What was configured on each device and why those settings. | 24 percent |
| Reachability verification | Tests run between named endpoints, with the output they produced. | 16 percent |
| Security policy | Rules applied, where they sit, what they permit and what they deny. | 18 percent |
| Automation | Any configuration applied by script or orchestration, and how it is repeated. | 13 percent |
| Troubleshooting record | A fault, the commands used to narrow it, the cause and the fix. | 10 percent |
| Close | What you would design differently and what it would simplify. | 5 percent |
Capturing configuration and verification output
Textual output is the strongest evidence available on this track, and it should be captured as text rather than as a photograph of a screen. Text is searchable, it copies cleanly into a document, it preserves exact values and it does not become unreadable when a page is scaled. Capture the command as well as its output, because output without its command is missing the question it answers.
Show state, not just configuration. A configuration excerpt proves what you typed; the operational state proves what the device is actually doing. Interface status, learned routes, neighbor relationships and rule hit counters all show a network behaving, which is what a working deployed environment means.
Include a test that fails as designed. Traffic that your policy is supposed to block, attempted and refused, with the counter showing the match, is the evidence that turns a configured rule into a demonstrated control. Only showing successful reachability leaves the security aspect resting on your description alone.
Remove or replace passwords, keys and community strings before submitting any configuration, and say that you have done so. Cite vendor documentation with a date where you justify a configuration choice, in the citation style your task specifies, and caption every excerpt with the device it came from and what it demonstrates.
What earns Competent, and what comes back
Competent Cisco track packages are internally consistent and verifiable. The address table matches the devices. Every task has both a configuration excerpt and an operational state artifact. Security rules are shown permitting and denying. At least one fault is diagnosed in writing. And the topology diagram matches what was actually built.
Returns cluster in six places. Addresses in the document differ from addresses on the devices, usually because the plan was written after the build. Verification consists of configuration excerpts only, which prove intent rather than behavior. Reachability is demonstrated in one direction only. Security rules are configured with no denied test to prove they act. Output is submitted as unreadable screen photographs. Or credentials remain visible in a configuration excerpt.
A check before submitting: pick two endpoints in your topology and trace, using only your own document, how traffic gets from one to the other and what would stop it. If your document cannot answer that, several aspects are resting on evidence that is not there.
A revised and resubmitted performance assessment costs nothing in grade terms at WGU, so submit once every aspect has evidence rather than waiting for the network to feel finished. Objective assessments anywhere in your program are proctored, and our boundary is absolute: preparation only, meaning we do not sit an assessment, stay out of it entirely while it runs, and never request or hold portal credentials. What we offer on a capstone is coaching: planning, ordering the work and documenting the build you produce yourself.
Network works, package does not show it?
Send the E032 rubric and your topology. We set the addressing plan, the configuration order and the verification set that proves each task behaves.
Six mistakes that cost time in E032
- Addressing improvised device by device. Write the address table before touching anything, or every later task inherits the mess.
- Applying security policy too early. Rules that silently drop your test traffic turn a routing check into an hours long hunt.
- Configuration excerpts as the only evidence. Show operational state too, since that is what proves behavior.
- One direction reachability. Test both ways. Return path problems are among the most common faults in student topologies.
- Photographs of screens. Capture text. It is searchable, exact and readable at any size.
- Credentials left in configuration. Replace passwords and community strings before submission and say that you did.
Three questions students ask about E032
Do I need physical equipment for this track?
How do I document troubleshooting without looking incompetent?
Is E032 the same course as ITCL 4204?
Where E032 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.