SY0-701 Question 27
Single answerA security administrator is preparing to deploy application allow listing on several Windows servers that host a legacy payroll application. The vendor documentation warns that the application relies on unsigned helper executables, a deprecated Java runtime, and a third-party reporting service that starts automatically after the main application launches. Management wants the security team to reduce malware risk without causing an outage during payroll processing. Which action should the administrator take FIRST to best support a secure and stable deployment?
- A
Enable a default-deny allow list policy in enforcement mode on all payroll servers during the next payroll run to quickly identify anything that is blocked
- B
Create and test the allow list in audit mode on a non-production system, documenting all application dependencies and any required service or application restarts before production rollout
- C
Block the deprecated Java runtime immediately with a deny list, because deny lists are less likely than allow lists to affect legacy application behavior
- D
Restart only the third-party reporting service after applying the allow list, because dependencies started by the main application are automatically permitted
Show answer and explanation
Correct answer: B
Explanation
The best first step is to build and validate the allow list in audit mode in a non-production or test environment, then document dependencies and operational impacts such as downtime, service restarts, and application restarts before moving to enforcement in production. This is especially important with legacy applications, which frequently rely on unsigned binaries, outdated runtimes, child processes, and supporting services that are not fully documented. Security best practices for application control emphasize phased deployment, testing, dependency mapping, and change management to avoid business disruption. In Microsoft AppLocker and Windows Defender Application Control guidance, audit-first approaches are commonly recommended so administrators can identify what would be blocked before enforcing rules. From a Security+ perspective, the key technical implication is balancing stronger execution control with compatibility, dependency awareness, and availability.
- A. Incorrect.
This is incorrect because enabling a default-deny allow list directly in enforcement mode on production systems without prior testing creates a significant risk of downtime. Legacy applications often depend on helper processes, runtimes, scripts, and services that may not be obvious. Applying the policy during a payroll run is especially risky because any blocked dependency could interrupt business operations.
- B. Correct.
This is correct because testing in audit mode allows the administrator to observe what executables, scripts, libraries, and services the legacy payroll application actually uses before enforcing restrictions. Documenting dependencies and restart requirements is critical for change planning, especially when service restarts or full application restarts may be needed for policy changes to take effect. This approach aligns with security best practices for reducing operational risk while implementing stronger controls.
- C. Incorrect.
This is incorrect because immediately deny listing the deprecated Java runtime could break the legacy payroll application if it depends on that runtime. Deny lists are generally weaker than allow lists for application control because they only block known items and do not comprehensively prevent unapproved execution. The misconception is that deny lists are safer for legacy environments; in reality, they may still cause outages if a required component is blocked.
- D. Incorrect.
This is incorrect because dependencies are not automatically permitted simply because they are launched by an approved application. Many application control technologies evaluate each executable or script separately. Also, assuming that only one supporting service needs a restart ignores the possibility that the main application, Java runtime, or system services may need to be restarted for policy changes to take effect.