STATUS: STAGED — NOT YET AVAILABLE TO ACTIVE STUDENTS.
This lab becomes available when your instructor announces that CyDeploy
Community Edition has been installed in the lab environment.
ACS Security Operations has an approved change request: a service that serves no
business purpose must be stopped and disabled.
Stopping a service takes ten seconds. Proving that the change did what was asked
— and nothing else — is the actual job.
Your job is to capture the state of your pod before the change, apply the
approved change, capture the state afterwards, compare the two, and record a
defensible PASS or FAIL determination.
By the end of this lab you will be able to:
| System | Where | What you use it for |
|---|---|---|
PODXX-SRV (via Guacamole) |
Your Guacamole connection list | Reading the change request and recording your response |
| Your pod application host | Named in the change request | Applying the approved change |
| CyDeploy Community Edition | As installed by your instructor | Before-and-after collection |
| Your pod artifact folder | C:\CyberLab\PodXX\SI-Artifacts\CyDeploy\ |
Change request, worksheets, and your response file |
Collect and change your own pod only. Both collections must use the same
scope, or the comparison is meaningless.
C:\CyberLab\PodXX\SI-Artifacts\CyDeploy\.PXX_Change_Scenario.txt and PXX_Change_Request.docx. Note the changePXX_Baseline_Worksheet.docx:
PXX_Change_Validation_Report.docx:
StudentResponses\SI-M5-L3.json in Notepad and fill in:
analyst — your student nametarget_item — the item named in the change requestbaseline_recorded — "yes" only if you collected the baseline firstbaseline_state — the state before the changepost_change_state — the state after the changeunintended_changes_observed — "none observed", or describe what you founddetermination — PASS or FAILevidence — what your two collections showedcompleted — trueA determination of PASS means: the intended condition changed, and the
comparison shows no unintended change. If either half is not true, your
determination must reflect that.
| Evidence | File |
|---|---|
| Completed baseline worksheet | PXX_Baseline_Worksheet.docx |
| Completed validation report | PXX_Change_Validation_Report.docx |
| Completed response file | StudentResponses\SI-M5-L3.json |
Verification is automatic. You do not run anything yourself, and you do not need
access to AWX.
SI-M5-L3.json response file.I applied the change before running the baseline collection.
Tell your instructor. Do not claim baseline_recorded: "yes" — a change you
cannot compare against a baseline is not validated, and inventing a baseline
after the fact is falsifying evidence.
The two collections differ in many places.
Check that both used the same scope, and that time-based details (timestamps,
uptime, log counts) are not being mistaken for configuration changes. Note them
as observations rather than configuration differences.
The service will not stop or will not stay disabled.
Record exactly what happened, and tell your instructor. A change that cannot be
applied is a FAIL with evidence — not a lab you should skip.
CyDeploy output is hard to compare by hand.
Compare the specific items you listed in your baseline worksheet first, then scan
the rest. That is why section 3 of the baseline worksheet exists.
The tracker says my post-change state is wrong.
Your recorded state must show the service both stopped and disabled, as the
change request asked.
I cannot edit the JSON file.
Open it with Notepad and keep the JSON valid.