D341 Cloud Deployment and Operations carries banner number ITEC 3005 and is worth 3 competency units. It covers the technical deployment, management and operation of cloud services: stability and scalability, backup and recovery, provisioning and monitoring of cloud resources, and managing connectivity. D341 and ITEC 3005 are one requirement. Where the design courses ask what to build, this one asks how it keeps running on a Tuesday afternoon when something breaks.
Operations is what happens after the architecture diagram
Deployment gets the attention and operations gets the years. This course is about the second, and the topics that fill it are unglamorous in exactly the way real work is: provisioning consistently, scaling without surprises, backing up in a way that actually restores, monitoring so problems are noticed by you rather than by users, and keeping connectivity healthy between everything that has to talk.
Scalability deserves precision because the vocabulary is loose in casual use. Scaling up means a bigger instance and eventually hits a ceiling. Scaling out means more instances and requires the workload to tolerate being spread. Automatic scaling adds rules that decide when either happens, and those rules have their own failure modes: too slow and the service degrades before capacity arrives, too aggressive and the bill grows while the load was momentary.
Backup is the topic where students most often write something that would not work. A backup is only real if it has been restored. Recovery point and recovery time targets decide the design, snapshots stored in the same place as the original protect against deletion but not against a regional problem, and a restore that takes eight hours does not meet a two hour recovery target no matter how frequently the snapshots are taken.
Monitoring closes the loop and has a specific cloud character. Platform metrics tell you about the infrastructure; application metrics tell you whether users can actually do anything; and the gap between them is where confusing incidents live. An operations plan that monitors only instance health has not committed to knowing whether the service works.
Your result reads Competent or Not Competent, because letter grades and an ordinary grade point average do not exist here, leaving 3 competency units as the only size figure attached to a flat-rate six month term.
Turning aspects into an operations plan
If your version of D341 uses a performance assessment, the aspects usually cover provisioning, scaling, backup, monitoring and connectivity. WGU requires a score of 2 in each aspect for a task to pass and judges each aspect alone, so a strong monitoring design will not carry an unaddressed recovery aspect.
Budget before drafting. Take a rubric with six scored aspects and a target near 1,800 words alongside your evidence. Reserve 130 words for the environment and the service being operated, and 100 for the close, leaving 1,570 across six aspects, or roughly 261 each. Weight by demand: two aspects requiring design with justification take 360 each, which is 720; the four remaining aspects, covering provisioning, backup, monitoring and connectivity, take 212 each, which is 848. Together that is 1,568.
Attach a number to every operational claim. A scaling rule needs a threshold and a cooldown. A backup needs a frequency, a retention period and a restore time. A monitor needs a threshold and an alert destination. Operations writing without numbers reads as intention rather than as a plan.
Reserve budget for the failure walkthrough. Choosing one plausible failure and narrating what the plan does about it, minute by minute, demonstrates more than three paragraphs of description and usually satisfies several aspects at once.
Shape for a cloud operations plan
D341 deliverables usually document how a cloud service is run. These proportions fit that document.
| Section | Content | Share |
|---|---|---|
| Service and environment | What is being operated, its components, and what users depend on it for. | 11 percent |
| Provisioning | How resources are created consistently, what is defined as configuration, and how drift is prevented. | 16 percent |
| Scaling | Up or out, the rules with thresholds and cooldowns, and the cost ceiling that bounds them. | 17 percent |
| Backup and recovery | Recovery point and time targets, backup location, retention, and the restore test that proves it. | 19 percent |
| Monitoring | Platform and application metrics, thresholds, alert routing and what each alert means. | 17 percent |
| Connectivity | Paths between components and to users, with what breaks if each one fails. | 13 percent |
| Close | One failure walked through end to end, and the gap it exposes. | 7 percent |
Evidence for operational claims
Service limits, scaling behaviour, snapshot semantics and metric definitions belong to provider documentation, cited by service and dated. These details matter operationally: whether a snapshot is incremental, whether a scaling action drains connections gracefully, and what exactly a metric measures all change how a plan behaves.
Where you can generate evidence, do. A screenshot of a scaling event, a restore completing with a timestamp, or an alert arriving is worth more than any description, and it is the difference between a plan and a demonstration. If your task includes practical work, capture these as you go rather than reconstructing them.
Recovery claims deserve the most scrutiny. Stating a recovery time target is easy; showing a restore that completed within it is evidence. If you cannot test a restore in your environment, say so and state the assumption your target rests on, because an untested recovery target is a hypothesis and treating it as a fact is the single most consequential error in operations planning.
Cost belongs in operations writing. Scaling rules, backup retention and monitoring granularity all have prices, and an operations plan that never mentions the bill will be modified by whoever receives the invoice. Naming the cost drivers and where you capped them shows the plan was designed rather than assembled.
Follow the citation style named in your task and reference inline rather than in a closing pile.
Competent operations work and returned work
Competent submissions attach numbers to everything, prove recovery rather than asserting it, monitor the application as well as the infrastructure, and walk through at least one failure end to end.
Returns follow four shapes. Backups exist with no restore test and no recovery time. Scaling is described with no thresholds, so it cannot be evaluated. Monitoring covers infrastructure only, leaving the service itself unmeasured. Or the plan describes tools and never says what an operator would do when an alert fires.
Runbooks are the artifact that turns an operations plan into something a team can actually use at three in the morning. For each alert or failure mode, a short set of steps saying what to check first, what to check next and when to escalate removes the guesswork that makes incidents long. They do not need to be elaborate; the value is that the reasoning was done in daylight rather than under pressure, and including one worked example in your submission demonstrates the whole idea more effectively than describing it.
A quick check: for every alert in your plan, write the first action the person receiving it should take. Any alert with no action is noise, and removing or reworking it improves the plan more than adding another monitor would.
Nothing is deducted when performance assessment work goes back for revision, so submit as soon as every aspect has a real answer, because feedback is more precise than your own second guessing. If your section also carries an objective assessment, WGU objective assessments are proctored and our boundary is fixed: preparation only, with service drills, operational scenario practice and a candid read on your preassessment result. We never sit an exam, take no part once one begins, and portal sign-in details stay with you at all times.
Operations plan with no numbers in it?
Send the D341 rubric and your environment. We attach thresholds, targets and retention to every claim and plan each aspect with word targets.
Eight mistakes that cost time in D341
- Backups never restored. An untested backup is a hypothesis. Test it, or state clearly that the target is untested.
- Scaling with no thresholds. Rules need trigger points, cooldowns and a cost ceiling to be evaluable.
- Monitoring infrastructure only. Healthy instances and a broken service is the most common real incident shape.
- Alerts with no action. If nobody knows what to do when it fires, it is noise that trains people to ignore alerts.
- Snapshots in the same location. They protect against deletion, not against losing the location itself.
- Provisioning by hand. Manual creation guarantees drift. Say what is defined as configuration and how it is applied.
- Ignoring cost. Retention, granularity and scaling headroom all appear on the bill and will be edited by whoever pays it.
- No failure walkthrough. Narrating one incident end to end proves the plan works better than describing each part of it.
Three questions students ask about D341
How much hands-on work does this course involve?
What recovery targets should I choose?
Is ITEC 3005 the same as D341?
Where D341 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.