Exam SY0-601 All QuestionsBrowse all questions from this exam
Question 616

While troubleshooting a firewall configuration, a technician determines that a "deny any" policy should be added to the bottom of the ACL. The technician updates the policy, but the new policy causes several company servers to become unreachable. Which of the following actions would prevent this issue?

    Correct Answer: B

    To prevent the issue of making several company servers unreachable, testing the policy in a non-production environment is crucial. By doing so, the technician can identify any unintended consequences or conflicts before applying the policy to the production network. This step ensures that any potential issues are addressed in a controlled setting, thereby minimizing the risk of disrupting critical services when the policy is implemented in the live environment.

Discussion
DChildsOption: A

At first I thought B but I realize how impractical that would be in the real world. Unlike applications, you cannot deploy firewall policies in a test environment as the rules are declarative (you know something is getting blocked even if you don't know what exactly that will be). So, I'd go with A because the Change Advisory Board needs to go through the request, gauge the risks, rollback actions and points etc.

Jacksoms

Just when I thought we have started getting correct answers from examtopics lol

jkalfoOption: B

this is a dumba** question . how is submitting a change request going to prevent the issue ... i understand you have to let people know before you make changes but it still doesnt make sense , not to me anyway

Gigi42Option: A

I have to look over my notes from A+. I believe that before anyone can make changes within the network, a request needs to be implemented. You can't can't go about making changing. Look what he did?

scoobysnack209Option: B

In Palo Alto Firewall you can test the policy before you commit. The answer is B

Mehe323

Agreed. Also A doesn't do anything directly to address the issue. I think B is the step before A.

AbdullahMohammad251Option: B

I would go with B Applying the "deny any" policy in a real environment would still make the servers unreachable even after getting approval from the change management team. We must use sandboxing to test the policy in a non-productive environment before applying it to our systems.

russianOption: B

Chat GPT: "B. Testing the policy in a non-production environment before enabling the policy in the production network. Explanation: Testing the policy in a non-production environment allows the technician to assess its impact and ensure that it does not cause unintended consequences, such as making company servers unreachable. By testing in a controlled environment first, any issues or conflicts can be identified and addressed before implementing the policy in the production network. Documenting the new policy in a change request and submitting it to change management (Option A) is a good practice for tracking changes but may not necessarily prevent the issue from occurring. Disabling intrusion prevention signatures on the "deny any" policy (Option C) is unrelated to ensuring that the policy does not affect server accessibility. Including an "allow any" policy above the "deny any" policy (Option D) would negate the purpose of the "deny any" policy and could potentially introduce security risks."

YomzieOption: A

The correct answer is option A. Before any drastic change is implemented in a PROD environment, a Change Management Request is first raised. The process of approval would factor in what the overall business impact would be, and that helps to determine when the change should be carried out, and what the Rollback Plan would be if need be.

TitanbugOption: B

In order to avoid problems such as rendering company servers inaccessible, it is essential to thoroughly test any modifications, particularly a "deny any" policy, in a non-production or test environment prior to implementing it on the production network. This enables the technician to discover and address any unintended repercussions or problems before they affect active systems.

marcperreroOption: B

: While documenting changes and submitting them through change management is good practice for tracking modifications, it does not directly prevent the issue of servers becoming unreachable. It's more about procedural control than technical prevention.

DapsieOption: B

To prevent this issue, the best thing to do is to test the policy in a non-PROD environment. Even if you submit a change request(The first step in the process), it still makes sense to test before deployment. A change approval won't prevent this issue.

MarleighOption: B

Despite what everyone is saying, I still think it is B. I don't see why it isn't possible to test policies in a segmented/isolated/whatever network away from prod. Like what was the point about learning of VLANs if we are just going to pretend they dont exist for these questions? Maybe this is showing my lack of IRL network experience. But, I also already have my net+, and I dont see this as unrealistic or impractical. So I will stick to my gut and say B.

Mehe323Option: B

I think is should be B, don't you need to present something to management and state the reason why this is the best solution? So, you do B before doing A?

spearousOption: A

A should be correct. yes, like other said, B is too general, and for network, you can't really test firewall in a test env. the network/number of servers/server IPs are entirely different between prod and test.

MF757Option: B

Testing the policy in a non-production environment before deploying it in the production network would help identify any potential issues or unintended consequences, such as causing several company servers to become unreachable.

shaneo007Option: B

Answer B I think it would be best to test the new policy first for any issue. Then . Documenting the new policy in a change request and submitting the request to change management.

ganymedeOption: A

A. Documenting the new policy in a change request and submitting the request to change management