D337 Internet of Things (IoT) and Infrastructure is recorded under banner number ITEC 2114 and is worth 3 competency units. It covers the technologies that connect the internet to physical objects, how to derive business requirements for sensors, and how to store, transmit and process the resulting data securely. D337 and ITEC 2114 are one requirement. The course lives at the join between the physical world and the infrastructure that has to absorb what it produces.
Start from the measurement, not from the device
The instinct in this subject is to start with devices, and it is the wrong end. Every worthwhile deployment starts with a decision someone wants to make better and a measurement that would inform it. From the measurement you derive the sensing requirement: what quantity, at what accuracy, how often, in what conditions, and for how long the answer stays useful. Only then does device selection become a question with a right answer.
Sampling rate is the requirement students handle worst, in both directions. Measure too rarely and you miss the event you deployed for. Measure too often and you generate volumes of data that cost money to move, store and process while adding nothing to the decision. A temperature reading every second in a cold store is almost certainly waste; a vibration reading every second on a failing bearing may be too slow. Tying the rate to the rate at which the underlying phenomenon changes is the reasoning the aspects want.
The infrastructure half is about what happens after the reading exists. Constrained devices, intermittent connectivity, batch versus stream processing, where computation happens relative to where data is produced, and how much history is retained are all decisions with cost implications. Processing near the source reduces what has to travel and adds complexity at the edge. Sending everything centrally simplifies devices and increases bandwidth and storage cost. Naming which you chose and why is a scored decision.
Security in this domain has a specific character. Devices are numerous, physically accessible, often long lived and frequently hard to update, which inverts several assumptions from ordinary infrastructure security. Identity per device, protection of data in transit from constrained endpoints, a realistic update mechanism and a plan for devices that will outlive their vendor support are the questions worth answering directly.
Outcomes are logged as 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 deployment analysis
If your version of D337 uses a performance assessment, the aspects generally cover requirements, technology selection, data handling and security. WGU requires a score of 2 in each aspect for a task to pass and scores each aspect alone, so an excellent sensor selection cannot carry an unaddressed data retention or security aspect.
Budget before drafting. Take a rubric with six scored aspects and a target near 1,750 words. Reserve 130 words for the business situation and the decision the deployment supports, and 100 for the close, leaving 1,520 across six aspects, or roughly 253 each. Weight by demand: two aspects that require requirement derivation and technology justification need 360 each; the four remaining aspects, covering architecture, data handling, security and cost, take 200 each. Two at 360 plus four at 200 is 1,520 exactly.
Do the data arithmetic explicitly somewhere in the document. Number of devices, multiplied by readings per device per day, multiplied by bytes per reading, gives a daily volume, and that single calculation drives transport, storage and retention decisions across three other aspects. Students who skip it end up asserting that storage is manageable without any basis.
Reserve space for what happens when a device fails or goes offline. Physical deployments degrade, and an analysis that assumes every sensor reports forever is one an evaluator will not believe.
Shape for a connected infrastructure proposal
D337 deliverables usually propose or evaluate a deployment. These proportions fit that document.
| Section | Content | Share |
|---|---|---|
| Business decision | What decision improves with better measurement, and what it is worth to the organization. | 11 percent |
| Sensing requirements | Quantity, accuracy, sampling rate, environmental conditions and expected device lifespan. | 17 percent |
| Device and connectivity | Device class and how it communicates, with power and coverage constraints stated. | 16 percent |
| Data pipeline | Volume calculation, where processing happens, what is kept and for how long. | 19 percent |
| Security | Device identity, transport protection, update mechanism and physical access risk. | 18 percent |
| Operations | Failure handling, monitoring of the fleet, and how a dead sensor is noticed. | 11 percent |
| Close | Cost summary and the condition under which the deployment stops being worthwhile. | 8 percent |
Sourcing across hardware, protocol and policy
This subject spans three source families. Device and sensor capability belongs to manufacturer specifications, including the operating conditions, because a sensor accurate at room temperature may not be in a freezer. Communication protocol behaviour, range and power characteristics belong to the defining standards or the protocol's own specification. Security guidance belongs to published frameworks and to national agency guidance for connected devices, which exists and is more specific than general security advice.
Watch out for range claims in particular. Wireless range figures are quoted under ideal conditions and real deployments involve walls, metal, moisture and interference. Quote the specification, then state what you expect in the described environment and why, because an evaluator reading a deployment proposal for a warehouse will notice if a line-of-sight figure was applied indoors.
Where data protection regulation applies, cite the regulation rather than a summary. Connected devices frequently collect data that is personal by inference even when no name is attached, such as occupancy patterns in a building, and the strongest submissions notice that rather than treating sensor data as automatically impersonal.
Apply whichever citation style the task specifies and put the citation where the assertion actually appears. Show your volume calculation as a labelled table so the numbers driving three later sections can be checked in one place.
Competent proposals and returned ones
Competent submissions reason from decision to measurement to device, calculate data volume rather than estimating it verbally, and treat security as a design constraint present from the start. They acknowledge that devices fail, that connectivity is imperfect and that some data is personal by inference.
Returns follow four shapes. The proposal starts with a technology and works backwards to a justification. Sampling rate is chosen with no relation to how fast the measured thing changes. Data volume is described as manageable with no arithmetic behind it. Or security is a closing paragraph about encryption, ignoring device identity, updates and physical access in a domain where all three are central.
One more habit lifts a deployment proposal noticeably. Say what the organization would do differently on the day the data starts arriving. Deployments that produce dashboards nobody acts on are a well documented failure pattern, and naming the specific action, the person who takes it and the threshold that triggers it turns a technology proposal into an operational one. It also makes the sampling rate and retention decisions easier to justify, because both follow from how the data is actually used.
A worthwhile final check: take your data volume figure and multiply it by a year. If the resulting number would be uncomfortable to defend in a budget conversation, either the retention policy or the sampling rate needs revisiting, and saying that in the document is a strong sign of judgement.
WGU attaches no grade penalty to a revised and resubmitted performance assessment, 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 carries an objective assessment, WGU objective assessments are proctored and our boundary is fixed: preparation only, with protocol drills, requirement derivation practice and a candid read on your preassessment result. Nobody here sits an assessment, give no help from the moment it starts, and we neither ask for nor accept portal credentials.
Deployment proposal starting from devices?
Send the D337 rubric and scenario. We rebuild it from decision to measurement to device, with the volume arithmetic and word targets included.
Eight mistakes that cost time in D337
- Starting from the device. Start from the decision, derive the measurement, then choose hardware. Reverse order shows in every later section.
- Arbitrary sampling rates. Tie the rate to how fast the measured phenomenon changes, and say so.
- No volume calculation. Devices times readings times bytes drives transport, storage and cost. Do the arithmetic once and reuse it.
- Ideal-condition range figures. Specifications assume clear line of sight. Warehouses, freezers and factories do not provide it.
- Security added at the end. Device identity, updates and physical access are design constraints, not a closing paragraph.
- Assuming devices never fail. A fleet degrades. Say how a dead sensor is noticed and what happens to the gap in the data.
- Treating sensor data as impersonal. Occupancy, movement and usage patterns can identify people by inference.
- No end-of-life plan. Devices outlive support. Say what happens when updates stop arriving.
Three questions students ask about D337
Do I need to buy sensors or a development board?
How much networking knowledge does this assume?
Is ITEC 2114 the same as D337?
Where D337 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.