D318 Cloud Applications is listed under banner number ITEC 3601 and is worth 3 competency units. It covers designing cloud infrastructure and services, recommending cloud security policies and procedures, and deploying cloud storage, networking and security. The material aligns to vendor-neutral cloud certification content. D318 and ITEC 3601 are one requirement, and this is where the business framing of the foundations course turns into things you actually build.
Design decisions in the cloud are storage decisions first
Most cloud application designs are decided by how data is stored, and students often treat storage as an afterthought. Object storage is cheap, effectively unlimited and not a file system. Block storage behaves like a disk and is attached to one machine at a time. File storage is shared and costs more. Databases add durability guarantees and operational burden. Choosing the wrong one produces an architecture that either does not work or costs several times what it should, and the reasoning behind that choice is exactly what a design aspect wants to see.
Networking in the cloud is the second design layer and it is more familiar than it first appears. Address ranges, subnets, routing and filtering all exist; what changes is that they are created by configuration rather than by cabling, and that the boundary to the internet is a setting rather than a device. The recurring student error is exposing something to the internet that only needed to be reachable from inside the environment.
Availability design is where cloud genuinely differs from a data centre. Spreading a workload across independent locations is achievable in minutes and pointless if the design still routes everything through one component. An availability claim in this course should name the failure it survives, and any design claiming resilience should have a single point of failure analysis behind it.
Security is deployed rather than described here. Identity, network exposure, encryption and logging are all configuration decisions in a cloud environment, and the aspects generally want them shown as part of the deployment rather than appended as a policy section.
Your result reads Competent or Not Competent, without letter grades, and WGU keeps no ordinary grade point average, and the 3 competency units measure course size within a six month term sold at one price.
Turning aspects into a design and deployment plan
If your version of D318 uses a performance assessment, expect aspects proven by design artifacts and aspects proven by justification. WGU requires a score of 2 in each aspect for a task to pass and judges each aspect alone, so a working deployment with no explanation leaves the reasoning aspects unanswered.
Budget both kinds. Take a rubric with seven scored aspects and a written component near 1,700 words alongside your diagrams and configuration evidence. Reserve 130 words for the application and its requirements, and 100 for the close, leaving 1,470. If four aspects are demonstrated by artifacts, allow 150 words each to name the component, its settings and the verification, which is 600. The remaining 870 covers three justification aspects at 290 each, enough for a decision, its alternative and its cost.
Write the requirements before the design. Availability target, expected load, data volume and growth, latency tolerance and budget are the five inputs that decide almost every choice you will make, and stating them first turns design into derivation rather than preference.
Reserve budget for cost. Cloud designs have a monthly bill, and a design document that never estimates it is incomplete in a way the reader will notice immediately.
Shape for a cloud application design
D318 deliverables usually design and deploy an application environment. These proportions fit the accompanying document.
| Section | Content | Share |
|---|---|---|
| Application requirements | Availability target, load, data volume and growth, latency tolerance and budget. | 13 percent |
| Storage design | Which storage type for which data, with durability, access pattern and cost reasoning. | 18 percent |
| Network design | Address plan, subnet layout, what is reachable from where, and what is deliberately not exposed. | 17 percent |
| Availability design | Distribution across locations, the failures it survives, and the single points that remain. | 16 percent |
| Security deployment | Identity, encryption, exposure and logging as configured, with evidence. | 17 percent |
| Cost estimate | Monthly running cost by component, with the assumptions behind each figure. | 12 percent |
| Close | What would change at ten times the load, and the first thing you would optimise. | 7 percent |
Evidence in a design and deployment course
Service behaviour, limits and pricing structure belong to provider documentation, cited by service and dated, because all three change. Where the course is vendor-neutral, be explicit about which provider your design assumes, since equivalent services differ in meaningful details.
Deployment evidence should show configuration and result. A screenshot of a created resource proves it exists; a screenshot of the security setting on it, and a test showing the resource is not reachable from outside, proves the design works. Aim for the second kind wherever an aspect concerns behaviour rather than existence.
Cost figures need visible assumptions. Instance hours, storage volume, data transfer and request counts drive the bill, and a monthly total with none of those stated cannot be checked. Where you use a provider calculator, say which inputs you gave it.
Diagrams carry a large share of the design aspects. Label every component, mark every boundary, show which subnets are reachable from the internet and which are not, and include a key. A design an evaluator can read from the diagram is a design that scores its structural aspects quickly.
Apply whichever citation style the task specifies and put the citation where the assertion actually appears.
Competent designs and returned ones
Competent submissions derive the design from stated requirements, justify storage choices by access pattern, keep private components private, name the failures their availability design survives, and estimate cost with assumptions attached.
Returns follow four shapes. Storage is chosen by habit rather than by access pattern, most often defaulting to the most expensive option. Something is exposed to the internet that had no reason to be. Availability is claimed with a single point of failure still in the path. Or the design has no cost estimate, which makes it impossible to evaluate as a proposal.
Growth deserves a paragraph in every cloud design because the interesting failures are gradual. A design that works comfortably at the stated load may behave very differently at five times that volume: a database that fitted in memory no longer does, a storage class chosen for low access frequency becomes expensive when access increases, a single region becomes a latency problem when users spread. Saying what breaks first as the workload grows, and roughly when, is the analysis that turns a snapshot design into an architecture.
Automation is worth naming even at foundations level. A design created by clicking through a console cannot be recreated reliably, and cloud environments are rebuilt more often than physical ones. Stating which parts of your design would be defined as configuration, and what that gives you in consistency and recovery speed, connects the design work to the operations work that follows it.
A quick test: for each component in your design, ask what happens if it fails. If the answer for any component is that the whole application stops, and your document claims high availability, you have found the gap the evaluator will find.
Revision and resubmission carry no grade consequence at WGU, so a complete draft should go to the evaluator rather than back to you, and treat the first submission as a way of buying exact feedback. If your section also carries an objective assessment, WGU objective assessments are proctored and our boundary is fixed: preparation only, with service drills, design practice and a candid read on your preassessment result. Sitting an assessment for you is not something we do, give no help from the moment it starts, and we neither ask for nor accept portal credentials.
Design built but not derived?
Send the D318 rubric and your requirements. We derive storage, network and availability choices and plan every aspect with word targets.
Eight mistakes that cost time in D318
- Storage chosen by habit. Access pattern and durability requirement decide the type. Cost differences between types are large.
- Designing before requirements. Availability, load, volume, latency and budget are the five inputs. State them first.
- Unnecessary internet exposure. A component reachable from outside that only needed internal access is the classic cloud error.
- Availability with a single point of failure. Distribution across locations means nothing if one component sits in the path of everything.
- Security described, not deployed. Show the setting and a test proving it works.
- No cost estimate. Cloud designs have monthly bills. A design with no number cannot be evaluated as a proposal.
- Unstated provider. Vendor-neutral does not mean vendor-free. Say which platform the design assumes.
- Unlabelled diagrams. Components without labels and boundaries force the evaluator to guess your intent.
Three questions students ask about D318
Should I take D282 first?
Which provider should I design for?
How accurate does the cost estimate have to be?
Where D318 sits in WGU's programs
The July 2026 catalog places this code in 4 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.