D319 AWS Cloud Architecture carries the banner number ITCL 3201 and is worth 3 competency units. It is about designing structured cloud environments and putting control measures around them, with two specific targets: architectures that stay available when something fails, and architectures that perform well and scale as software workloads grow. D319 and ITCL 3201 are one requirement. It is a design course, so the deliverable is usually an architecture with reasons attached rather than a description of services.
Resilience and performance pull in different directions
The reason architecture is a discipline rather than a checklist is that its goals conflict. Redundancy improves resilience and costs money. Distributing a workload across availability zones improves survivability and adds latency between components. Caching improves performance and introduces staleness. Automatic scaling absorbs demand and can amplify a runaway process. A design document that recommends every good practice at once has not designed anything, it has listed virtues.
Resilience begins with a blunt question: what happens when this fails? Ask it of every component in your design, one at a time. A single instance, a single zone, a single database, a single credential, a single region. For each, the design either survives, degrades gracefully or stops. Those three outcomes are the vocabulary of a resilience argument, and the aim is not that everything survives but that the failures you accept are the ones you chose.
Performance and scale are separate properties and students often merge them. Performance is how fast a single request completes under normal conditions. Scale is what happens to that number as demand rises. A design can be fast and unable to grow, or highly scalable and slow for every user. Say which you are optimizing and where the bottleneck moves once you do.
Structure and control measures are the part that feels administrative and is not. How accounts and environments are organized, how permissions are granted, how resources are named and tagged, how spending is bounded and how changes are made all determine whether the architecture survives contact with a real team. An elegant diagram sitting inside an ungoverned environment is a design that will drift within a month.
WGU judges this course Competent or Not Competent instead of by letter grade, maintains no ordinary grade point average, and its 3 competency units sit inside a six month term at a flat rate.
Turning scored aspects into an architecture document plan
If your version of D319 is assessed by a performance assessment, the aspects your evaluator scores are the section list, and design courses tend to produce aspects that each demand a justification rather than a description. WGU requires a score of 2 in every aspect for a task to pass and scores each one alone, so a well argued resilience section does not carry a thin section on control measures.
Set the budget before drafting. Work from a rubric of six scored aspects with a target near 2,300 words, which suits a document where diagrams carry part of the load. Reserve 210 words for the workload, its demand profile and its constraints, and 130 for the close, leaving 1,960 words. Two aspects carry the design argument itself, typically the resilient architecture and the scalable one, and they take 470 words each for 940, because each needs the requirement, the design choice, the rejected alternative and the failure behavior. The four remaining aspects, usually covering environment structure, access control, monitoring and cost, take 255 each for 1,020. Adding 940 to 1,020 gives 1,960 exactly.
Write each design decision in a fixed shape: the requirement, the option chosen, the option rejected, the tradeoff accepted. Four sentences, repeated. That pattern is what turns a component list into an architecture, and it makes every decision individually scoreable, which is precisely what an aspect based rubric wants.
Reserve words for failure behavior. For each major component, one sentence saying what the system does when that component is unavailable is worth more than a paragraph praising the component. Those sentences are the strongest evidence that you designed rather than assembled.
Shape for a cloud architecture design document
D319 deliverables usually present an architecture for a described software workload. These proportions carry that document.
| Section | What belongs there | Share |
|---|---|---|
| Workload and requirements | What the software does, its demand pattern, and the constraints that bound the design. | 12 percent |
| Environment structure | How accounts, environments, networks and resources are organized, and why that way. | 13 percent |
| Resilient design | The architecture, its redundancy, and what happens when each component fails. | 21 percent |
| Performance and scale | What makes it fast, what makes it grow, and where the bottleneck moves. | 19 percent |
| Control measures | Access, change control, tagging, spending limits and the guardrails on all of it. | 15 percent |
| Monitoring | What is measured, what threshold matters, and what action an alert triggers. | 13 percent |
| Close | The tradeoff you are least comfortable with and what would justify revisiting it. | 7 percent |
Justifying architecture decisions with sources
Architecture claims come in three kinds and each needs different support. What a service does and what it guarantees is a provider documentation claim, cited with a date because service behavior changes. What constitutes good practice is a claim for published architectural guidance and well known reference frameworks. What this workload needs is a claim for the scenario, and inventing a requirement the scenario did not state is the most common integrity slip in design coursework.
Where the provider publishes an availability or durability commitment relevant to your design, cite it rather than paraphrasing it, because the exact wording usually contains conditions that matter. A commitment that applies only when a service is deployed across multiple zones is a different fact from the headline number, and quoting it correctly is often the whole argument for a design choice.
Use diagrams to carry structure and prose to carry reasoning. A diagram shows what connects to what. It cannot show why you rejected the alternative, and that reasoning is what most aspects actually score. Label every diagram, refer to it by name in the text, and never let it be the only place a design decision appears.
Where you discuss cost, describe the driver rather than quoting a price that will be stale by next term. Saying that a design trades higher steady state cost for lower recovery time is durable and analytical. Use the citation style your task specifies and cite at the point of the claim, including inside table cells.
What earns Competent, and what comes back
Competent architecture work is traceable and honest. Every component answers a requirement, every requirement comes from the scenario, every choice names what it gave up, and the failure behavior of the design is stated rather than implied. It also governs itself: access, change and spending are addressed rather than assumed.
Returns cluster in five places. The document lists services with no requirement behind them. Resilience is claimed because redundancy exists somewhere, without saying what survives which failure. Performance and scale are merged into one paragraph so one of the two aspects goes unanswered. Control measures are omitted entirely, which is the most common single omission in this course. Or the design contradicts a stated constraint, usually a budget or a data location requirement mentioned once in the scenario.
A check worth running: take your architecture and mentally remove one component at a time. If you cannot say what the system does in each case, the resilience aspect is not yet answered no matter how much redundancy the diagram shows.
No grade penalty attaches to revising and resubmitting a performance assessment at WGU, so submit once every aspect has a genuine answer rather than holding for polish. If your section also carries an objective assessment, that exam is proctored and our boundary is absolute: preparation only, with design pattern drills, service comparison work and a candid read of your preassessment result. We do not sit an assessment on your behalf, we are absent while one is in progress, and portal credentials never pass through us.
Diagram done, justification missing?
Send the D319 rubric and your workload. We rebuild the document decision by decision, with rejected alternatives and failure behavior for every component.
Six mistakes that cost time in D319
- Listing services instead of deciding. Each component needs a requirement behind it and an alternative you turned down.
- Claiming resilience without failure behavior. Say what happens when each component is unavailable. Redundancy alone is not an argument.
- Merging performance with scale. They are different properties with different remedies and usually different aspects.
- Skipping control measures. Access, change and spending guardrails are the most commonly omitted aspect in this course.
- Recommending everything. A design that accepts no tradeoff has not been designed. Name what you gave up.
- Contradicting a stated constraint. Budget, latency and data location requirements in the scenario exist to bound the answer.
Three questions students ask about D319
How detailed should the architecture diagram be?
Do I need hands on AWS experience to pass?
Is D319 the same course as ITCL 3201?
Where D319 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.