Documentation and Change Management practice questions

Deploy the application to all laptops and disable the VPN client on each.

Why wrong: Disabling the VPN client without approval could disrupt business operations and violates the change management process.

Continue with the deployment and note the conflict in the change log.

Why wrong: Continuing deployment without resolving the conflict risks widespread issues and bypasses the pilot’s purpose.

Uninstall the VPN client from all laptops and reinstall after the deployment.

Why wrong: Uninstalling the VPN client without a change request is unauthorized and could cause connectivity loss for users.

Reboot the print server to clear any temporary errors.

Why wrong: Rebooting might help transient issues but does not address the firmware change itself and could waste time.

Submit a new change request to update the firmware again.

Why wrong: Submitting a new change request does not resolve the current outage and delays restoration of service.

Disable the printer in Active Directory and re-add it.

Why wrong: This action does not address the firmware change and is unlikely to fix the connectivity issue.

Attempt to roll back the update using the server’s built-in recovery options.

Why wrong: While attempting a rollback is logical, without a documented plan, the technician risks making the situation worse and should escalate first.

Continue troubleshooting until the maintenance window ends, then document the failure.

Why wrong: Continuing to troubleshoot without a plan risks exceeding the maintenance window, causing business impact, and delaying escalation.

Reboot the server to clear the error and retry the update.

Why wrong: Rebooting without understanding the error could lead to data loss or system instability, and does not address the lack of a rollback plan.

Ignore the missing setting since the SOP was followed.

Why wrong: Ignoring a critical security setting leaves the server vulnerable and is not acceptable, even if the SOP was followed.

Submit a change request to update the SOP without applying the setting.

Why wrong: Submitting a change request without fixing the current server leaves it exposed; the setting should be applied immediately.

Revert the server configuration and wait for an updated SOP.

Why wrong: Reverting the configuration is unnecessary and delays the server deployment; the technician can apply the setting and update the SOP concurrently.

Proceed with the firmware update and document the change afterward.

Why wrong: Proceeding without CAB approval violates change management policy, especially when the change plan is incomplete.

Use the old switch firmware on the new switch to match the documentation.

Why wrong: Using incompatible firmware could damage the switch or cause network issues, and it bypasses the proper process.

Implement the switch and create a separate change request for the firmware.

Why wrong: Implementing first and requesting later is risky; the CAB should be involved before making changes that deviate from the approved plan.

The change log did not include a rollback plan.

Why wrong: While a rollback plan is important, the issue here is the lack of documentation for the password change step, not the rollback.

The change request was not approved by the change advisory board.

Why wrong: Approval is important, but the core failure is the omission of the password change from the documentation.

The technician did not perform a post-implementation review.

Why wrong: A post-implementation review might have caught the issue, but the primary failure is the lack of detailed documentation during the change.

Delete the change log entry to avoid confusion.

Why wrong: Deleting entries violates documentation best practices and removes valuable audit information.

Send an email to the user explaining the fix.

Why wrong: While communication is good, the primary documentation step is updating the change log; email alone is insufficient.

Create a new change request to revert the group policy.

Why wrong: Creating a new change request may be needed if the fix involves a permanent policy change, but the immediate step is to document the resolution.

Wait for the next CAB meeting to report the change.

Why wrong: Waiting could delay necessary documentation and approval; the technician should notify the CAB immediately.

Revert the patch and wait for CAB approval.

Why wrong: Reverting a critical security patch during an active exploit would leave the system vulnerable, which is not advisable.

Delete the change log entry to avoid accountability.

Why wrong: Deleting entries is unethical and violates documentation policies; it could lead to disciplinary action.

Skip the backup for this laptop and proceed with the patch installation.

Why wrong: Skipping the backup violates the change management policy and could lead to data loss if the patch causes issues.

Install the patch anyway and create a manual restore point.

Why wrong: A manual restore point is not a full system backup and does not satisfy the change management requirement.

Report the failure to the change manager and request an exception.

Why wrong: While reporting is good, the technician should first attempt to resolve the backup failure before escalating, as it may be a simple fix.

