E029 BSCNE Capstone Project carries the banner number ITCL 4201 and is worth 4 competency units. The WGU catalog describes it as a fixed set of workplace tasks, such as configuring network components, applying security policies to cloud resources or automating a network deployment with orchestration tools, submitted in a working deployed environment. E029 and ITCL 4201 are one requirement. It is a build capstone rather than a research capstone, which changes almost everything about how you should approach it.
A build capstone is graded on evidence, not on narrative
Most degree capstones ask you to propose something and defend the proposal. This one asks you to make something work and prove it. That distinction should reorganize your effort. Time spent polishing prose about what you intend to build is time not spent on the environment that has to exist at the end, and prose cannot rescue an environment that does not function.
The phrase carrying the most weight in the catalog description is working deployed environment. Working means it does what it is supposed to do when someone exercises it. Deployed means it is running somewhere rather than existing as a plan. Together they set the standard your evidence has to meet, and they explain why verification output matters more here than in any other course in the program.
Because the task set is fixed rather than chosen, the usual capstone anxiety about topic selection disappears and is replaced by a different one: sequencing. Some tasks depend on others being finished first, and discovering that dependency late is the most common way students lose a week. Reading the whole task set before starting anything, and drawing the order once, is the highest return half hour available to you.
The tasks named in the catalog description span three quite different skills. Configuring network components is device and connectivity work. Applying security policies to cloud resources is governance and access work. Automating a deployment with orchestration tools is code and repeatability work. A capstone that is strong in one and weak in another is a common shape, and the fix is to schedule your weakest area first while there is still term left.
WGU records the outcome as Competent or Not Competent, issues no letter grades and keeps no ordinary grade point average, and places these 4 competency units in a flat rate six month term. Capstones are worth starting early in a term for exactly that reason: they are the course least amenable to a final week sprint.
Turning scored aspects into a build and documentation plan
If your version of E029 is assessed by a performance assessment, the aspects your evaluator scores tell you what has to be demonstrated and documented. WGU requires a score of 2 in every aspect for a task to pass and judges each aspect on its own, so a technically excellent build with undocumented verification will still come back.
Budget the documentation before you build. Assume a rubric of five scored aspects and a target near 2,000 words of written material alongside your artifacts. Reserve 140 words for the environment overview and 120 for the close, leaving 1,740. Three aspects that require you to explain a build and show it working take 380 words each for 1,140, because each needs the requirement, what you configured, the verification and the result. The two remaining aspects, typically covering design rationale and security or operational considerations, take 300 each for 600. Adding 1,140 to 600 gives 1,740 exactly.
Document as you build rather than afterward. Capture verification output at the moment a thing starts working, because reproducing that evidence later means rebuilding state you have moved past. A running document with a section per task, filled in as you go, is the difference between a smooth submission and a frantic one.
Reserve budget for the failures you fixed. A short account of what did not work first time, what you found and what you changed is genuine evidence of competence and reads far better than an account in which everything worked immediately.
Shape for a build capstone documentation package
E029 submissions pair a working environment with documentation that lets someone verify it. These proportions carry the written part.
| Section | What belongs there | Share |
|---|---|---|
| Environment overview | What was built, where it runs, and how the pieces relate. | 12 percent |
| Task sequence | The order you worked in and the dependencies that set it. | 9 percent |
| Build record per task | What was configured, with the settings that matter and why they were chosen. | 28 percent |
| Verification | What you ran or exercised to prove each task works, and the output it produced. | 22 percent |
| Problems and resolutions | What failed, how you diagnosed it, what changed. | 13 percent |
| Security and operations | Access, secrets handling, and what running this would require day to day. | 11 percent |
| Close | What you would build differently with the term again. | 5 percent |
Evidence that a deployed environment actually works
Verification evidence has a quality hierarchy and evaluators know it. Output from a command or a test that exercises the thing is the strongest, because it shows behavior. A configuration export is next, because it shows state. A screenshot of a console showing a resource exists is weaker, because existing and working are different. A sentence asserting that it works is not evidence at all.
Capture evidence that identifies itself. Output that includes the resource name, the timestamp and the command or request that produced it is self explaining. Cropped fragments with no context force an evaluator to take your word for what they are looking at, and every uncertainty you leave is a place an aspect can fail.
Redact secrets before anything is submitted. Keys, tokens, passwords and connection strings appear in output more often than people expect, and a capstone package is a document that gets read. Replace them visibly rather than deleting them silently, so a reader can tell a value was present and was removed.
Where you cite documentation for a configuration choice, use the provider or vendor source with a date, in the citation style your task specifies. Keep excerpts short and say what each one demonstrates, because a page of pasted configuration with no commentary shows an evaluator nothing about your reasoning.
What earns Competent, and what comes back
Competent capstone packages let an evaluator verify without asking questions. Each task has a build record, a verification artifact and a result. Choices are explained rather than merely listed. Failures are reported. Secrets are handled properly. And the environment described in the document matches the environment that exists.
Returns cluster in five places. Verification is asserted rather than shown. Evidence is present but unlabeled, so nobody can tell what it proves. The documentation describes an intended configuration that differs from the delivered one. Everything is reported as having worked first time, which reads as incomplete rather than impressive. Or a credential is visible in an artifact, which is a problem no evaluator can overlook.
A check before submitting: hand your package to someone who has not seen your environment and ask them to say, for each task, what proves it works. If they hesitate on any task, that is the aspect that will come back.
At WGU a performance assessment can be revised and resubmitted with no grade penalty, so submit once each aspect has real evidence behind it rather than waiting for the environment to feel perfect. Where any part of your program uses an objective assessment, those exams are proctored and our boundary is absolute: preparation only, and we do not sit an assessment, play no role while one is running, and never request or hold portal credentials. Capstone support here is coaching on planning, sequencing and documentation of your own build.
Built it, cannot prove it?
Send the E029 rubric and your task list. We build the sequence plan and the documentation template that turns your environment into verifiable evidence.
Six mistakes that cost time in E029
- Starting before reading every task. Dependencies between tasks decide the order. Finding them late costs days.
- Documenting at the end. Verification evidence is easiest to capture the moment something starts working, not after you have moved on.
- Existence instead of behavior. A resource showing in a console is not proof it works. Exercise it and capture the output.
- Unlabeled artifacts. Every piece of evidence needs a caption saying what it is and what it proves.
- Secrets left in output. Redact keys, tokens and passwords visibly before anything is submitted.
- Hiding the problems. The diagnosis of something that broke is stronger evidence of competence than a flawless narrative.
Three questions students ask about E029
How is this different from a research capstone?
How early in a term should I start?
Is E029 the same course as ITCL 4201?
Where E029 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.