D282 Cloud Foundations is recorded under banner number ITEC 2119 and is worth 3 competency units. It covers the business value of cloud computing, the types of cloud available, the steps to a successful adoption, the effect on IT service management and the risks that implementation carries. The material aligns to entry-level AWS certification content. D282 and ITEC 2119 are one requirement, and the course is deliberately business-first rather than technical.
Cloud is an operating model change, not a hosting change
The most useful idea in this course is that moving to cloud changes how an organization buys, operates and accounts for technology, and only incidentally changes where servers live. Capital purchase becomes operating expenditure. Capacity planning becomes elasticity management. A procurement cycle measured in months becomes a request measured in minutes, which is a benefit and also a governance problem, because anyone with a card can now create infrastructure.
The value discussion has to be honest to score well. Cloud is not automatically cheaper. It converts fixed cost to variable cost, which is valuable when demand is uneven and expensive when demand is steady and predictable. It removes hardware refresh cycles and adds a permanent, growing bill that nobody owns unless someone is made to own it. Students who write cloud as unambiguously cost-saving miss the reasoning the aspects want.
Cloud types and service models supply the vocabulary. Public, private, hybrid and multi-provider describe deployment; the service models describe how much of the stack the provider runs. Getting these two dimensions straight early is what makes every later cloud course easier, because almost every question in this field is really a question about which combination is being discussed.
Service management effects are a scored theme and an interesting one. Incident management changes when part of the stack belongs to someone else and you cannot investigate their layer. Change management changes when infrastructure can be created by a script. Capacity management largely disappears and cost management arrives to replace it.
Outcomes are logged as Competent or Not Competent, and neither letter grades nor an ordinary grade point average are recorded, with 3 competency units describing its share of a flat-priced six month term.
Turning aspects into an adoption analysis
If your version of D282 uses a performance assessment, the aspects usually cover value, model selection, adoption steps and risk. WGU requires a score of 2 in each aspect for a task to pass and judges each aspect alone, so a strong benefits section will not carry an unaddressed risk aspect.
Budget before drafting. Take a rubric with five scored aspects and a target near 1,600 words. Reserve 130 words for the organization and the workload under consideration, and 100 for the close, leaving 1,370 across five aspects, or 274 each. Weight by demand: two aspects requiring evaluation and recommendation take 380 each, which is 760; the three remaining aspects, covering models, adoption steps and service management effects, take 203 each, which is 609. Together that is 1,369.
Anchor the value discussion to a workload rather than to the organization as a whole. A seasonal reporting system and a steady internal database have completely different cloud economics, and analysing one specific workload produces sharper answers than generalising across an estate.
Reserve budget for the case against. Every adoption analysis is stronger for naming the workload that should stay where it is and why, and that paragraph is frequently the one that demonstrates real understanding.
Shape for a cloud adoption analysis
D282 deliverables usually evaluate cloud for a described organization. These proportions fit that document.
| Section | Content | Share |
|---|---|---|
| Organization and workload | What the business does and the specific workload being considered, with its demand pattern. | 13 percent |
| Business value | What cloud changes for this workload, in cost shape, speed and capability, honestly weighed. | 19 percent |
| Model selection | Deployment and service model chosen, with what each alternative would have cost or required. | 17 percent |
| Adoption steps | The sequence from assessment to migration to operation, with who does what at each step. | 18 percent |
| Service management impact | How incident, change and cost management have to change once the workload moves. | 15 percent |
| Risks | Implementation risks named specifically, with likelihood, consequence and mitigation. | 13 percent |
| Close | Recommendation, plus the workload you would not move and why. | 5 percent |
Sourcing a business-first cloud course
Capability and pricing model claims belong to provider documentation, dated, because both change frequently. Adoption practice and service management effects belong to published frameworks and to recognised guidance on cloud adoption. Claims about what organizations experience after migrating are empirical and belong to research or industry survey data with a year and a population attached.
Cost claims deserve particular care because this is where the marketing pressure is strongest. Provider calculators are useful for structure and are built by a party with an interest in the answer. Where you produce a cost comparison, show the assumptions: demand profile, hours of operation, data transfer, storage growth and the staff time on each side. A comparison with visible assumptions can be argued with, which is what makes it credible.
Be careful not to treat a case study as evidence of general effect. A published account of one organization's migration is an illustration, and labelling it as one while keeping the argument on criteria applied to your scenario is the mark of a student who understands what evidence does.
Where certification content shapes the course, use it to gauge expected scope rather than as a source. It tells you how deep the technical material should go, which is useful when deciding whether a section belongs in this course or a later one.
Apply whichever citation style the task specifies and place each reference beside the claim it supports. That table is where several aspects can be scored at once.
Competent analysis and returned work
Competent submissions weigh value honestly, name deployment and service models precisely, sequence adoption with owners, and treat risk as specific and mitigable rather than as a closing list of generic worries.
Returns follow four shapes. Cloud is presented as unambiguously cheaper with no demand analysis behind it. Model terminology is used loosely, so the recommendation is ambiguous. Adoption is described as a migration with no assessment or operating phase around it. Or risks are listed generically without likelihood, consequence or mitigation.
The lock-in question belongs in any serious adoption analysis and students frequently skip it. Building on a provider's managed services delivers speed and reduces operational work, and it also means leaving becomes expensive in proportion to how much you used. That is a legitimate trade rather than a mistake, but it is one an organization should make knowingly. Saying which services create portability cost, and whether the speed is worth it for this workload, is a paragraph that separates a considered recommendation from an enthusiastic one.
Governance deserves a mention too. Self-service provisioning is a genuine benefit and it removes the friction that used to stop people creating infrastructure, which means an organization needs some replacement for that friction. Naming who may create what, within which spending limits, and how that is enforced turns an adoption plan into something an organization could actually operate for more than a quarter.
A quick check: for every benefit you claim, write the condition under which it would not hold. Elasticity helps uneven demand; steady demand does not benefit. Speed of provisioning helps teams that were waiting; it does nothing for teams that were not. Conditions turn claims into analysis.
Revision and resubmission carry no grade consequence at WGU, so submit as soon as every aspect has a real answer, and let the evaluator find the last gap faster than you would. If your section also carries an objective assessment, WGU objective assessments are proctored and our boundary is fixed: preparation only, with model drills, practice questions and a candid read on your preassessment result. Sitting an assessment for you is not something we do, do not assist while it is running, and we would refuse portal credentials if they were offered.
Cloud case reading like a brochure?
Send the D282 rubric and scenario. We anchor value to a workload, build the honest cost comparison and plan every aspect with word targets.
Eight mistakes that cost time in D282
- Cloud as automatically cheaper. It changes the shape of cost. Whether that helps depends on the demand pattern.
- Generalising across the estate. Analyse a specific workload. Different workloads give opposite answers.
- Loose model terminology. Deployment and service model are two dimensions. Name both, every time.
- Migration without assessment. Adoption starts before the move and continues after it. Cover the whole sequence.
- Ignoring cost ownership. A bill that grows with no owner is the most predictable post-migration problem there is.
- Generic risks. Name the risk, its likelihood here, its consequence and the mitigation.
- Case studies as evidence. One organization's outcome is an illustration, not a general finding.
- No workload left behind. Naming what should not move demonstrates judgement more efficiently than anything else in the document.
Three questions students ask about D282
Is D282 a technical course?
Do I need a provider account?
Does this course prepare me for a cloud certification?
Where D282 sits in WGU's programs
The July 2026 catalog places this code in 6 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.