D320 Managing Cloud Security carries banner number ITCL 3202 and is worth 4 competency units. It covers safeguarding data in the cloud through identity and access management, implementing secure solutions across the cloud service models, and setting the security policies that govern cloud applications. D320 and ITCL 3202 are one requirement. The idea that reorganises everything here is that in the cloud, identity has largely replaced the network perimeter as the primary control.
Shared responsibility decides who fixes what
The first thing to internalise is that security responsibility splits between provider and customer, and the split moves depending on the service model. With infrastructure services the customer holds the operating system, the patching, the configuration and the data. With platform services the provider takes the runtime and the customer keeps the application and the data. With software services the customer's responsibility narrows toward identity, configuration and data, and widens nowhere else. Answering a cloud security question without stating which model applies is answering an underspecified question.
Identity and access management is the working core. Roles rather than individual permissions, least privilege applied to machine identities as well as human ones, short-lived credentials rather than static keys, and a genuine separation between the accounts that run workloads and the accounts that administer them. The single most consequential cloud security habit is treating a long-lived access key as a liability that has to be justified rather than as a convenience.
Configuration is where real incidents come from. The characteristic cloud failure is not a sophisticated attack; it is a storage container left readable, a permissive network rule, a logging service never enabled, or an administrative role granted broadly because narrowing it was fiddly. That is why the course pairs technical controls with policy: the technical fix is easy and the organizational discipline to keep it fixed is the hard part.
Visibility completes the picture. Cloud platforms generate rich activity records, and an environment where those are not enabled, retained and reviewed is one where nobody can say what happened. When a scenario mentions an investigation, the first question is whether the evidence exists at all.
Outcomes are logged as Competent or Not Competent, with no letter grades and no ordinary grade point average behind them, leaving 4 competency units as the only size figure attached to a flat-rate six month term.
Turning aspects into a cloud security plan
If your version of D320 uses a performance assessment, the aspects usually cover identity, service model implementation and policy. WGU requires a score of 2 in each aspect for a task to pass and judges each aspect alone, so a detailed identity design will not carry an unaddressed policy or monitoring aspect.
Budget before drafting. Take a rubric with seven scored aspects and a target near 2,200 words. Reserve 150 words for the workload, its service model and its data, and 110 for the close, leaving 1,940 across seven aspects, or roughly 277 each. Weight by demand: three aspects requiring design with justification take 380 each, which is 1,140; the four remaining aspects, covering policy, monitoring, compliance or responsibility mapping, take 200 each, which is 800. Together that is 1,940.
State the service model at the top of every technical section. The same recommendation is correct in one model and impossible in another, and a document that keeps the model visible avoids the most common source of confused answers in cloud writing.
Reserve budget for the responsibility mapping. A short table showing what the provider handles and what the customer handles for this workload is worth more than several paragraphs and anchors every later recommendation to something concrete.
Shape for a cloud security design
D320 deliverables usually secure a described cloud workload. These proportions fit that document.
| Section | Content | Share |
|---|---|---|
| Workload and data | What runs where, what data it holds, its sensitivity and any regulatory character. | 12 percent |
| Responsibility split | Service model in use and a clear table of provider versus customer duties for this workload. | 13 percent |
| Identity design | Roles, groups, machine identities, credential lifetimes and administrative separation. | 22 percent |
| Data protection | Encryption at rest and in transit, key ownership, and who can reach the keys. | 16 percent |
| Network and configuration | Segmentation, exposure of endpoints, and the configuration baseline you would enforce. | 15 percent |
| Monitoring and policy | What is logged and retained, who reviews it, and the written policy that keeps it in place. | 16 percent |
| Close | Residual exposure and the first control to implement, with its reason. | 6 percent |
Sourcing cloud security claims
Provider documentation is the authority for what a platform does and how a service behaves, and it should be cited by service name with a date, because cloud services change continually. Control guidance belongs to published frameworks, including those written specifically for cloud environments, which exist and are more useful than adapting general guidance yourself.
Keep provider capability separate from provider assurance. Documentation telling you that a service supports encryption with customer-managed keys is a capability claim you can rely on. A provider's marketing statement that its platform is secure is not evidence about your configuration, which is the part that is actually yours to get right.
Where compliance is in scope, cite the regulation or the standard rather than the provider's compliance page. A provider being certified for something does not automatically make your deployment on it compliant, and understanding that distinction is a scored insight rather than a technicality.
Use the scenario's own facts. Data residency requirements, the number of administrators, whether third parties have access and how the workload is deployed all change the answer, and citing those details keeps the design specific rather than generic.
Keep to the citation style the task requires and reference inline rather than in a closing pile. Where you present identity roles, a table of role, purpose, permissions and who holds it is far more legible than prose and gives the identity aspect an obvious anchor.
What earns Competent here
Competent submissions name the service model and hold to it, design identity around roles and short-lived credentials, treat configuration as a governed baseline rather than a one-time fix, and pair every technical control with the policy that sustains it.
Returns follow four shapes. The service model is never stated, so recommendations float between models. Identity is designed for humans and ignores the machine identities that run the workload. Encryption is claimed without saying who holds the keys, which is the question that actually matters. Or monitoring is proposed with no retention period and no named reviewer.
Cost has a place in a cloud security document that it does not have in an on-premises one, because cloud controls are metered. Extended log retention, key management services, additional monitoring and network inspection all appear on a bill, and a design that ignores this reads as though it has never been implemented. Naming the controls that carry ongoing cost, and saying which you would fund first, shows that the recommendation could survive a budget conversation as well as a security review.
Another distinction worth making explicitly: a control the platform offers is not a control until it is enabled and configured. Cloud providers ship a great many protective features that are off by default, and a submission that claims a capability exists without saying who turns it on, at what scope, and how you would verify it remained on has described the platform rather than the deployment.
One check that catches a lot: for every permission you grant, ask what an attacker holding that identity could do. If the answer for a routine workload identity includes reading all data or changing security settings, the design has a privilege problem that no other control will compensate for.
Performance assessment work can be revised and resubmitted with no grade penalty, so send it in the moment each aspect is genuinely addressed, 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 identity drills, service model practice and a candid read on your preassessment result. We never sit an exam, give no help from the moment it starts, and portal sign-in details stay with you at all times.
Cloud design floating between models?
Send the D320 rubric and your workload. We fix the service model, build the responsibility table and plan every aspect with word targets.
Eight mistakes that cost time in D320
- Not naming the service model. Responsibility moves with the model, and so does whether your recommendation is even possible.
- Ignoring machine identities. The workload itself has an identity, and it is usually over-permissioned.
- Long-lived static keys. Treat them as a liability requiring justification, not as normal practice.
- Encryption without key ownership. Who holds and can reach the keys is the substance of the control.
- Configuration treated as a one-time fix. Drift is the norm. Say how the baseline is enforced and monitored.
- Provider compliance as your compliance. Their certification does not make your deployment compliant.
- Monitoring with no retention or reviewer. Logs nobody keeps or reads are not a control.
- Undated provider references. Cloud services change constantly. Date every capability claim.
Three questions students ask about D320
Do I need an account with a cloud provider?
Which provider should my answers assume?
How does this differ from the graduate cloud security course?
Where D320 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.