How to Configure Cloud NGFW Threat Signatures to Log and Drop Packets?

Your organization deployed a mission critical application that is expected to be a new revenue source. As part of the planning and deployment process, you have recently implemented a security profile with the default set of threat signatures provided by Cloud Next Generation Firewall (Cloud NGFW). This application is the only application running on this project. You need to increase the security posture of the application to log the threat and drop the related packets. What should you do?

  1. Configure a new default threat signature with Deny All to all severity options. Review the logs to understand the impact.
  2. Set up a Linux VM as the frontend gateway for the application. Create iptables rules to drop all packets, excluding the application port.
  3. For all severity options (critical, high, medium, low and informational) in the security profile, change the default override action to Deny. Source Reference Answer
  4. Configure Cloud Scheduler to run a task that checks the Cloud NGFW logs to verify the threats. Configure the task to create a security profile with each signature ID set to override the default action.

Community Votes

C
50%
B
25%
A
25%

50% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

Tests overriding default threat signature actions in Cloud NGFW security profiles, with the common trap being hesitation to drop informational severity traffic or confusing configuration steps with external automation.

This question tests configuring Cloud NGFW threat prevention profiles to enforce stricter security by overriding default signature actions. The community consensus confirms that changing the default override action to Deny across all severities is the correct method to log and drop malicious traffic.

Option A is frequently chosen because it appears more cautious, but creating a new default threat signature is not how Cloud NGFW handles profile-level overrides; administrators must modify existing profile settings directly via the default override action.

Community Discussion (4 comments)

7103685 👍 1 Selected: C
I don´t know what the answer is but A and C seem the same to me. As A contain part of the statament"you have recently implemented a security profile with the default set of threat signatures provided by Cloud Next Generation Firewall (Cloud NGFW)"
Gwendal 👍 1 Selected: C
Deny: logs the threat and drops the packet. https://cloud.google.com/firewall/docs/about-security-profiles#threat-prevention-profile
Popa 👍 1 Selected: A
The most balanced and effective approach seems to align better with A: A. Configure a new default threat signature with Deny All to all severity options. Review the logs to understand the impact. Why A Could Be Correct: Proactive Logging and Review: This option allows you to test and analyze the impact of a more aggressive blocking policy, while simultaneously reviewing logs to fine-tune the security profile before putting it into production. Incremental Improvement: By observing the behavior of the application and understanding what is being blocked, you can avoid negatively affecting legitimate traffic while improving the security posture over time.
1f01b87 👍 1 Selected: B
Not sure what the right answer is here. But C doesn't make sense as it will drop traffic for ALL severity options, including informational. This could impact legitimate traffic.

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Expert Analysis

Why the Answer Is Correct

In Cloud NGFW, security profiles use threat signatures with configurable default actions. Changing the default override action to Deny for all severity levels ensures that matching traffic is both logged and dropped, directly fulfilling the requirement to block threats while maintaining visibility. This centralized approach aligns with Palo Alto Networks best practices for threat prevention management.

Why the Other Options Are Wrong

Option A incorrectly suggests creating a new signature rather than modifying the profile's override settings, which would not apply globally as intended. Option B introduces an unnecessary Linux VM and iptables, bypassing the native Cloud NGFW capabilities entirely. Option D relies on Cloud Scheduler and manual task creation, which is overly complex, error-prone, and not supported for real-time threat policy enforcement.

Community Comment Notes

Several candidates noted confusion between Options A and C, highlighting the importance of understanding profile-level versus signature-level configurations. Comment [2] correctly points out that the Deny action inherently logs and drops packets, referencing official documentation. Others like Comment [4] express concern about dropping informational traffic, but in mission-critical environments with strict security postures, explicit deny rules are often prioritized over potential false positives.

Official Reference

Exam Strategy

Focus on understanding how Cloud NGFW security profiles handle threat prevention overrides rather than relying on external tools or manual workarounds. Always verify whether a question requires native policy configuration versus third-party integration when designing secure architectures.

Related Analysis

You have provisioned a Cloud Interconnect connection with a

S-Grade

Your organization wants to set up hybrid connectivity with V

S-Grade

You are responsible for designing a new connectivity solutio

S-Grade

Practice All PCNE Questions

Access 80 questions with complete answers and detailed explanations.

View Full PCNE Practice Test →

← Back to PCNE Study Guide