Trick 1: "An allow list blocks only malicious applications." True or False?
FALSE — an allow list blocks EVERYTHING not explicitly approved.
This is one of the most commonly confused concepts. An allow list doesn't care whether software is malicious or not — it blocks anything not on the approved list, including perfectly legitimate new software you haven't added yet.
A deny list is what blocks specifically identified malicious software (antivirus). An allow list blocks by default with exceptions for approved items. Knowing the direction of the default matters enormously on the exam.
This is one of the most commonly confused concepts. An allow list doesn't care whether software is malicious or not — it blocks anything not on the approved list, including perfectly legitimate new software you haven't added yet.
A deny list is what blocks specifically identified malicious software (antivirus). An allow list blocks by default with exceptions for approved items. Knowing the direction of the default matters enormously on the exam.
Trick 2: "If an approved change requires a minor additional update to complete, can the technician make that update without a new change request?"
It depends — and this nuance matters on the exam.
Prof. Messer specifically addresses this. The general rule is: stick to the approved scope. But if a minor, necessary adjustment is required to complete the PRIMARY change — and the organization's policies permit it — the technician may make that adjustment.
The key criteria: (1) it must be truly minor, (2) it must be required to complete the primary change, (3) the organization's change management policy must explicitly allow it, and (4) it must be documented.
This is NOT permission to add whatever you want. It's a narrow exception for truly necessary ancillary actions.
Prof. Messer specifically addresses this. The general rule is: stick to the approved scope. But if a minor, necessary adjustment is required to complete the PRIMARY change — and the organization's policies permit it — the technician may make that adjustment.
The key criteria: (1) it must be truly minor, (2) it must be required to complete the primary change, (3) the organization's change management policy must explicitly allow it, and (4) it must be documented.
This is NOT permission to add whatever you want. It's a narrow exception for truly necessary ancillary actions.
Trick 3: "Legacy applications shouldn't be touched — you should just document the 'don't touch' sign and move on." True or False?
FALSE — documentation and gradual support are the correct approach.
Prof. Messer explicitly addresses the "don't touch" legacy system. The correct approach: study the application, document how it's installed and what it depends on, and gradually bring it into the normal support cycle.
"Don't touch" is not a security posture — it's a gap. An undocumented legacy system running on unsupported OS is a significant security risk. The path forward is documentation, understanding, and eventually migration — not perpetual avoidance.
Prof. Messer explicitly addresses the "don't touch" legacy system. The correct approach: study the application, document how it's installed and what it depends on, and gradually bring it into the normal support cycle.
"Don't touch" is not a security posture — it's a gap. An undocumented legacy system running on unsupported OS is a significant security risk. The path forward is documentation, understanding, and eventually migration — not perpetual avoidance.
Trick 4: "Dependencies only affect the system being changed." True or False?
FALSE — dependencies frequently span multiple systems.
This is exactly the firewall management software example: upgrading the management software required first upgrading the physical firewalls. The dependency was on a completely different class of hardware.
Always ask: "What else depends on the thing I'm changing? What does the thing I'm changing depend on?" Dependencies can span services, applications, hardware, and even remote sites.
This is exactly the firewall management software example: upgrading the management software required first upgrading the physical firewalls. The dependency was on a completely different class of hardware.
Always ask: "What else depends on the thing I'm changing? What does the thing I'm changing depend on?" Dependencies can span services, applications, hardware, and even remote sites.
Trick 5: "Version control is only for software developers." True or False?
FALSE — version control applies to any configuration that changes over time.
Prof. Messer specifically calls out: router configurations, Windows registry changes, application configuration files, scripts, GPO templates. Any configuration in your environment benefits from version control.
For the Security+ exam: version control in the context of change management = tracking infrastructure and configuration changes, not just source code. The ability to "click a button" to roll back to a previous configuration saves real incidents in production.
Prof. Messer specifically calls out: router configurations, Windows registry changes, application configuration files, scripts, GPO templates. Any configuration in your environment benefits from version control.
For the Security+ exam: version control in the context of change management = tracking infrastructure and configuration changes, not just source code. The ability to "click a button" to roll back to a previous configuration saves real incidents in production.
Performance Task: Your organization is deploying a new application to 1,000 servers across 10 data centers. The application requires: stopping a service, installing a new package, updating a config file, and restarting the service. Occasionally (5% of servers) the config update requires an OS reboot instead of just a service restart. Design the technical change management implementation plan.
Model Answer:
1. Pre-change preparation: Add the new package to the allow list. Verify the package is accessible from all 10 data centers. Prepare rollback scripts. Take configuration snapshots of 5 representative servers.
2. Batched deployment strategy:
- Batch 1: 10 servers (1 per data center) — manual verification
- Batch 2: 100 servers if Batch 1 succeeds — automated with monitoring
- Batch 3: remaining 890 servers — automated deployment
3. Restart classification: Automate the deployment script to detect whether an OS reboot is required (check installer exit code or a reboot-pending flag). For service-restart servers: quick turnaround. For reboot servers: flag for the maintenance window where reboot can be scheduled.
4. Rollback plan: If a batch fails above a threshold (e.g., >2% failure rate), halt deployment. Automated rollback script restores previous package and config from version control snapshot.
5. Documentation: After completion, update the asset management system with the new application version for all 1,000 servers. Commit the updated configuration baseline to version control. Close the change request with batch-level success/failure statistics.
1. Pre-change preparation: Add the new package to the allow list. Verify the package is accessible from all 10 data centers. Prepare rollback scripts. Take configuration snapshots of 5 representative servers.
2. Batched deployment strategy:
- Batch 1: 10 servers (1 per data center) — manual verification
- Batch 2: 100 servers if Batch 1 succeeds — automated with monitoring
- Batch 3: remaining 890 servers — automated deployment
3. Restart classification: Automate the deployment script to detect whether an OS reboot is required (check installer exit code or a reboot-pending flag). For service-restart servers: quick turnaround. For reboot servers: flag for the maintenance window where reboot can be scheduled.
4. Rollback plan: If a batch fails above a threshold (e.g., >2% failure rate), halt deployment. Automated rollback script restores previous package and config from version control snapshot.
5. Documentation: After completion, update the asset management system with the new application version for all 1,000 servers. Commit the updated configuration baseline to version control. Close the change request with batch-level success/failure statistics.