Restore the user’s system from a backup taken before the update.

Why wrong: Restoring from backup is a possible remediation, but it should be done only after understanding the change and attempting a rollback if available.

Uninstall the update immediately to restore functionality.

Why wrong: Uninstalling without consulting documentation may bypass the approved rollback process and could cause additional issues.

Escalate the issue to the IT manager for a decision.

Why wrong: Escalation may be needed later, but the technician should first review the change log to gather information before escalating.

Disable the backup job immediately to restore network stability.

Why wrong: Disabling a scheduled backup without authorization could lead to data loss and violates change management.

Increase the network bandwidth to accommodate the backup traffic.

Why wrong: Increasing bandwidth without a change request bypasses the process and may not address the root cause.

Ignore the issue since the backup is a critical process.

Why wrong: Ignoring the outage is unacceptable; the impact must be documented and addressed.

A list of user passwords for the application.

Why wrong: User passwords are sensitive and should not be documented in a deployment plan; they are provisioned separately.

A detailed network topology diagram.

Why wrong: While useful, a network topology diagram is not directly needed for a standardized software installation.

A copy of the software license agreement.

Why wrong: The license agreement is important but does not help standardize the installation process.

Proceed with the deployment since the registry change is necessary for the new software.

Why wrong: Proceeding without approval violates change management and could break the legacy application.

Modify the script to skip the registry change and continue.

Why wrong: Modifying the script without authorization is also a change that needs approval.

Document the registry change after the deployment is complete.

Why wrong: Post-deployment documentation does not mitigate the risk of breaking the legacy application during the rollout.

The server's warranty information.

Why wrong: Warranty info is useful but not a prerequisite for performing an approved change.

The network topology diagram.

Why wrong: The network diagram is not directly relevant to a hard drive replacement.

The employee handbook.

Why wrong: The employee handbook does not contain technical change details.

The network topology diagram.

Why wrong: The network diagram shows connections, not internal hardware components like a RAID controller.

The change management log.

Why wrong: The change log records the approval process, not the resulting hardware configuration.

The knowledge base article for RAID troubleshooting.

Why wrong: A knowledge base article is general guidance, not a record of the specific server's configuration.

The printer driver was corrupted by a virus.

Why wrong: While possible, the scenario points to a missing documentation record, not a security incident.

The technician forgot to save the change log before leaving for the day.

Why wrong: Forgetting to save is less likely than an automatic update that was never documented in the first place.

The customer accidentally deleted the update history.

Why wrong: The customer would not have access to the technician's change log.

Restore the application from the last known good backup.

Why wrong: Restoring without documenting the unauthorized change bypasses the change management process and may hide the root cause.

Uninstall the update and reinstall the previous version of the application.

Why wrong: Reversing the change without following the change management process can lead to inconsistency and lack of accountability.

Contact the software vendor to request a patch for the crash.

Why wrong: Contacting the vendor is premature; the first step is to address the unauthorized change internally.

The exact date and time the rule was added.

Why wrong: Date and time are important but secondary to the business justification.

The IP address of the new employee's remote location.

Why wrong: The IP address is technical detail but does not explain why the change was made.

The name of the technician who made the change.

Why wrong: The technician's name is useful but not as critical as the reason for the change.

The name of the junior admin who applied the patch.

Why wrong: While the admin's name may be recorded, the most critical documentation is the reason the patch was applied outside the window.

The exact time the patch was applied.

Why wrong: Time is important but secondary to understanding why the change occurred outside the approved window.

The patch's version number and source.

Why wrong: Version details are useful but do not address the procedural violation.

Continue upgrading the remaining workstations since the change was approved.

Why wrong: Continuing despite a known failure would multiply the impact and violate the change management principle of risk assessment.

Restore the first workstation to the previous OS and complete the rest without changes.

Why wrong: Restoring without documenting the issue ignores the need for root cause analysis and proper change control.

Research a hotfix for the application and apply it to all workstations.

Why wrong: Applying a hotfix without CAB approval bypasses change management and could introduce new issues.