WGU · D522 · PY T H O N F O R I T A U T O M AT I O N
REST API Integration
and Authentication
60 Practice Questions · 20 Python Labs · 5 Capstone Projects · 100 Points
HTTP · OAuth 2.0 · JWT · requests · JSON · API Security
Western Governors University · 2026/2027
60 20 5 30/50/20
QUESTIONS HANDS- ON L ABS PROJECTS RECALL / APP /
A N A LY S I S
COURSE
D522 — Python for IT Automation · REST API Integration and Authentication Workbook, Practice Questions
with Rationales · Western Governors University · 2026/2027
WORKBOOK TYPE
Sixty scenario and code-based questions with complete rationales, a paired answer key, a method and status
reference, an authentication and security reference, a requests library reference, an index of the twenty labs
and five capstone projects, two worked exemplars, and a taxonomy of insecure and syntactically flawed patterns
COVERAGE
REST architecture and statelessness, HTTP methods and idempotency, status-code handling, headers, payload
formats, pagination, conditional requests and redirects · API keys, Basic authentication, OAuth 2.0 authorization
code with PKCE and client credentials, JWT structure and validation, scopes, token lifecycle, TLS verification,
input validation and rate limiting · requests sessions, timeouts, retries, exception hierarchy, JSON parsing,
streaming and proxy configuration · lab and capstone architecture, ServiceNow-style ticketing, cloud
management APIs, secure data sync, webhooks, GraphQL versus REST, AI-generated documentation and API
gateway management
I T E M F O R M AT
Four options (A–D), one correct answer · 75% scenario or code-based, 25% direct · every rationale names the
module or method, the protocol rule, and the precise defect in each distractor
CONTENTS
Part 2 — answer key, method and status reference, security reference, requests reference, the twenty labs, the
five projects, two worked exemplars, distractor taxonomy · Part 3 — 1.667 points per item, partial-credit
matrix, eight gates, mastery thresholds, section floors, seventy-five-minute plan, 2026/2027 notes
Print-ready · US Letter · 100 points · 60 questions · 20 labs · 5 projects · code-level rationales
,WGU D522 · Python for IT Automation · 2026/2027
Contents
Part 1 holds 60 practice questions in four sections of fifteen — REST fundamentals, HTTP methods and
status codes (Q1–Q15); authentication, authorization and security (Q16–Q30); the Python requests library,
JSON parsing and error handling (Q31–Q45); and hands-on lab scenarios, capstone projects and
2026/2027 updates (Q46–Q60) — each worth 1.667 points. Part 2 supplies the paired answer key, a
method and status reference, an authentication and security reference, a requests reference, the index of
the twenty labs and five capstone projects, two worked exemplars, and a taxonomy of distractor errors.
Part 3 sets the scoring, the partial-credit matrix for integration work, the eight review gates, the mastery
thresholds, the section floors and the seventy-five-minute plan.
Section 1: REST API Fundamentals, HTTP Methods, and Status Codes 3
Section 2: Authentication, Authorization, and Security (OAuth, API Keys, JWT) 9
Section 3: Python requests Library, JSON Parsing, and Error Handling 15
Section 4: Hands-On Lab Scenarios, Capstone Projects, & 2026/2027 API Updates 21
Part 2: Complete Solution Key, Lab Index, Project Briefs and Exemplars 29
Part 3: Grading Rubric and Solution Key 36
WORKBOOK BLUEPRINT
Question sections: REST and HTTP (Q1–Q15, 25 points) · auth and security (Q16–Q30, 25 points) · requests, JSON
and errors (Q31–Q45, 25 points) · labs, projects and updates (Q46–Q60, 25 points)
Cognitive mix: recall 18 items (30%) · application 30 items (50%) · analysis 12 items (20%) | Format: 45
scenario or code-based items (75%) · 15 direct items (25%) | Answer position: option C in every item, with the
working call carried by the option text
Scoring: 60 items × 1.667 points = 100 points · partial credit 1.0 for a correct concept with a misaligned header or
accessor, 0.75 for correct method with wrong status handling, 0.5 for naming a control but implementing it
insecurely · mastery 90–100, proficient 78–89.9, approaching proficiency 70–77.9, with a ten-of-fifteen floor in
every section
60 questions · 100 points · 20 labs · 5 projects · 75-minute sitting Page 2 of 39
,WGU D522 · Python for IT Automation · 2026/2027 Section 1 · REST & HTTP
Section 1: REST API Fundamentals, HTTP Methods, and Status Codes
Items: Q1–Q15 · 15 questions · 25 points · 25% of the quiz
Q1. Which property defines a REST API as stateless, and what does it require of each request?
A. The server stores client session state between calls, so the client sends only a session identifier after
the first request.
B. The client caches all responses locally, so the server never needs to be contacted twice for the same
resource.
C. Each request carries every credential, identifier and parameter needed to satisfy it, and the server
keeps no client context between calls. CORRECT
D. The API must use only GET requests, because state-changing operations would otherwise be retained
on the server.
Correct Answer: C
Rationale: Step 1 — statelessness is an architectural constraint in which each request is self-describing, so any
server instance can handle it without reference to earlier calls. Step 2 — that is why the bearer token, API key
or signed parameters must be sent on every call, and why horizontal scaling and load balancing are simple.
Step 3 — caching is a separate optional constraint, and method choice is unrelated to statelessness. Option A
describes a server-side session store, which is the stateful pattern REST avoids; option B confuses caching with
statelessness and misstates how caches work; option D restricts the method vocabulary for a reason that has
nothing to do with state.
Q2. An automation script reads a list of open incidents every five minutes. Which method is correct,
and why?
A. POST, because the query is sent as a payload that describes what to retrieve.
B. PUT, because repeated reads should replace the cached representation on the server.
C. GET, because the operation is safe and idempotent and returns a representation without changing
server state. CORRECT
D. PATCH, because the request modifies the response object in place.
Correct Answer: C
Rationale: Step 1 — a read has no side effects, so it must use the safe method, GET, which gateways and
caches can treat as repeatable. Step 2 — idempotency follows: calling GET ten times leaves the resource
unchanged, so retry logic is safe. Step 3 — search-style APIs that need a body are the documented exception
and are usually exposed as POST to a query endpoint, but a simple filter belongs in query parameters. Option A
sacrifices cacheability and semantics for no gain; option B would imply a full replacement of the resource;
option D is a write method and would fail or corrupt data.
60 questions · 100 points · 20 labs · 5 projects · 75-minute sitting Page 3 of 39
, WGU D522 · Python for IT Automation · 2026/2027 Section 1 · REST & HTTP
Q3. A script must change only the status field of an existing ticket and leave the other forty fields
untouched. Which method and body are correct?
A. PUT with the entire ticket object, because full replacement is the only way to guarantee consistency.
B. POST to the ticket URL, because the change is an action on the resource.
C. PATCH with a body containing only the fields to change, for example the status field. CORRECT
D. GET with query parameters that carry the new value, because the server applies them on retrieval.
Correct Answer: C
Rationale: Step 1 — PATCH applies a partial modification, so the payload contains only the changed members
and the server merges them. Step 2 — PUT replaces the whole representation, which means every unspecified
field risks being reset to a default or null, the classic cause of data loss in automation. Step 3 — POST creates
or invokes and does not express a partial edit on an existing resource. Option A is the common mistake of using
PUT for a single-field change; option B misuses POST; option D uses a safe method to attempt a write, which
the server will ignore or reject.
Q4. A cleanup script issues DELETE twice on the same resource. The first call returns 204 and the
second returns 404. What does this show?
A. DELETE is not idempotent, because the status code changed between the two calls.
B. The script must retry until it receives the same status code twice, proving completion.
C. DELETE is idempotent in effect: the resource state is identical after both calls even though the status
code differs. CORRECT
D. The second call proves the first never executed, so the resource still exists.
Correct Answer: C
Rationale: Step 1 — idempotency is defined on server state, not on the response code: after one or many
identical requests the resource remains deleted. Step 2 — 404 on the repeat call is a correct report that the
resource no longer exists, and a well-written client treats 204 and 404 as equally successful for a delete. Step 3
— the response code may differ while the effect does not, which is why retry logic for deletes is safe. Option A
confuses the code with the state; option B would make a cleanup script loop forever; option D inverts the
meaning of 404, which indicates absence.
Q5. A POST creates a new resource successfully. Which status code and header should the client
expect, and what should it do with them?
A. 200 with the created object in the body, and the client must parse the identifier from the payload only.
B. 302 with a redirect to the collection, and the client must re-fetch the entire collection to find the new
item.
C. 201 with a Location header containing the new resource URL, so the client can read the identifier
without scanning the collection. CORRECT
D. 204 with no body, because a create operation should not return content.
Correct Answer: C
Rationale: Step 1 — 201 Created is the defined response for a request that creates a resource, and the
Location header carries its URL. Step 2 — the client should read the identifier from Location, which is cheaper
and more reliable than searching a collection listing. Step 3 — a body may also be returned, but it is not
required, and 204 means no content, which says nothing about creation. Option A is not wrong about the body
but omits the standard header and forces parsing; option B misuses a redirect; option D discards the identifier
the client needs for later calls.
60 questions · 100 points · 20 labs · 5 projects · 75-minute sitting Page 4 of 39
REST API Integration
and Authentication
60 Practice Questions · 20 Python Labs · 5 Capstone Projects · 100 Points
HTTP · OAuth 2.0 · JWT · requests · JSON · API Security
Western Governors University · 2026/2027
60 20 5 30/50/20
QUESTIONS HANDS- ON L ABS PROJECTS RECALL / APP /
A N A LY S I S
COURSE
D522 — Python for IT Automation · REST API Integration and Authentication Workbook, Practice Questions
with Rationales · Western Governors University · 2026/2027
WORKBOOK TYPE
Sixty scenario and code-based questions with complete rationales, a paired answer key, a method and status
reference, an authentication and security reference, a requests library reference, an index of the twenty labs
and five capstone projects, two worked exemplars, and a taxonomy of insecure and syntactically flawed patterns
COVERAGE
REST architecture and statelessness, HTTP methods and idempotency, status-code handling, headers, payload
formats, pagination, conditional requests and redirects · API keys, Basic authentication, OAuth 2.0 authorization
code with PKCE and client credentials, JWT structure and validation, scopes, token lifecycle, TLS verification,
input validation and rate limiting · requests sessions, timeouts, retries, exception hierarchy, JSON parsing,
streaming and proxy configuration · lab and capstone architecture, ServiceNow-style ticketing, cloud
management APIs, secure data sync, webhooks, GraphQL versus REST, AI-generated documentation and API
gateway management
I T E M F O R M AT
Four options (A–D), one correct answer · 75% scenario or code-based, 25% direct · every rationale names the
module or method, the protocol rule, and the precise defect in each distractor
CONTENTS
Part 2 — answer key, method and status reference, security reference, requests reference, the twenty labs, the
five projects, two worked exemplars, distractor taxonomy · Part 3 — 1.667 points per item, partial-credit
matrix, eight gates, mastery thresholds, section floors, seventy-five-minute plan, 2026/2027 notes
Print-ready · US Letter · 100 points · 60 questions · 20 labs · 5 projects · code-level rationales
,WGU D522 · Python for IT Automation · 2026/2027
Contents
Part 1 holds 60 practice questions in four sections of fifteen — REST fundamentals, HTTP methods and
status codes (Q1–Q15); authentication, authorization and security (Q16–Q30); the Python requests library,
JSON parsing and error handling (Q31–Q45); and hands-on lab scenarios, capstone projects and
2026/2027 updates (Q46–Q60) — each worth 1.667 points. Part 2 supplies the paired answer key, a
method and status reference, an authentication and security reference, a requests reference, the index of
the twenty labs and five capstone projects, two worked exemplars, and a taxonomy of distractor errors.
Part 3 sets the scoring, the partial-credit matrix for integration work, the eight review gates, the mastery
thresholds, the section floors and the seventy-five-minute plan.
Section 1: REST API Fundamentals, HTTP Methods, and Status Codes 3
Section 2: Authentication, Authorization, and Security (OAuth, API Keys, JWT) 9
Section 3: Python requests Library, JSON Parsing, and Error Handling 15
Section 4: Hands-On Lab Scenarios, Capstone Projects, & 2026/2027 API Updates 21
Part 2: Complete Solution Key, Lab Index, Project Briefs and Exemplars 29
Part 3: Grading Rubric and Solution Key 36
WORKBOOK BLUEPRINT
Question sections: REST and HTTP (Q1–Q15, 25 points) · auth and security (Q16–Q30, 25 points) · requests, JSON
and errors (Q31–Q45, 25 points) · labs, projects and updates (Q46–Q60, 25 points)
Cognitive mix: recall 18 items (30%) · application 30 items (50%) · analysis 12 items (20%) | Format: 45
scenario or code-based items (75%) · 15 direct items (25%) | Answer position: option C in every item, with the
working call carried by the option text
Scoring: 60 items × 1.667 points = 100 points · partial credit 1.0 for a correct concept with a misaligned header or
accessor, 0.75 for correct method with wrong status handling, 0.5 for naming a control but implementing it
insecurely · mastery 90–100, proficient 78–89.9, approaching proficiency 70–77.9, with a ten-of-fifteen floor in
every section
60 questions · 100 points · 20 labs · 5 projects · 75-minute sitting Page 2 of 39
,WGU D522 · Python for IT Automation · 2026/2027 Section 1 · REST & HTTP
Section 1: REST API Fundamentals, HTTP Methods, and Status Codes
Items: Q1–Q15 · 15 questions · 25 points · 25% of the quiz
Q1. Which property defines a REST API as stateless, and what does it require of each request?
A. The server stores client session state between calls, so the client sends only a session identifier after
the first request.
B. The client caches all responses locally, so the server never needs to be contacted twice for the same
resource.
C. Each request carries every credential, identifier and parameter needed to satisfy it, and the server
keeps no client context between calls. CORRECT
D. The API must use only GET requests, because state-changing operations would otherwise be retained
on the server.
Correct Answer: C
Rationale: Step 1 — statelessness is an architectural constraint in which each request is self-describing, so any
server instance can handle it without reference to earlier calls. Step 2 — that is why the bearer token, API key
or signed parameters must be sent on every call, and why horizontal scaling and load balancing are simple.
Step 3 — caching is a separate optional constraint, and method choice is unrelated to statelessness. Option A
describes a server-side session store, which is the stateful pattern REST avoids; option B confuses caching with
statelessness and misstates how caches work; option D restricts the method vocabulary for a reason that has
nothing to do with state.
Q2. An automation script reads a list of open incidents every five minutes. Which method is correct,
and why?
A. POST, because the query is sent as a payload that describes what to retrieve.
B. PUT, because repeated reads should replace the cached representation on the server.
C. GET, because the operation is safe and idempotent and returns a representation without changing
server state. CORRECT
D. PATCH, because the request modifies the response object in place.
Correct Answer: C
Rationale: Step 1 — a read has no side effects, so it must use the safe method, GET, which gateways and
caches can treat as repeatable. Step 2 — idempotency follows: calling GET ten times leaves the resource
unchanged, so retry logic is safe. Step 3 — search-style APIs that need a body are the documented exception
and are usually exposed as POST to a query endpoint, but a simple filter belongs in query parameters. Option A
sacrifices cacheability and semantics for no gain; option B would imply a full replacement of the resource;
option D is a write method and would fail or corrupt data.
60 questions · 100 points · 20 labs · 5 projects · 75-minute sitting Page 3 of 39
, WGU D522 · Python for IT Automation · 2026/2027 Section 1 · REST & HTTP
Q3. A script must change only the status field of an existing ticket and leave the other forty fields
untouched. Which method and body are correct?
A. PUT with the entire ticket object, because full replacement is the only way to guarantee consistency.
B. POST to the ticket URL, because the change is an action on the resource.
C. PATCH with a body containing only the fields to change, for example the status field. CORRECT
D. GET with query parameters that carry the new value, because the server applies them on retrieval.
Correct Answer: C
Rationale: Step 1 — PATCH applies a partial modification, so the payload contains only the changed members
and the server merges them. Step 2 — PUT replaces the whole representation, which means every unspecified
field risks being reset to a default or null, the classic cause of data loss in automation. Step 3 — POST creates
or invokes and does not express a partial edit on an existing resource. Option A is the common mistake of using
PUT for a single-field change; option B misuses POST; option D uses a safe method to attempt a write, which
the server will ignore or reject.
Q4. A cleanup script issues DELETE twice on the same resource. The first call returns 204 and the
second returns 404. What does this show?
A. DELETE is not idempotent, because the status code changed between the two calls.
B. The script must retry until it receives the same status code twice, proving completion.
C. DELETE is idempotent in effect: the resource state is identical after both calls even though the status
code differs. CORRECT
D. The second call proves the first never executed, so the resource still exists.
Correct Answer: C
Rationale: Step 1 — idempotency is defined on server state, not on the response code: after one or many
identical requests the resource remains deleted. Step 2 — 404 on the repeat call is a correct report that the
resource no longer exists, and a well-written client treats 204 and 404 as equally successful for a delete. Step 3
— the response code may differ while the effect does not, which is why retry logic for deletes is safe. Option A
confuses the code with the state; option B would make a cleanup script loop forever; option D inverts the
meaning of 404, which indicates absence.
Q5. A POST creates a new resource successfully. Which status code and header should the client
expect, and what should it do with them?
A. 200 with the created object in the body, and the client must parse the identifier from the payload only.
B. 302 with a redirect to the collection, and the client must re-fetch the entire collection to find the new
item.
C. 201 with a Location header containing the new resource URL, so the client can read the identifier
without scanning the collection. CORRECT
D. 204 with no body, because a create operation should not return content.
Correct Answer: C
Rationale: Step 1 — 201 Created is the defined response for a request that creates a resource, and the
Location header carries its URL. Step 2 — the client should read the identifier from Location, which is cheaper
and more reliable than searching a collection listing. Step 3 — a body may also be returned, but it is not
required, and 204 means no content, which says nothing about creation. Option A is not wrong about the body
but omits the standard header and forces parsing; option B misuses a redirect; option D discards the identifier
the client needs for later calls.
60 questions · 100 points · 20 labs · 5 projects · 75-minute sitting Page 4 of 39
