1. An organization wants ONLY approved applications to execute on workstations. Which policy implements this?
Correct: B — An allow list permits only explicitly named applications. Everything else is blocked by default — the most restrictive application control approach.
2. During an approved change to upgrade a web server, the technician discovers the load balancer configuration also needs updating for the new server version. What is the CORRECT action?
Correct: B — Scope discipline: complete what was approved, document discoveries, submit separate requests. Don't expand scope mid-window.
3. Which restart type is the LEAST disruptive when a configuration change only requires a single background process to reload?
Correct: C — A service restart stops and restarts only the specific service needed. No full OS reboot, no power cycle — fastest and least disruptive option.
4. A company runs a 24/7 payment processing system. Which strategy BEST minimizes downtime when upgrades are applied to this system?
Correct: C — Primary/secondary failover allows changes to the primary while keeping the secondary running. Users are switched seamlessly. If the primary upgrade fails, simply point users back to the unchanged secondary.
5. Why is version control valuable in technical change management?
Correct: B — Version control creates a history of changes. You can compare current vs. previous configurations, identify what changed, and restore a known-good state when a change causes problems.
6. Matching — Match each technical change management concept to its description.
CONCEPT
Allow List
Deny List
Dependency
Version Control
DESCRIPTION
A requirement where one system needs another to function correctly
Only explicitly approved applications may run; all others blocked
System for tracking configuration changes over time with rollback capability
Everything runs except specifically named blocked applications
7. Analysis: An organization has a legacy billing application that has been running since 2003. No documentation exists. The developer is out of business. A new OS version needs to be deployed on the server it runs on. Describe the technical change management approach.
Model Answer:
1. Document before touching. Study how the legacy app is installed, what processes it runs, what ports/services it uses, what files it reads/writes, what database it connects to, what startup dependencies it has. Create documentation even if it's imperfect.
2. Clone the environment. Create a full VM snapshot of the current server. Build a test environment identical to the current state.
3. Test the OS upgrade in the clone. Install the new OS on the test VM. See if the billing app starts. Document every error.
4. Develop a compatibility remediation plan. Some legacy apps need compatibility layers (run in compatibility mode, use older runtime libraries). Document what's needed.
5. Keep the change narrow. If the OS upgrade has a high risk of breaking the app, consider: (a) postpone the OS upgrade until a migration path exists, or (b) plan a parallel application migration project.
6. Always have a backout. Full server backup before any production change. Test the restore procedure.
1. Document before touching. Study how the legacy app is installed, what processes it runs, what ports/services it uses, what files it reads/writes, what database it connects to, what startup dependencies it has. Create documentation even if it's imperfect.
2. Clone the environment. Create a full VM snapshot of the current server. Build a test environment identical to the current state.
3. Test the OS upgrade in the clone. Install the new OS on the test VM. See if the billing app starts. Document every error.
4. Develop a compatibility remediation plan. Some legacy apps need compatibility layers (run in compatibility mode, use older runtime libraries). Document what's needed.
5. Keep the change narrow. If the OS upgrade has a high risk of breaking the app, consider: (a) postpone the OS upgrade until a migration path exists, or (b) plan a parallel application migration project.
6. Always have a backout. Full server backup before any production change. Test the restore procedure.
8. Evaluation: A developer argues that allow lists are too restrictive for a development environment — developers constantly install new tools. Evaluate: when should an organization use an allow list vs. a deny list?
Model Answer:
The developer's concern is valid — allow lists impose significant overhead in environments where software changes frequently. The choice depends on the environment's security requirements and operational needs:
Use allow lists when: High-security environment (financial, healthcare, government). Known, fixed software set (kiosks, POS terminals, servers with defined roles). Insider threat is a significant concern. Regulatory compliance requires it.
Use deny lists when: Dynamic environments (developer workstations, research labs). Users need flexibility to install new tools frequently. The operational overhead of maintaining an allow list outweighs the security benefit.
Practical middle ground: Many organizations use a hybrid — allow lists on production servers and high-security endpoints, deny lists on general user workstations, and separate policies for developer machines. The security level should match the risk profile of the system.
The developer's concern is valid — allow lists impose significant overhead in environments where software changes frequently. The choice depends on the environment's security requirements and operational needs:
Use allow lists when: High-security environment (financial, healthcare, government). Known, fixed software set (kiosks, POS terminals, servers with defined roles). Insider threat is a significant concern. Regulatory compliance requires it.
Use deny lists when: Dynamic environments (developer workstations, research labs). Users need flexibility to install new tools frequently. The operational overhead of maintaining an allow list outweighs the security benefit.
Practical middle ground: Many organizations use a hybrid — allow lists on production servers and high-security endpoints, deny lists on general user workstations, and separate policies for developer machines. The security level should match the risk profile of the system.