D522 V2 | Python for IT Automation | Task 1 Guide | August 2026
WGU D522 V2
Python for IT Automation
Task 1 Performance Assessment Guide & Original Exemplar | August 2026 Updated
Original Task 1 workflow diagram created for this guide.
Network discovery • device inventory • DHCP/reachability • DNS validation • API/ticketing •
notifications • remediation • GitLab evidence
Research current through August 29, 2026
Important academic-integrity and alignment note
This is an independent study guide and implementation exemplar. It is not an official WGU document and is
not a completed submission that should be represented as someone else's work. The public WGU catalog does
not publish the private Task 1 rubric. Use your live Task 1 page, the current D522 Reference Guide Detailed,
and the assigned lab as the controlling sources. Replace all examples with your own code, observations,
repository history, and unaltered screenshots.
Page 1
, D522 V2 | Python for IT Automation | Task 1 Guide | August 2026
1. What Is Confirmed for D522 in August 2026?
The August 2026 WGU Institutional Catalog lists D522 as Python for IT Automation, a 3-CU School of
Technology course. WGU describes the course as using Python fundamentals, program-flow control,
decision-making, and automation of IT tasks/processes to support secure, scalable, resilient networks and
systems. [1][2]
WGU does not publicly post the current Task 1 rubric. To understand the V2 assessment format, this guide
cross-checks recent June-August 2026 learner reports. Those reports consistently describe a transition to a
hands-on PA with two tasks, a GitLab workflow, a virtual GNS3-based lab, and Task 1 code that is reused
heavily in Task 2. [3][4][5][6]
Item August 2026 status How this guide treats it
D522 title and high-level course scope Officially confirmed Anchor for all technical content.
3 CUs Officially confirmed Context only; not an assessment
requirement.
V2 uses project-style performance Strongly corroborated by current Used for preparation, but live portal
assessments learners controls.
Task 1 feeds Task 2 Repeatedly reported by successful The exemplar is modular and reusable.
learners
GitLab / virtual lab / GNS3 / VS Code Repeatedly reported Detailed setup/evidence guidance.
B2 device/DHCP/reachability/DNS work Repeatedly reported; exact wording Explained as a reasoning pattern, not
private copied rubric text.
Ticket/email/remediation/evidence Repeatedly reported Covered with fictional, non-WGU-
specific examples.
Exact file names, headings, screenshot Portal-controlled Checklist tells you to verify before
count submission.
Pass-readiness, not a guarantee
No third-party document can guarantee an evaluator result. A pass depends on the current rubric, your live
lab behavior, your own repository and commit history, and evidence that demonstrates every requirement.
1.1 High-value learner reports to account for
A learner who passed both V2 tasks on August 26, 2026 reported that Task 1 is substantially harder
than Task 2 and that Task 2 reuses almost all Task 1 code. [3]
The same report identifies the device-information/DHCP/reachability/DNS portion (referred to as B2) as
the most important and difficult Task 1 area, and recommends storing observations for later use. [3]
Recent learners repeatedly recommend building small functions and calling them from main rather
than writing one long unstructured block. [3][4]
One learner reported a Task 1 return solely because a required screenshot was missing even though
the code worked. [3]
Learner reports emphasize that later remediation logic should be repeatable: after the first repair,
subsequent runs should not crash or reapply unnecessary changes. [3]
An August 27, 2026 submission discussion reports a GitLab branch link plus branch/commit-history
artifacts as part of the Task 1 submission workflow. Verify the exact upload rules in your portal. [7]
Page 2
, D522 V2 | Python for IT Automation | Task 1 Guide | August 2026
2. Task 1 Architecture: Build the Data Pipeline Before the
Features
The safest design is a pipeline in which each stage enriches a device record and preserves enough state for
the next stage. Do not throw away DHCP, reachability, DNS, ticket, or remediation results after printing
them. Store them in structured Python objects.
Original data-model diagram. Use a normalized record so later functions do not rediscover the same information.
State field Purpose Typical value (fictional)
name Human-readable device identity edge-rtr-01
host / console_port Connection target supplied by lab localhost / 5001
device_type Selects the correct network_os, linux, windows
connection/command strategy
dhcp_context DHCP server/lease context discovered 192.0.2.5 or lease metadata
for the device
reachable Outcome of required reachability test True / False / exempt
observed_dns DNS server(s) actually returned ["192.0.2.53"]
expected_dns Policy/baseline appropriate to this ["192.0.2.53", "192.0.2.54"]
device
dns_status Explicit classification compliant / affected / unknown / error
reason Why the classification was assigned unexpected DNS server
ticket_id Ticketing result if required INC-EXAMPLE-1042
remediated Whether authorized corrective action True / False
occurred
device = {
"name": "edge-rtr-01",
"host": "localhost",
"console_port": 5001,
"device_type": "network_os",
"reachable": None,
Page 3
WGU D522 V2
Python for IT Automation
Task 1 Performance Assessment Guide & Original Exemplar | August 2026 Updated
Original Task 1 workflow diagram created for this guide.
Network discovery • device inventory • DHCP/reachability • DNS validation • API/ticketing •
notifications • remediation • GitLab evidence
Research current through August 29, 2026
Important academic-integrity and alignment note
This is an independent study guide and implementation exemplar. It is not an official WGU document and is
not a completed submission that should be represented as someone else's work. The public WGU catalog does
not publish the private Task 1 rubric. Use your live Task 1 page, the current D522 Reference Guide Detailed,
and the assigned lab as the controlling sources. Replace all examples with your own code, observations,
repository history, and unaltered screenshots.
Page 1
, D522 V2 | Python for IT Automation | Task 1 Guide | August 2026
1. What Is Confirmed for D522 in August 2026?
The August 2026 WGU Institutional Catalog lists D522 as Python for IT Automation, a 3-CU School of
Technology course. WGU describes the course as using Python fundamentals, program-flow control,
decision-making, and automation of IT tasks/processes to support secure, scalable, resilient networks and
systems. [1][2]
WGU does not publicly post the current Task 1 rubric. To understand the V2 assessment format, this guide
cross-checks recent June-August 2026 learner reports. Those reports consistently describe a transition to a
hands-on PA with two tasks, a GitLab workflow, a virtual GNS3-based lab, and Task 1 code that is reused
heavily in Task 2. [3][4][5][6]
Item August 2026 status How this guide treats it
D522 title and high-level course scope Officially confirmed Anchor for all technical content.
3 CUs Officially confirmed Context only; not an assessment
requirement.
V2 uses project-style performance Strongly corroborated by current Used for preparation, but live portal
assessments learners controls.
Task 1 feeds Task 2 Repeatedly reported by successful The exemplar is modular and reusable.
learners
GitLab / virtual lab / GNS3 / VS Code Repeatedly reported Detailed setup/evidence guidance.
B2 device/DHCP/reachability/DNS work Repeatedly reported; exact wording Explained as a reasoning pattern, not
private copied rubric text.
Ticket/email/remediation/evidence Repeatedly reported Covered with fictional, non-WGU-
specific examples.
Exact file names, headings, screenshot Portal-controlled Checklist tells you to verify before
count submission.
Pass-readiness, not a guarantee
No third-party document can guarantee an evaluator result. A pass depends on the current rubric, your live
lab behavior, your own repository and commit history, and evidence that demonstrates every requirement.
1.1 High-value learner reports to account for
A learner who passed both V2 tasks on August 26, 2026 reported that Task 1 is substantially harder
than Task 2 and that Task 2 reuses almost all Task 1 code. [3]
The same report identifies the device-information/DHCP/reachability/DNS portion (referred to as B2) as
the most important and difficult Task 1 area, and recommends storing observations for later use. [3]
Recent learners repeatedly recommend building small functions and calling them from main rather
than writing one long unstructured block. [3][4]
One learner reported a Task 1 return solely because a required screenshot was missing even though
the code worked. [3]
Learner reports emphasize that later remediation logic should be repeatable: after the first repair,
subsequent runs should not crash or reapply unnecessary changes. [3]
An August 27, 2026 submission discussion reports a GitLab branch link plus branch/commit-history
artifacts as part of the Task 1 submission workflow. Verify the exact upload rules in your portal. [7]
Page 2
, D522 V2 | Python for IT Automation | Task 1 Guide | August 2026
2. Task 1 Architecture: Build the Data Pipeline Before the
Features
The safest design is a pipeline in which each stage enriches a device record and preserves enough state for
the next stage. Do not throw away DHCP, reachability, DNS, ticket, or remediation results after printing
them. Store them in structured Python objects.
Original data-model diagram. Use a normalized record so later functions do not rediscover the same information.
State field Purpose Typical value (fictional)
name Human-readable device identity edge-rtr-01
host / console_port Connection target supplied by lab localhost / 5001
device_type Selects the correct network_os, linux, windows
connection/command strategy
dhcp_context DHCP server/lease context discovered 192.0.2.5 or lease metadata
for the device
reachable Outcome of required reachability test True / False / exempt
observed_dns DNS server(s) actually returned ["192.0.2.53"]
expected_dns Policy/baseline appropriate to this ["192.0.2.53", "192.0.2.54"]
device
dns_status Explicit classification compliant / affected / unknown / error
reason Why the classification was assigned unexpected DNS server
ticket_id Ticketing result if required INC-EXAMPLE-1042
remediated Whether authorized corrective action True / False
occurred
device = {
"name": "edge-rtr-01",
"host": "localhost",
"console_port": 5001,
"device_type": "network_os",
"reachable": None,
Page 3
