Welcome to today’s practice test!
Today’s practice test is based on subdomain 1.3 (Explain the importance of change management processes and the impact to security) from the CompTIA Security+ SY0-701 objectives.
This beginner-level practice test is inspired by the CompTIA Security+ (SY0-701) exam and is designed to help you reinforce key cybersecurity concepts on a daily basis.
These questions are not official exam questions, but they reflect topics and scenarios relevant to the Security+ certification. Use them to test your knowledge, identify areas for improvement, and build daily cybersecurity habits.
Click the button below to start today’s practice exam.
Results
#1. A security administrator at a financial institution is proposing a patch deployment for a critical vulnerability. What step must occur before implementation to ensure change control compliance?
#2. A company frequently deploys updates without coordination, leading to unexpected outages. Which business process can address this issue?
#3. What documentation ensures everyone knows the exact timing and procedure for a change to a production environment?
#4. An analyst identifies dependencies on outdated systems during a proposed software change. What risk does this present?
#5. Which component ensures that configuration diagrams and documentation reflect current architecture after changes?
#6. A failed software update disables user authentication services. What should be executed immediately?
#7. Which of the following is a technical implication that must be considered in a change management process?
#8. Why should test results be reviewed before implementing a security patch?
#9. A cloud provider is implementing new firewall rules. Which document must be updated to reflect this?
#10. A security administrator at a financial firm needs to update a firewall rule set during off-peak hours. Which of the following BEST ensures business continuity and accountability?
Note: CompTIA and Security+ are registered trademarks of CompTIA. This content is not affiliated with or endorsed by CompTIA.
To view CompTIA Security+ practice tests on other days, click here.To view answers and explanations for today’s questions, expand the Answers accordion below.
Answers
| Number | Answer | Explanation |
|---|---|---|
| 1 | C | Before implementing a patch for a critical vulnerability, it’s crucial to perform an impact analysis. This mandatory step for change control involves assessing potential risks, downtime, and effects on systems and services to ensure the change (patch) won’t cause unintended disruptions or create new issues. Rollback procedures are steps to take if a change fails, not a step before implementation to ensure compliance. While the incident response plan might eventually need updates based on new systems or threats, it’s not a pre-implementation step for a specific patch deployment’s change control compliance. A vulnerability scan would typically occur after the patch to verify its effectiveness, or as part of a regular security assessment, but it’s not the primary pre-implementation step for change control compliance on the patch itself. |
| 2 | B | A Change Approval Board (CAB) review is a formal business process specifically designed to evaluate, approve, and schedule proposed changes (like updates) to IT systems. Its purpose is to ensure changes are coordinated, minimize risks, and prevent unexpected outages, directly addressing the described issue. A risk register documents known risks, but simply updating it doesn’t solve the underlying problem of uncoordinated updates leading to outages. Continuous integration is a development practice for merging code frequently; while it aids development speed and quality, it doesn’t, by itself, manage the deployment coordination that prevents unexpected outages in a broader operational context. Asset tagging is for inventory management and tracking physical or logical assets. It has no direct role in coordinating system updates to prevent outages. |
| 3 | C | A Change Request (CR) is the primary documentation that formally proposes a change and typically includes its exact timing, detailed procedures for implementation, rollback plans, and the expected impact on the production environment. It serves as the central record for coordinating and communicating the change. A Service level agreement (SLA) defines the expected level of service and uptime, but it does not detail the timing or procedures for specific changes. An impact analysis assesses the potential effects of a change; it’s a component of a change request process, but not the document that communicates the timing and procedure to everyone. Root cause analysis (RCA) is conducted after an incident or problem to determine its underlying causes, not before a change to communicate its details. |
| 4 | A | When a proposed software change depends on outdated systems, the primary risk is incompatibility. The new software might not function correctly with the old system, leading to failures. Furthermore, if issues arise, rolling back the change becomes more complicated because the old system might not easily revert or integrate with the newer components that were partially deployed. Test automation generally improves availability by catching issues early, not reducing it. Dependencies on outdated systems don’t inherently lead to reduced availability because of test automation. Mean time to recovery (MTTR) is the average time it takes to recover from a system failure. Dependencies on outdated systems would likely increase MTTR due to the complexities of troubleshooting and resolving issues, not accelerate it. Outdated system dependencies might require a longer or more complex maintenance window due to potential issues. They don’t inherently shorten it. |
| 5 | C | Version control systems (like Git) are designed precisely to track changes over time to files, including configuration diagrams, architectural documentation, and code. By committing every change, these systems ensure a historical record, facilitate collaboration, and allow teams to guarantee that the latest committed version reflects the current architecture. Chain of custody is a legal term referring to the documented chronological history of physical evidence, not for managing IT documentation. An asset inventory lists what assets exist, but it doesn’t manage the detailed configurations or architectural relationships in diagrams and documentation as they change. Penetration testing is a security assessment method that looks for vulnerabilities, it doesn’t ensure documentation accuracy after changes. |
| 6 | A | When a critical system like user authentication services fails due to a software update, the immediate priority is to restore service. A backout plan contains the predefined steps to revert the failed change and restore the system to its previous working state, minimizing downtime. A root cause analysis is performed after the service is restored to understand why the failure occurred and prevent recurrence, not immediately during the outage. A business impact analysis (BIA) is a pre-emptive process to understand the impact of potential disruptions. It’s not an action executed during an outage. Patch validation is typically performed before a broad deployment to confirm the patch works as expected, or after a successful deployment to verify its effects. It’s not the immediate action during a critical failure. |
| 7 | B | A service restart is a direct technical implication that often must occur when implementing changes (e.g., applying patches, configuration updates) to production systems for the changes to take effect. This necessitates planning for potential downtime and coordination. A maintenance window is a scheduled period of time for changes, an operational consideration, not a technical implication of the change itself. Stakeholder mapping is a management and communication activity, not a technical implication of a change. Test result review is a quality assurance activity to verify the change, not a technical implication of the change’s execution. |
| 8 | C | Reviewing test results before implementing a security patch is crucial to validate that the patch achieves its intended security fix without introducing new vulnerabilities or causing unintended side effects (negative impacts), such as system instability or functional issues. While the patch might affect uptime, confirming uptime metrics is typically an ongoing monitoring activity, not the primary reason for reviewing pre-implementation test results. Version parity refers to ensuring software versions are consistent across environments. While part of a well-managed change, it’s not the primary reason for reviewing test results of a security patch. GDPR is a data privacy regulation. While security patches contribute to overall data security, the act of reviewing test results for a patch is a general security best practice, not a specific GDPR compliance step. |
| 9 | A | Standard Operating Procedures (SOPs) document the routine, step-by-step instructions for tasks. Implementing new firewall rules is a operational procedure, and the SOPs for network security, change management, or firewall administration would need to be updated to reflect these new rules to ensure consistency and compliance. A vulnerability report documents identified security weaknesses. It’s an input to why rules might have to change, but not the document that reflects the new rules themselves. A security incident log records details of security events or breaches. It’s a historical record, not a document for current operational rules. A penetration test script outlines steps for security testing. It’s used to test the effectiveness of security controls, not to document the controls themselves. |
| 10 | C | Scheduling a change during the maintenance window with proper documentation directly addresses both business continuity and accountability. Scheduling during off-peak hours (a maintenance window) minimizes disruption, while proper documentation ensures the change is planned, reviewed, approved, and auditable, maintaining accountability. Making changes immediately, especially in a financial firm, risks uncoordinated outages and lacks accountability, directly violating business continuity principles. While notification is important, it’s a communication step, not a comprehensive approach that ensures continuity or accountability for the change itself. Restarting services might be a step in the change, but it’s not the overarching practice that ensures continuity and accountability. |