E030 BSCNE-AWS Capstone Project carries the banner number ITCL 4202 and is worth 4 competency units. The catalog describes it as the Amazon Web Services track variant of the network engineering capstone, sharing the same task set and the same deployed environment evaluation as the other tracks. E030 and ITCL 4202 are one requirement. Choosing the AWS track means your evidence, your naming and your cost exposure all take an AWS specific shape, and planning for that shape before you start is most of the difference between a smooth capstone and an expensive one.
The track changes the evidence, not the standard
Every track of this capstone is evaluated the same way: a deployed environment that works, documented well enough that someone else can confirm it. What differs is the vocabulary and the artifacts. On the AWS track your evidence lives in resource identifiers, policy documents, network configuration and command line output, and an evaluator familiar with the platform will read those artifacts fluently. Vague description is more obviously vague when the reader knows exactly what the real thing looks like.
Environment organization is the first decision and it is worth spending an hour on. How resources are separated, how regions are chosen, how everything is named and tagged, and which identity you work as all determine whether your capstone is navigable at the end. Building everything in one place under a single powerful identity works right up until you need to demonstrate access control, at which point you have no story to tell.
Cost is the AWS specific risk that catches students, and it is entirely avoidable with two habits. Set a budget alert before creating anything, so a mistake announces itself in hours rather than at the end of the month. And know which resource types keep charging when idle, because compute you stopped thinking about, addresses you reserved and storage you detached rather than deleted are the classic sources of a bill that arrives after the capstone is finished.
Access control deserves early attention because it is both a task area and a habit. Working as an identity with unrestricted permissions makes everything easy and leaves you with nothing to show for the access control portion of your work. Creating scoped roles from the start gives you a real artifact, a real story and a genuinely better environment.
Work is judged Competent or Not Competent at WGU, without letter grades and without an ordinary grade point average, and these 4 competency units fall inside a six month term charged at a flat rate.
Turning scored aspects into a build and evidence plan
If your version of E030 is assessed by a performance assessment, the aspects your evaluator scores tell you what has to be demonstrated. WGU requires a score of 2 in every aspect for a task to pass and judges each aspect independently, so a well built network with no evidence of the security work will not pass on the strength of the network.
Plan the documentation before the build. Picture a rubric of six scored aspects with a target near 2,150 words of written material accompanying your artifacts. Reserve 170 words for the environment overview and 100 for the close, leaving 1,880. Two aspects usually carry the heaviest demonstration, typically the network build and the automation, and they take 460 words each for 920, because each needs the design, the configuration, the verification and the outcome. The four remaining aspects, typically covering access control, security policy, monitoring and operational considerations, take 240 each for 960. Adding 920 to 960 gives 1,880 exactly.
Keep a running evidence log with one row per task: what you built, the identifier of the thing, the command or action that verified it, and where the output is stored. Filling that log as you work is the practical difference between a submission assembled calmly and one reconstructed under pressure.
Reserve budget for the cost narrative. Saying what your environment costs to run, which resources drive it, and what you shut down or removed at the end demonstrates operational judgment and takes eighty words.
Shape for an AWS track capstone package
E030 submissions pair a deployed AWS environment with documentation that lets someone verify it. These proportions carry the written part.
| Section | What belongs there | Share |
|---|---|---|
| Account and region layout | Where things live, why that region, and the naming and tagging convention used throughout. | 11 percent |
| Network build | Addressing, subnet layout, routing and gateway configuration, with the reasoning. | 22 percent |
| Access control | The roles and policies you created, what each permits, and the identity you worked as. | 15 percent |
| Security policy application | Controls applied to resources, where they sit, and what traffic or action each governs. | 15 percent |
| Automation | What was deployed by code or orchestration, and how a rerun produces the same result. | 18 percent |
| Verification | What you exercised, the output it produced, and what each artifact proves. | 13 percent |
| Cost and teardown | What it costs to run, and what was stopped or deleted at the end. | 6 percent |
Capturing AWS evidence that reads as genuine
The strongest evidence on this track is output that shows behavior. A connectivity test that succeeds between two specific resources, a request that is correctly refused by a policy, an automation run that completes and reports what it created. Each of those demonstrates the system doing its job, which is what the deployed environment standard asks for.
Include identifiers in your evidence. Resource identifiers are long and ugly and they are also what makes an artifact unambiguous, since they tie the output to a specific thing in a specific place. Evidence without identifiers could have come from anywhere, and an evaluator has no way to connect it to your build.
Show a negative test wherever a control is involved. Demonstrating that permitted traffic flows is half the proof; demonstrating that traffic you intended to block is actually blocked is the half students omit, and it is the half that proves the control exists rather than merely being configured.
Redact access keys, session tokens and account numbers where your task requires it, and never place credentials in a document or a repository. Cite provider documentation with a date for any configuration choice you justify, in the citation style your task specifies, and label every artifact with what it is and what it demonstrates.
What earns Competent, and what comes back
Competent AWS track packages are navigable and verifiable. Naming is consistent, so a reader can find things. Each task has behavioral evidence with identifiers attached. Access control is demonstrated rather than described. Automation is shown to be repeatable. And the environment as documented matches the environment as built.
Returns cluster in six places. Everything was built under an unrestricted identity, leaving no access control story. Evidence shows resources existing rather than working. Automation is described but never run, so repeatability is unproven. Controls are configured with no negative test. Naming is inconsistent enough that the document and the environment cannot be reconciled. Or credentials appear in an artifact, which no evaluator can pass over.
A check before submitting: pick any claim in your document and try to find the artifact that supports it in under thirty seconds. If you cannot, an evaluator working through a rubric certainly cannot, and that aspect is at risk regardless of what you actually built.
Since revision of performance assessment work carries no grade penalty at WGU, submit once every aspect has evidence rather than waiting for the build to feel complete. Objective assessments anywhere in your program are proctored, and our boundary is absolute: preparation only, which means we never sit an assessment, stay uninvolved while one runs, and never request or hold portal credentials. Capstone support here is planning, sequencing and documentation coaching on your own build.
Environment sprawling, evidence scattered?
Send the E030 rubric and your task list. We build the naming convention, the evidence log and the verification plan before the environment gets away from you.
Six mistakes that cost time in E030
- No budget alert. Set it before creating anything. A misconfiguration should announce itself in hours, not on a statement.
- Working as an unrestricted identity. It makes the build easy and leaves you with nothing to show for access control.
- Inconsistent naming. If the document and the environment use different names, nobody can reconcile them, including you.
- Existence as evidence. Show the thing working: a successful connection, a refused request, a completed automation run.
- Skipping the negative test. Proving that blocked traffic is actually blocked is what demonstrates a control exists.
- Forgetting teardown. Idle compute, reserved addresses and detached storage keep charging after the capstone is finished.
Three questions students ask about E030
Which capstone track should I choose?
How do I keep the cost down while building?
Is E030 the same course as ITCL 4202?
Where E030 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.