Palo Alto Networks NetSec-Pro TLS SSH Decryption And Decryption Policy Practice Test
This Palo Alto Networks Network Security Professional practice test focuses on tls ssh decryption and decryption policy through original scenario-based questions aligned to the June 2026 NetSec-Pro blueprint. Use the full ExamSnap NetSec-Pro collection for broader practice across all current blueprint domains. For broader exam preparation, review the Palo Alto Networks NetSec-Pro Exam Dumps page.
Question 1
An engineer at Trey Research is troubleshooting a configuration decision. Which action directly addresses the need to inspect outbound TLS sessions initiated by internal users?
- Use SSL Inbound Inspection with access to the server certificate and private key where the deployment supports it
- Attach an appropriate decryption profile that enforces acceptable TLS protocol and certificate behavior
- Use SSL Forward Proxy decryption for matching outbound client traffic and deploy the required forward-trust certificate
- Check certificate trust, decryption logs, protocol support, and certificate-pinning behavior before creating an exception
- Make exceptions specific by source, destination, URL category, or application context and document the business reason
Correct answer: C
Explanation
- Inbound inspection decrypts traffic destined for a protected server whose certificate material is controlled by the organization. This can be valid in another context, but it does not directly satisfy the stated requirement(s): inspect outbound TLS sessions initiated by internal users.
- Decryption profiles let the firewall enforce cryptographic and certificate standards in addition to making content visible. This can be valid in another context, but it does not directly satisfy the stated requirement(s): inspect outbound TLS sessions initiated by internal users.
- SSL Forward Proxy places the firewall between internal clients and external TLS servers so encrypted application content can be inspected. This directly satisfies one of the stated requirement(s).
- Failures introduced by decryption commonly relate to trust, protocol negotiation, or applications that resist interception. This can be valid in another context, but it does not directly satisfy the stated requirement(s): inspect outbound TLS sessions initiated by internal users.
- Narrow exceptions reduce blind spots and make decryption policy easier to review and govern. This can be valid in another context, but it does not directly satisfy the stated requirement(s): inspect outbound TLS sessions initiated by internal users.
Learning point: NETSEC-T03-Q001: Use SSL Forward Proxy decryption for matching outbound client traffic and deploy the required forward-trust certificate.
Question 2
Which option best supports the goal to inspect inbound TLS traffic to an organization-owned HTTPS server in Wide World Importers’s Palo Alto Networks environment?
- Use SSH Proxy decryption for matching SSH sessions
- Use SSL Inbound Inspection with access to the server certificate and private key where the deployment supports it
- Use SSL Forward Proxy decryption for matching outbound client traffic and deploy the required forward-trust certificate
- Distribute the firewall forward-trust CA certificate to managed endpoints and protect the corresponding private key
- Create a narrowly scoped no-decrypt rule and place it appropriately in the decryption policy
Correct answer: B
Explanation
- SSH Proxy is the decryption mode used to inspect supported SSH traffic instead of leaving the encrypted tunnel opaque. This can be valid in another context, but it does not directly satisfy the stated requirement(s): inspect inbound TLS traffic to an organization-owned HTTPS server.
- Inbound inspection decrypts traffic destined for a protected server whose certificate material is controlled by the organization. This directly satisfies one of the stated requirement(s).
- SSL Forward Proxy places the firewall between internal clients and external TLS servers so encrypted application content can be inspected. This can be valid in another context, but it does not directly satisfy the stated requirement(s): inspect inbound TLS traffic to an organization-owned HTTPS server.
- Clients must trust the certificate authority used by the firewall to generate substitute server certificates during forward-proxy inspection. This can be valid in another context, but it does not directly satisfy the stated requirement(s): inspect inbound TLS traffic to an organization-owned HTTPS server.
- A specific no-decrypt rule provides an auditable exception without disabling decryption for unrelated traffic. This can be valid in another context, but it does not directly satisfy the stated requirement(s): inspect inbound TLS traffic to an organization-owned HTTPS server.
Learning point: NETSEC-T03-Q002: Use SSL Inbound Inspection with access to the server certificate and private key where the deployment supports it.
Question 3
A security review at Contoso Retail identifies a gap. The team wants to inspect SSH traffic for policy enforcement when SSH decryption is required. Which action should it take?
- Start with visibility and controlled policy scope, identify unsupported or pinned applications, then expand coverage deliberately
- Attach an appropriate decryption profile that enforces acceptable TLS protocol and certificate behavior
- Distribute the firewall forward-trust CA certificate to managed endpoints and protect the corresponding private key
- Use SSH Proxy decryption for matching SSH sessions
- Use separate forward-untrust handling so clients can recognize sessions to servers whose certificates are not trusted
Correct answer: D
Explanation
- A staged rollout lets the team discover compatibility issues and create justified exceptions instead of broadly disabling decryption. This can be valid in another context, but it does not directly satisfy the stated requirement(s): inspect SSH traffic for policy enforcement when SSH decryption is required.
- Decryption profiles let the firewall enforce cryptographic and certificate standards in addition to making content visible. This can be valid in another context, but it does not directly satisfy the stated requirement(s): inspect SSH traffic for policy enforcement when SSH decryption is required.
- Clients must trust the certificate authority used by the firewall to generate substitute server certificates during forward-proxy inspection. This can be valid in another context, but it does not directly satisfy the stated requirement(s): inspect SSH traffic for policy enforcement when SSH decryption is required.
- SSH Proxy is the decryption mode used to inspect supported SSH traffic instead of leaving the encrypted tunnel opaque. This directly satisfies one of the stated requirement(s).
- Forward-untrust behavior prevents the firewall from making an untrusted destination appear normally trusted to the client. This can be valid in another context, but it does not directly satisfy the stated requirement(s): inspect SSH traffic for policy enforcement when SSH decryption is required.
Learning point: NETSEC-T03-Q003: Use SSH Proxy decryption for matching SSH sessions.
Question 4
While validating a deployment for Fabrikam Health, an architect must ensure the design can exclude legally or operationally sensitive traffic from decryption. What should be done?
- Make exceptions specific by source, destination, URL category, or application context and document the business reason
- Check certificate trust, decryption logs, protocol support, and certificate-pinning behavior before creating an exception
- Attach an appropriate decryption profile that enforces acceptable TLS protocol and certificate behavior
- Create a narrowly scoped no-decrypt rule and place it appropriately in the decryption policy
- Use SSL Forward Proxy decryption for matching outbound client traffic and deploy the required forward-trust certificate
Correct answer: D
Explanation
- Narrow exceptions reduce blind spots and make decryption policy easier to review and govern. This can be valid in another context, but it does not directly satisfy the stated requirement(s): exclude legally or operationally sensitive traffic from decryption.
- Failures introduced by decryption commonly relate to trust, protocol negotiation, or applications that resist interception. This can be valid in another context, but it does not directly satisfy the stated requirement(s): exclude legally or operationally sensitive traffic from decryption.
- Decryption profiles let the firewall enforce cryptographic and certificate standards in addition to making content visible. This can be valid in another context, but it does not directly satisfy the stated requirement(s): exclude legally or operationally sensitive traffic from decryption.
- A specific no-decrypt rule provides an auditable exception without disabling decryption for unrelated traffic. This directly satisfies one of the stated requirement(s).
- SSL Forward Proxy places the firewall between internal clients and external TLS servers so encrypted application content can be inspected. This can be valid in another context, but it does not directly satisfy the stated requirement(s): exclude legally or operationally sensitive traffic from decryption.
Learning point: NETSEC-T03-Q004: Create a narrowly scoped no-decrypt rule and place it appropriately in the decryption policy.
Question 5
At Northwind Traders, the network security team needs to prevent certificate errors for sanctioned forward-proxy decryption. Which approach best meets the requirement?
- Use SSL Forward Proxy decryption for matching outbound client traffic and deploy the required forward-trust certificate
- Use SSH Proxy decryption for matching SSH sessions
- Use SSL Inbound Inspection with access to the server certificate and private key where the deployment supports it
- Distribute the firewall forward-trust CA certificate to managed endpoints and protect the corresponding private key
- Create a narrowly scoped no-decrypt rule and place it appropriately in the decryption policy
Correct answer: D
Explanation
- SSL Forward Proxy places the firewall between internal clients and external TLS servers so encrypted application content can be inspected. This can be valid in another context, but it does not directly satisfy the stated requirement(s): prevent certificate errors for sanctioned forward-proxy decryption.
- SSH Proxy is the decryption mode used to inspect supported SSH traffic instead of leaving the encrypted tunnel opaque. This can be valid in another context, but it does not directly satisfy the stated requirement(s): prevent certificate errors for sanctioned forward-proxy decryption.
- Inbound inspection decrypts traffic destined for a protected server whose certificate material is controlled by the organization. This can be valid in another context, but it does not directly satisfy the stated requirement(s): prevent certificate errors for sanctioned forward-proxy decryption.
- Clients must trust the certificate authority used by the firewall to generate substitute server certificates during forward-proxy inspection. This directly satisfies one of the stated requirement(s).
- A specific no-decrypt rule provides an auditable exception without disabling decryption for unrelated traffic. This can be valid in another context, but it does not directly satisfy the stated requirement(s): prevent certificate errors for sanctioned forward-proxy decryption.
Learning point: NETSEC-T03-Q005: Distribute the firewall forward-trust CA certificate to managed endpoints and protect the corresponding private key.
Question 6
Tailspin Energy is reviewing its Palo Alto Networks deployment. What should the administrator do to avoid silently trusting servers that present invalid certificates during forward-proxy decryption?
- Distribute the firewall forward-trust CA certificate to managed endpoints and protect the corresponding private key
- Start with visibility and controlled policy scope, identify unsupported or pinned applications, then expand coverage deliberately
- Create a narrowly scoped no-decrypt rule and place it appropriately in the decryption policy
- Use separate forward-untrust handling so clients can recognize sessions to servers whose certificates are not trusted
- Attach an appropriate decryption profile that enforces acceptable TLS protocol and certificate behavior
Correct answer: D
Explanation
- Clients must trust the certificate authority used by the firewall to generate substitute server certificates during forward-proxy inspection. This can be valid in another context, but it does not directly satisfy the stated requirement(s): avoid silently trusting servers that present invalid certificates during forward-proxy decryption.
- A staged rollout lets the team discover compatibility issues and create justified exceptions instead of broadly disabling decryption. This can be valid in another context, but it does not directly satisfy the stated requirement(s): avoid silently trusting servers that present invalid certificates during forward-proxy decryption.
- A specific no-decrypt rule provides an auditable exception without disabling decryption for unrelated traffic. This can be valid in another context, but it does not directly satisfy the stated requirement(s): avoid silently trusting servers that present invalid certificates during forward-proxy decryption.
- Forward-untrust behavior prevents the firewall from making an untrusted destination appear normally trusted to the client. This directly satisfies one of the stated requirement(s).
- Decryption profiles let the firewall enforce cryptographic and certificate standards in addition to making content visible. This can be valid in another context, but it does not directly satisfy the stated requirement(s): avoid silently trusting servers that present invalid certificates during forward-proxy decryption.
Learning point: NETSEC-T03-Q006: Use separate forward-untrust handling so clients can recognize sessions to servers whose certificates are not trusted.
Question 7
During a design review for Woodgrove Bank, the requirement is to phase in decryption without causing unnecessary business disruption. Which choice is most appropriate?
- Check certificate trust, decryption logs, protocol support, and certificate-pinning behavior before creating an exception
- Attach an appropriate decryption profile that enforces acceptable TLS protocol and certificate behavior
- Make exceptions specific by source, destination, URL category, or application context and document the business reason
- Start with visibility and controlled policy scope, identify unsupported or pinned applications, then expand coverage deliberately
- Use SSL Forward Proxy decryption for matching outbound client traffic and deploy the required forward-trust certificate
Correct answer: D
Explanation
- Failures introduced by decryption commonly relate to trust, protocol negotiation, or applications that resist interception. This can be valid in another context, but it does not directly satisfy the stated requirement(s): phase in decryption without causing unnecessary business disruption.
- Decryption profiles let the firewall enforce cryptographic and certificate standards in addition to making content visible. This can be valid in another context, but it does not directly satisfy the stated requirement(s): phase in decryption without causing unnecessary business disruption.
- Narrow exceptions reduce blind spots and make decryption policy easier to review and govern. This can be valid in another context, but it does not directly satisfy the stated requirement(s): phase in decryption without causing unnecessary business disruption.
- A staged rollout lets the team discover compatibility issues and create justified exceptions instead of broadly disabling decryption. This directly satisfies one of the stated requirement(s).
- SSL Forward Proxy places the firewall between internal clients and external TLS servers so encrypted application content can be inspected. This can be valid in another context, but it does not directly satisfy the stated requirement(s): phase in decryption without causing unnecessary business disruption.
Learning point: NETSEC-T03-Q007: Start with visibility and controlled policy scope, identify unsupported or pinned applications, then expand coverage deliberately.
Question 8
A change request at Alpine Ski House states that the team must protect decrypted traffic from weak protocol choices. What is the best response?
- Use SSL Forward Proxy decryption for matching outbound client traffic and deploy the required forward-trust certificate
- Use SSH Proxy decryption for matching SSH sessions
- Create a narrowly scoped no-decrypt rule and place it appropriately in the decryption policy
- Attach an appropriate decryption profile that enforces acceptable TLS protocol and certificate behavior
- Use SSL Inbound Inspection with access to the server certificate and private key where the deployment supports it
Correct answer: D
Explanation
- SSL Forward Proxy places the firewall between internal clients and external TLS servers so encrypted application content can be inspected. This can be valid in another context, but it does not directly satisfy the stated requirement(s): protect decrypted traffic from weak protocol choices.
- SSH Proxy is the decryption mode used to inspect supported SSH traffic instead of leaving the encrypted tunnel opaque. This can be valid in another context, but it does not directly satisfy the stated requirement(s): protect decrypted traffic from weak protocol choices.
- A specific no-decrypt rule provides an auditable exception without disabling decryption for unrelated traffic. This can be valid in another context, but it does not directly satisfy the stated requirement(s): protect decrypted traffic from weak protocol choices.
- Decryption profiles let the firewall enforce cryptographic and certificate standards in addition to making content visible. This directly satisfies one of the stated requirement(s).
- Inbound inspection decrypts traffic destined for a protected server whose certificate material is controlled by the organization. This can be valid in another context, but it does not directly satisfy the stated requirement(s): protect decrypted traffic from weak protocol choices.
Learning point: NETSEC-T03-Q008: Attach an appropriate decryption profile that enforces acceptable TLS protocol and certificate behavior.
Question 9
Contoso Retail has two related requirements: it must troubleshoot a TLS application that fails only when decryption is enabled, and it must also inspect inbound TLS traffic to an organization-owned HTTPS server. Which TWO actions best satisfy these requirements? Select two.
- Use SSL Forward Proxy decryption for matching outbound client traffic and deploy the required forward-trust certificate
- Attach an appropriate decryption profile that enforces acceptable TLS protocol and certificate behavior
- Use SSL Inbound Inspection with access to the server certificate and private key where the deployment supports it
- Check certificate trust, decryption logs, protocol support, and certificate-pinning behavior before creating an exception
- Make exceptions specific by source, destination, URL category, or application context and document the business reason
Correct answers: C, D
Explanation
- SSL Forward Proxy places the firewall between internal clients and external TLS servers so encrypted application content can be inspected. This can be valid in another context, but it does not directly satisfy the stated requirement(s): troubleshoot a TLS application that fails only when decryption is enabled; inspect inbound TLS traffic to an organization-owned HTTPS server.
- Decryption profiles let the firewall enforce cryptographic and certificate standards in addition to making content visible. This can be valid in another context, but it does not directly satisfy the stated requirement(s): troubleshoot a TLS application that fails only when decryption is enabled; inspect inbound TLS traffic to an organization-owned HTTPS server.
- Inbound inspection decrypts traffic destined for a protected server whose certificate material is controlled by the organization. This directly satisfies one of the stated requirement(s).
- Failures introduced by decryption commonly relate to trust, protocol negotiation, or applications that resist interception. This directly satisfies one of the stated requirement(s).
- Narrow exceptions reduce blind spots and make decryption policy easier to review and govern. This can be valid in another context, but it does not directly satisfy the stated requirement(s): troubleshoot a TLS application that fails only when decryption is enabled; inspect inbound TLS traffic to an organization-owned HTTPS server.
Learning point: NETSEC-T03-Q009: Check certificate trust, decryption logs, protocol support, and certificate-pinning behavior before creating an exception; Use SSL Inbound Inspection with access to the server certificate and private key where the deployment supports it.
Question 10
Which option best supports the goal to preserve inspection while limiting broad decryption exemptions in Adventure Works’s Palo Alto Networks environment?
- Make exceptions specific by source, destination, URL category, or application context and document the business reason
- Check certificate trust, decryption logs, protocol support, and certificate-pinning behavior before creating an exception
- Use SSL Forward Proxy decryption for matching outbound client traffic and deploy the required forward-trust certificate
- Attach an appropriate decryption profile that enforces acceptable TLS protocol and certificate behavior
- Start with visibility and controlled policy scope, identify unsupported or pinned applications, then expand coverage deliberately
Correct answer: A
Explanation
- Narrow exceptions reduce blind spots and make decryption policy easier to review and govern. This directly satisfies one of the stated requirement(s).
- Failures introduced by decryption commonly relate to trust, protocol negotiation, or applications that resist interception. This can be valid in another context, but it does not directly satisfy the stated requirement(s): preserve inspection while limiting broad decryption exemptions.
- SSL Forward Proxy places the firewall between internal clients and external TLS servers so encrypted application content can be inspected. This can be valid in another context, but it does not directly satisfy the stated requirement(s): preserve inspection while limiting broad decryption exemptions.
- Decryption profiles let the firewall enforce cryptographic and certificate standards in addition to making content visible. This can be valid in another context, but it does not directly satisfy the stated requirement(s): preserve inspection while limiting broad decryption exemptions.
- A staged rollout lets the team discover compatibility issues and create justified exceptions instead of broadly disabling decryption. This can be valid in another context, but it does not directly satisfy the stated requirement(s): preserve inspection while limiting broad decryption exemptions.
Learning point: NETSEC-T03-Q010: Make exceptions specific by source, destination, URL category, or application context and document the business reason.
Question 11
A security review at Proseware Services identifies a gap. The team wants to inspect outbound TLS sessions initiated by internal users. Which action should it take?
- Use SSL Forward Proxy decryption for matching outbound client traffic and deploy the required forward-trust certificate
- Use SSH Proxy decryption for matching SSH sessions
- Create a narrowly scoped no-decrypt rule and place it appropriately in the decryption policy
- Distribute the firewall forward-trust CA certificate to managed endpoints and protect the corresponding private key
- Use SSL Inbound Inspection with access to the server certificate and private key where the deployment supports it
Correct answer: A
Explanation
- SSL Forward Proxy places the firewall between internal clients and external TLS servers so encrypted application content can be inspected. This directly satisfies one of the stated requirement(s).
- SSH Proxy is the decryption mode used to inspect supported SSH traffic instead of leaving the encrypted tunnel opaque. This can be valid in another context, but it does not directly satisfy the stated requirement(s): inspect outbound TLS sessions initiated by internal users.
- A specific no-decrypt rule provides an auditable exception without disabling decryption for unrelated traffic. This can be valid in another context, but it does not directly satisfy the stated requirement(s): inspect outbound TLS sessions initiated by internal users.
- Clients must trust the certificate authority used by the firewall to generate substitute server certificates during forward-proxy inspection. This can be valid in another context, but it does not directly satisfy the stated requirement(s): inspect outbound TLS sessions initiated by internal users.
- Inbound inspection decrypts traffic destined for a protected server whose certificate material is controlled by the organization. This can be valid in another context, but it does not directly satisfy the stated requirement(s): inspect outbound TLS sessions initiated by internal users.
Learning point: NETSEC-T03-Q011: Use SSL Forward Proxy decryption for matching outbound client traffic and deploy the required forward-trust certificate.
Question 12
While validating a deployment for Wingtip Logistics, an architect must ensure the design can inspect inbound TLS traffic to an organization-owned HTTPS server. What should be done?
- Use separate forward-untrust handling so clients can recognize sessions to servers whose certificates are not trusted
- Start with visibility and controlled policy scope, identify unsupported or pinned applications, then expand coverage deliberately
- Use SSL Inbound Inspection with access to the server certificate and private key where the deployment supports it
- Attach an appropriate decryption profile that enforces acceptable TLS protocol and certificate behavior
- Distribute the firewall forward-trust CA certificate to managed endpoints and protect the corresponding private key
Correct answer: C
Explanation
- Forward-untrust behavior prevents the firewall from making an untrusted destination appear normally trusted to the client. This can be valid in another context, but it does not directly satisfy the stated requirement(s): inspect inbound TLS traffic to an organization-owned HTTPS server.
- A staged rollout lets the team discover compatibility issues and create justified exceptions instead of broadly disabling decryption. This can be valid in another context, but it does not directly satisfy the stated requirement(s): inspect inbound TLS traffic to an organization-owned HTTPS server.
- Inbound inspection decrypts traffic destined for a protected server whose certificate material is controlled by the organization. This directly satisfies one of the stated requirement(s).
- Decryption profiles let the firewall enforce cryptographic and certificate standards in addition to making content visible. This can be valid in another context, but it does not directly satisfy the stated requirement(s): inspect inbound TLS traffic to an organization-owned HTTPS server.
- Clients must trust the certificate authority used by the firewall to generate substitute server certificates during forward-proxy inspection. This can be valid in another context, but it does not directly satisfy the stated requirement(s): inspect inbound TLS traffic to an organization-owned HTTPS server.
Learning point: NETSEC-T03-Q012: Use SSL Inbound Inspection with access to the server certificate and private key where the deployment supports it.
Question 13
At Blue Yonder Airlines, the network security team needs to inspect SSH traffic for policy enforcement when SSH decryption is required. Which approach best meets the requirement?
- Check certificate trust, decryption logs, protocol support, and certificate-pinning behavior before creating an exception
- Make exceptions specific by source, destination, URL category, or application context and document the business reason
- Use SSL Forward Proxy decryption for matching outbound client traffic and deploy the required forward-trust certificate
- Use SSH Proxy decryption for matching SSH sessions
- Attach an appropriate decryption profile that enforces acceptable TLS protocol and certificate behavior
Correct answer: D
Explanation
- Failures introduced by decryption commonly relate to trust, protocol negotiation, or applications that resist interception. This can be valid in another context, but it does not directly satisfy the stated requirement(s): inspect SSH traffic for policy enforcement when SSH decryption is required.
- Narrow exceptions reduce blind spots and make decryption policy easier to review and govern. This can be valid in another context, but it does not directly satisfy the stated requirement(s): inspect SSH traffic for policy enforcement when SSH decryption is required.
- SSL Forward Proxy places the firewall between internal clients and external TLS servers so encrypted application content can be inspected. This can be valid in another context, but it does not directly satisfy the stated requirement(s): inspect SSH traffic for policy enforcement when SSH decryption is required.
- SSH Proxy is the decryption mode used to inspect supported SSH traffic instead of leaving the encrypted tunnel opaque. This directly satisfies one of the stated requirement(s).
- Decryption profiles let the firewall enforce cryptographic and certificate standards in addition to making content visible. This can be valid in another context, but it does not directly satisfy the stated requirement(s): inspect SSH traffic for policy enforcement when SSH decryption is required.
Learning point: NETSEC-T03-Q013: Use SSH Proxy decryption for matching SSH sessions.
Question 14
Fourth Coffee is reviewing its Palo Alto Networks deployment. What should the administrator do to exclude legally or operationally sensitive traffic from decryption?
- Create a narrowly scoped no-decrypt rule and place it appropriately in the decryption policy
- Use SSL Forward Proxy decryption for matching outbound client traffic and deploy the required forward-trust certificate
- Distribute the firewall forward-trust CA certificate to managed endpoints and protect the corresponding private key
- Use SSH Proxy decryption for matching SSH sessions
- Use SSL Inbound Inspection with access to the server certificate and private key where the deployment supports it
Correct answer: A
Explanation
- A specific no-decrypt rule provides an auditable exception without disabling decryption for unrelated traffic. This directly satisfies one of the stated requirement(s).
- SSL Forward Proxy places the firewall between internal clients and external TLS servers so encrypted application content can be inspected. This can be valid in another context, but it does not directly satisfy the stated requirement(s): exclude legally or operationally sensitive traffic from decryption.
- Clients must trust the certificate authority used by the firewall to generate substitute server certificates during forward-proxy inspection. This can be valid in another context, but it does not directly satisfy the stated requirement(s): exclude legally or operationally sensitive traffic from decryption.
- SSH Proxy is the decryption mode used to inspect supported SSH traffic instead of leaving the encrypted tunnel opaque. This can be valid in another context, but it does not directly satisfy the stated requirement(s): exclude legally or operationally sensitive traffic from decryption.
- Inbound inspection decrypts traffic destined for a protected server whose certificate material is controlled by the organization. This can be valid in another context, but it does not directly satisfy the stated requirement(s): exclude legally or operationally sensitive traffic from decryption.
Learning point: NETSEC-T03-Q014: Create a narrowly scoped no-decrypt rule and place it appropriately in the decryption policy.
Question 15
During a design review for City Power & Light, the requirement is to prevent certificate errors for sanctioned forward-proxy decryption. Which choice is most appropriate?
- Use separate forward-untrust handling so clients can recognize sessions to servers whose certificates are not trusted
- Distribute the firewall forward-trust CA certificate to managed endpoints and protect the corresponding private key
- Attach an appropriate decryption profile that enforces acceptable TLS protocol and certificate behavior
- Start with visibility and controlled policy scope, identify unsupported or pinned applications, then expand coverage deliberately
- Create a narrowly scoped no-decrypt rule and place it appropriately in the decryption policy
Correct answer: B
Explanation
- Forward-untrust behavior prevents the firewall from making an untrusted destination appear normally trusted to the client. This can be valid in another context, but it does not directly satisfy the stated requirement(s): prevent certificate errors for sanctioned forward-proxy decryption.
- Clients must trust the certificate authority used by the firewall to generate substitute server certificates during forward-proxy inspection. This directly satisfies one of the stated requirement(s).
- Decryption profiles let the firewall enforce cryptographic and certificate standards in addition to making content visible. This can be valid in another context, but it does not directly satisfy the stated requirement(s): prevent certificate errors for sanctioned forward-proxy decryption.
- A staged rollout lets the team discover compatibility issues and create justified exceptions instead of broadly disabling decryption. This can be valid in another context, but it does not directly satisfy the stated requirement(s): prevent certificate errors for sanctioned forward-proxy decryption.
- A specific no-decrypt rule provides an auditable exception without disabling decryption for unrelated traffic. This can be valid in another context, but it does not directly satisfy the stated requirement(s): prevent certificate errors for sanctioned forward-proxy decryption.
Learning point: NETSEC-T03-Q015: Distribute the firewall forward-trust CA certificate to managed endpoints and protect the corresponding private key.
Question 16
A change request at Lucerne Publishing states that the team must avoid silently trusting servers that present invalid certificates during forward-proxy decryption. What is the best response?
- Make exceptions specific by source, destination, URL category, or application context and document the business reason
- Use SSL Forward Proxy decryption for matching outbound client traffic and deploy the required forward-trust certificate
- Check certificate trust, decryption logs, protocol support, and certificate-pinning behavior before creating an exception
- Use separate forward-untrust handling so clients can recognize sessions to servers whose certificates are not trusted
- Attach an appropriate decryption profile that enforces acceptable TLS protocol and certificate behavior
Correct answer: D
Explanation
- Narrow exceptions reduce blind spots and make decryption policy easier to review and govern. This can be valid in another context, but it does not directly satisfy the stated requirement(s): avoid silently trusting servers that present invalid certificates during forward-proxy decryption.
- SSL Forward Proxy places the firewall between internal clients and external TLS servers so encrypted application content can be inspected. This can be valid in another context, but it does not directly satisfy the stated requirement(s): avoid silently trusting servers that present invalid certificates during forward-proxy decryption.
- Failures introduced by decryption commonly relate to trust, protocol negotiation, or applications that resist interception. This can be valid in another context, but it does not directly satisfy the stated requirement(s): avoid silently trusting servers that present invalid certificates during forward-proxy decryption.
- Forward-untrust behavior prevents the firewall from making an untrusted destination appear normally trusted to the client. This directly satisfies one of the stated requirement(s).
- Decryption profiles let the firewall enforce cryptographic and certificate standards in addition to making content visible. This can be valid in another context, but it does not directly satisfy the stated requirement(s): avoid silently trusting servers that present invalid certificates during forward-proxy decryption.
Learning point: NETSEC-T03-Q016: Use separate forward-untrust handling so clients can recognize sessions to servers whose certificates are not trusted.
Question 17
An engineer at A. Datum Research is troubleshooting a configuration decision. Which action directly addresses the need to phase in decryption without causing unnecessary business disruption?
- Create a narrowly scoped no-decrypt rule and place it appropriately in the decryption policy
- Start with visibility and controlled policy scope, identify unsupported or pinned applications, then expand coverage deliberately
- Use SSH Proxy decryption for matching SSH sessions
- Use SSL Inbound Inspection with access to the server certificate and private key where the deployment supports it
- Use SSL Forward Proxy decryption for matching outbound client traffic and deploy the required forward-trust certificate
Correct answer: B
Explanation
- A specific no-decrypt rule provides an auditable exception without disabling decryption for unrelated traffic. This can be valid in another context, but it does not directly satisfy the stated requirement(s): phase in decryption without causing unnecessary business disruption.
- A staged rollout lets the team discover compatibility issues and create justified exceptions instead of broadly disabling decryption. This directly satisfies one of the stated requirement(s).
- SSH Proxy is the decryption mode used to inspect supported SSH traffic instead of leaving the encrypted tunnel opaque. This can be valid in another context, but it does not directly satisfy the stated requirement(s): phase in decryption without causing unnecessary business disruption.
- Inbound inspection decrypts traffic destined for a protected server whose certificate material is controlled by the organization. This can be valid in another context, but it does not directly satisfy the stated requirement(s): phase in decryption without causing unnecessary business disruption.
- SSL Forward Proxy places the firewall between internal clients and external TLS servers so encrypted application content can be inspected. This can be valid in another context, but it does not directly satisfy the stated requirement(s): phase in decryption without causing unnecessary business disruption.
Learning point: NETSEC-T03-Q017: Start with visibility and controlled policy scope, identify unsupported or pinned applications, then expand coverage deliberately.
Question 18
Wingtip Logistics has two related requirements: it must protect decrypted traffic from weak protocol choices, and it must also inspect SSH traffic for policy enforcement when SSH decryption is required. Which TWO actions best satisfy these requirements? Select two.
- Distribute the firewall forward-trust CA certificate to managed endpoints and protect the corresponding private key
- Use SSL Inbound Inspection with access to the server certificate and private key where the deployment supports it
- Use SSH Proxy decryption for matching SSH sessions
- Create a narrowly scoped no-decrypt rule and place it appropriately in the decryption policy
- Attach an appropriate decryption profile that enforces acceptable TLS protocol and certificate behavior
Correct answers: C, E
Explanation
- Clients must trust the certificate authority used by the firewall to generate substitute server certificates during forward-proxy inspection. This can be valid in another context, but it does not directly satisfy the stated requirement(s): protect decrypted traffic from weak protocol choices; inspect SSH traffic for policy enforcement when SSH decryption is required.
- Inbound inspection decrypts traffic destined for a protected server whose certificate material is controlled by the organization. This can be valid in another context, but it does not directly satisfy the stated requirement(s): protect decrypted traffic from weak protocol choices; inspect SSH traffic for policy enforcement when SSH decryption is required.
- SSH Proxy is the decryption mode used to inspect supported SSH traffic instead of leaving the encrypted tunnel opaque. This directly satisfies one of the stated requirement(s).
- A specific no-decrypt rule provides an auditable exception without disabling decryption for unrelated traffic. This can be valid in another context, but it does not directly satisfy the stated requirement(s): protect decrypted traffic from weak protocol choices; inspect SSH traffic for policy enforcement when SSH decryption is required.
- Decryption profiles let the firewall enforce cryptographic and certificate standards in addition to making content visible. This directly satisfies one of the stated requirement(s).
Learning point: NETSEC-T03-Q018: Attach an appropriate decryption profile that enforces acceptable TLS protocol and certificate behavior; Use SSH Proxy decryption for matching SSH sessions.
Question 19
A security review at Trey Research identifies a gap. The team wants to troubleshoot a TLS application that fails only when decryption is enabled. Which action should it take?
- Start with visibility and controlled policy scope, identify unsupported or pinned applications, then expand coverage deliberately
- Check certificate trust, decryption logs, protocol support, and certificate-pinning behavior before creating an exception
- Use SSL Forward Proxy decryption for matching outbound client traffic and deploy the required forward-trust certificate
- Make exceptions specific by source, destination, URL category, or application context and document the business reason
- Attach an appropriate decryption profile that enforces acceptable TLS protocol and certificate behavior
Correct answer: B
Explanation
- A staged rollout lets the team discover compatibility issues and create justified exceptions instead of broadly disabling decryption. This can be valid in another context, but it does not directly satisfy the stated requirement(s): troubleshoot a TLS application that fails only when decryption is enabled.
- Failures introduced by decryption commonly relate to trust, protocol negotiation, or applications that resist interception. This directly satisfies one of the stated requirement(s).
- SSL Forward Proxy places the firewall between internal clients and external TLS servers so encrypted application content can be inspected. This can be valid in another context, but it does not directly satisfy the stated requirement(s): troubleshoot a TLS application that fails only when decryption is enabled.
- Narrow exceptions reduce blind spots and make decryption policy easier to review and govern. This can be valid in another context, but it does not directly satisfy the stated requirement(s): troubleshoot a TLS application that fails only when decryption is enabled.
- Decryption profiles let the firewall enforce cryptographic and certificate standards in addition to making content visible. This can be valid in another context, but it does not directly satisfy the stated requirement(s): troubleshoot a TLS application that fails only when decryption is enabled.
Learning point: NETSEC-T03-Q019: Check certificate trust, decryption logs, protocol support, and certificate-pinning behavior before creating an exception.
Question 20
While validating a deployment for Wide World Importers, an architect must ensure the design can preserve inspection while limiting broad decryption exemptions. What should be done?
- Use SSH Proxy decryption for matching SSH sessions
- Use SSL Forward Proxy decryption for matching outbound client traffic and deploy the required forward-trust certificate
- Use SSL Inbound Inspection with access to the server certificate and private key where the deployment supports it
- Make exceptions specific by source, destination, URL category, or application context and document the business reason
- Create a narrowly scoped no-decrypt rule and place it appropriately in the decryption policy
Correct answer: D
Explanation
- SSH Proxy is the decryption mode used to inspect supported SSH traffic instead of leaving the encrypted tunnel opaque. This can be valid in another context, but it does not directly satisfy the stated requirement(s): preserve inspection while limiting broad decryption exemptions.
- SSL Forward Proxy places the firewall between internal clients and external TLS servers so encrypted application content can be inspected. This can be valid in another context, but it does not directly satisfy the stated requirement(s): preserve inspection while limiting broad decryption exemptions.
- Inbound inspection decrypts traffic destined for a protected server whose certificate material is controlled by the organization. This can be valid in another context, but it does not directly satisfy the stated requirement(s): preserve inspection while limiting broad decryption exemptions.
- Narrow exceptions reduce blind spots and make decryption policy easier to review and govern. This directly satisfies one of the stated requirement(s).
- A specific no-decrypt rule provides an auditable exception without disabling decryption for unrelated traffic. This can be valid in another context, but it does not directly satisfy the stated requirement(s): preserve inspection while limiting broad decryption exemptions.
Learning point: NETSEC-T03-Q020: Make exceptions specific by source, destination, URL category, or application context and document the business reason.
Question 21
At Contoso Retail, the network security team needs to inspect outbound TLS sessions initiated by internal users. Which approach best meets the requirement?
- Use separate forward-untrust handling so clients can recognize sessions to servers whose certificates are not trusted
- Start with visibility and controlled policy scope, identify unsupported or pinned applications, then expand coverage deliberately
- Distribute the firewall forward-trust CA certificate to managed endpoints and protect the corresponding private key
- Attach an appropriate decryption profile that enforces acceptable TLS protocol and certificate behavior
- Use SSL Forward Proxy decryption for matching outbound client traffic and deploy the required forward-trust certificate
Correct answer: E
Explanation
- Forward-untrust behavior prevents the firewall from making an untrusted destination appear normally trusted to the client. This can be valid in another context, but it does not directly satisfy the stated requirement(s): inspect outbound TLS sessions initiated by internal users.
- A staged rollout lets the team discover compatibility issues and create justified exceptions instead of broadly disabling decryption. This can be valid in another context, but it does not directly satisfy the stated requirement(s): inspect outbound TLS sessions initiated by internal users.
- Clients must trust the certificate authority used by the firewall to generate substitute server certificates during forward-proxy inspection. This can be valid in another context, but it does not directly satisfy the stated requirement(s): inspect outbound TLS sessions initiated by internal users.
- Decryption profiles let the firewall enforce cryptographic and certificate standards in addition to making content visible. This can be valid in another context, but it does not directly satisfy the stated requirement(s): inspect outbound TLS sessions initiated by internal users.
- SSL Forward Proxy places the firewall between internal clients and external TLS servers so encrypted application content can be inspected. This directly satisfies one of the stated requirement(s).
Learning point: NETSEC-T03-Q021: Use SSL Forward Proxy decryption for matching outbound client traffic and deploy the required forward-trust certificate.
Question 22
Fabrikam Health is reviewing its Palo Alto Networks deployment. What should the administrator do to inspect inbound TLS traffic to an organization-owned HTTPS server?
- Use SSL Inbound Inspection with access to the server certificate and private key where the deployment supports it
- Use SSL Forward Proxy decryption for matching outbound client traffic and deploy the required forward-trust certificate
- Check certificate trust, decryption logs, protocol support, and certificate-pinning behavior before creating an exception
- Make exceptions specific by source, destination, URL category, or application context and document the business reason
- Attach an appropriate decryption profile that enforces acceptable TLS protocol and certificate behavior
Correct answer: A
Explanation
- Inbound inspection decrypts traffic destined for a protected server whose certificate material is controlled by the organization. This directly satisfies one of the stated requirement(s).
- SSL Forward Proxy places the firewall between internal clients and external TLS servers so encrypted application content can be inspected. This can be valid in another context, but it does not directly satisfy the stated requirement(s): inspect inbound TLS traffic to an organization-owned HTTPS server.
- Failures introduced by decryption commonly relate to trust, protocol negotiation, or applications that resist interception. This can be valid in another context, but it does not directly satisfy the stated requirement(s): inspect inbound TLS traffic to an organization-owned HTTPS server.
- Narrow exceptions reduce blind spots and make decryption policy easier to review and govern. This can be valid in another context, but it does not directly satisfy the stated requirement(s): inspect inbound TLS traffic to an organization-owned HTTPS server.
- Decryption profiles let the firewall enforce cryptographic and certificate standards in addition to making content visible. This can be valid in another context, but it does not directly satisfy the stated requirement(s): inspect inbound TLS traffic to an organization-owned HTTPS server.
Learning point: NETSEC-T03-Q022: Use SSL Inbound Inspection with access to the server certificate and private key where the deployment supports it.
Question 23
During a design review for Northwind Traders, the requirement is to inspect SSH traffic for policy enforcement when SSH decryption is required. Which choice is most appropriate?
- Use SSL Inbound Inspection with access to the server certificate and private key where the deployment supports it
- Use SSL Forward Proxy decryption for matching outbound client traffic and deploy the required forward-trust certificate
- Distribute the firewall forward-trust CA certificate to managed endpoints and protect the corresponding private key
- Use SSH Proxy decryption for matching SSH sessions
- Create a narrowly scoped no-decrypt rule and place it appropriately in the decryption policy
Correct answer: D
Explanation
- Inbound inspection decrypts traffic destined for a protected server whose certificate material is controlled by the organization. This can be valid in another context, but it does not directly satisfy the stated requirement(s): inspect SSH traffic for policy enforcement when SSH decryption is required.
- SSL Forward Proxy places the firewall between internal clients and external TLS servers so encrypted application content can be inspected. This can be valid in another context, but it does not directly satisfy the stated requirement(s): inspect SSH traffic for policy enforcement when SSH decryption is required.
- Clients must trust the certificate authority used by the firewall to generate substitute server certificates during forward-proxy inspection. This can be valid in another context, but it does not directly satisfy the stated requirement(s): inspect SSH traffic for policy enforcement when SSH decryption is required.
- SSH Proxy is the decryption mode used to inspect supported SSH traffic instead of leaving the encrypted tunnel opaque. This directly satisfies one of the stated requirement(s).
- A specific no-decrypt rule provides an auditable exception without disabling decryption for unrelated traffic. This can be valid in another context, but it does not directly satisfy the stated requirement(s): inspect SSH traffic for policy enforcement when SSH decryption is required.
Learning point: NETSEC-T03-Q023: Use SSH Proxy decryption for matching SSH sessions.
Question 24
A change request at Tailspin Energy states that the team must exclude legally or operationally sensitive traffic from decryption. What is the best response?
- Create a narrowly scoped no-decrypt rule and place it appropriately in the decryption policy
- Distribute the firewall forward-trust CA certificate to managed endpoints and protect the corresponding private key
- Start with visibility and controlled policy scope, identify unsupported or pinned applications, then expand coverage deliberately
- Use separate forward-untrust handling so clients can recognize sessions to servers whose certificates are not trusted
- Attach an appropriate decryption profile that enforces acceptable TLS protocol and certificate behavior
Correct answer: A
Explanation
- A specific no-decrypt rule provides an auditable exception without disabling decryption for unrelated traffic. This directly satisfies one of the stated requirement(s).
- Clients must trust the certificate authority used by the firewall to generate substitute server certificates during forward-proxy inspection. This can be valid in another context, but it does not directly satisfy the stated requirement(s): exclude legally or operationally sensitive traffic from decryption.
- A staged rollout lets the team discover compatibility issues and create justified exceptions instead of broadly disabling decryption. This can be valid in another context, but it does not directly satisfy the stated requirement(s): exclude legally or operationally sensitive traffic from decryption.
- Forward-untrust behavior prevents the firewall from making an untrusted destination appear normally trusted to the client. This can be valid in another context, but it does not directly satisfy the stated requirement(s): exclude legally or operationally sensitive traffic from decryption.
- Decryption profiles let the firewall enforce cryptographic and certificate standards in addition to making content visible. This can be valid in another context, but it does not directly satisfy the stated requirement(s): exclude legally or operationally sensitive traffic from decryption.
Learning point: NETSEC-T03-Q024: Create a narrowly scoped no-decrypt rule and place it appropriately in the decryption policy.
Question 25
An engineer at Woodgrove Bank is troubleshooting a configuration decision. Which action directly addresses the need to prevent certificate errors for sanctioned forward-proxy decryption?
- Check certificate trust, decryption logs, protocol support, and certificate-pinning behavior before creating an exception
- Attach an appropriate decryption profile that enforces acceptable TLS protocol and certificate behavior
- Distribute the firewall forward-trust CA certificate to managed endpoints and protect the corresponding private key
- Use SSL Forward Proxy decryption for matching outbound client traffic and deploy the required forward-trust certificate
- Make exceptions specific by source, destination, URL category, or application context and document the business reason
Correct answer: C
Explanation
- Failures introduced by decryption commonly relate to trust, protocol negotiation, or applications that resist interception. This can be valid in another context, but it does not directly satisfy the stated requirement(s): prevent certificate errors for sanctioned forward-proxy decryption.
- Decryption profiles let the firewall enforce cryptographic and certificate standards in addition to making content visible. This can be valid in another context, but it does not directly satisfy the stated requirement(s): prevent certificate errors for sanctioned forward-proxy decryption.
- Clients must trust the certificate authority used by the firewall to generate substitute server certificates during forward-proxy inspection. This directly satisfies one of the stated requirement(s).
- SSL Forward Proxy places the firewall between internal clients and external TLS servers so encrypted application content can be inspected. This can be valid in another context, but it does not directly satisfy the stated requirement(s): prevent certificate errors for sanctioned forward-proxy decryption.
- Narrow exceptions reduce blind spots and make decryption policy easier to review and govern. This can be valid in another context, but it does not directly satisfy the stated requirement(s): prevent certificate errors for sanctioned forward-proxy decryption.
Learning point: NETSEC-T03-Q025: Distribute the firewall forward-trust CA certificate to managed endpoints and protect the corresponding private key.
Question 26
Which option best supports the goal to avoid silently trusting servers that present invalid certificates during forward-proxy decryption in Alpine Ski House’s Palo Alto Networks environment?
- Create a narrowly scoped no-decrypt rule and place it appropriately in the decryption policy
- Use SSL Forward Proxy decryption for matching outbound client traffic and deploy the required forward-trust certificate
- Use SSH Proxy decryption for matching SSH sessions
- Use SSL Inbound Inspection with access to the server certificate and private key where the deployment supports it
- Use separate forward-untrust handling so clients can recognize sessions to servers whose certificates are not trusted
Correct answer: E
Explanation
- A specific no-decrypt rule provides an auditable exception without disabling decryption for unrelated traffic. This can be valid in another context, but it does not directly satisfy the stated requirement(s): avoid silently trusting servers that present invalid certificates during forward-proxy decryption.
- SSL Forward Proxy places the firewall between internal clients and external TLS servers so encrypted application content can be inspected. This can be valid in another context, but it does not directly satisfy the stated requirement(s): avoid silently trusting servers that present invalid certificates during forward-proxy decryption.
- SSH Proxy is the decryption mode used to inspect supported SSH traffic instead of leaving the encrypted tunnel opaque. This can be valid in another context, but it does not directly satisfy the stated requirement(s): avoid silently trusting servers that present invalid certificates during forward-proxy decryption.
- Inbound inspection decrypts traffic destined for a protected server whose certificate material is controlled by the organization. This can be valid in another context, but it does not directly satisfy the stated requirement(s): avoid silently trusting servers that present invalid certificates during forward-proxy decryption.
- Forward-untrust behavior prevents the firewall from making an untrusted destination appear normally trusted to the client. This directly satisfies one of the stated requirement(s).
Learning point: NETSEC-T03-Q026: Use separate forward-untrust handling so clients can recognize sessions to servers whose certificates are not trusted.
Question 27
Contoso Retail has two related requirements: it must phase in decryption without causing unnecessary business disruption, and it must also exclude legally or operationally sensitive traffic from decryption. Which TWO actions best satisfy these requirements? Select two.
- Use separate forward-untrust handling so clients can recognize sessions to servers whose certificates are not trusted
- Attach an appropriate decryption profile that enforces acceptable TLS protocol and certificate behavior
- Create a narrowly scoped no-decrypt rule and place it appropriately in the decryption policy
- Check certificate trust, decryption logs, protocol support, and certificate-pinning behavior before creating an exception
- Start with visibility and controlled policy scope, identify unsupported or pinned applications, then expand coverage deliberately
Correct answers: C, E
Explanation
- Forward-untrust behavior prevents the firewall from making an untrusted destination appear normally trusted to the client. This can be valid in another context, but it does not directly satisfy the stated requirement(s): phase in decryption without causing unnecessary business disruption; exclude legally or operationally sensitive traffic from decryption.
- Decryption profiles let the firewall enforce cryptographic and certificate standards in addition to making content visible. This can be valid in another context, but it does not directly satisfy the stated requirement(s): phase in decryption without causing unnecessary business disruption; exclude legally or operationally sensitive traffic from decryption.
- A specific no-decrypt rule provides an auditable exception without disabling decryption for unrelated traffic. This directly satisfies one of the stated requirement(s).
- Failures introduced by decryption commonly relate to trust, protocol negotiation, or applications that resist interception. This can be valid in another context, but it does not directly satisfy the stated requirement(s): phase in decryption without causing unnecessary business disruption; exclude legally or operationally sensitive traffic from decryption.
- A staged rollout lets the team discover compatibility issues and create justified exceptions instead of broadly disabling decryption. This directly satisfies one of the stated requirement(s).
Learning point: NETSEC-T03-Q027: Start with visibility and controlled policy scope, identify unsupported or pinned applications, then expand coverage deliberately; Create a narrowly scoped no-decrypt rule and place it appropriately in the decryption policy.
Question 28
While validating a deployment for Adventure Works, an architect must ensure the design can protect decrypted traffic from weak protocol choices. What should be done?
- Start with visibility and controlled policy scope, identify unsupported or pinned applications, then expand coverage deliberately
- Check certificate trust, decryption logs, protocol support, and certificate-pinning behavior before creating an exception
- Use SSL Forward Proxy decryption for matching outbound client traffic and deploy the required forward-trust certificate
- Attach an appropriate decryption profile that enforces acceptable TLS protocol and certificate behavior
- Make exceptions specific by source, destination, URL category, or application context and document the business reason
Correct answer: D
Explanation
- A staged rollout lets the team discover compatibility issues and create justified exceptions instead of broadly disabling decryption. This can be valid in another context, but it does not directly satisfy the stated requirement(s): protect decrypted traffic from weak protocol choices.
- Failures introduced by decryption commonly relate to trust, protocol negotiation, or applications that resist interception. This can be valid in another context, but it does not directly satisfy the stated requirement(s): protect decrypted traffic from weak protocol choices.
- SSL Forward Proxy places the firewall between internal clients and external TLS servers so encrypted application content can be inspected. This can be valid in another context, but it does not directly satisfy the stated requirement(s): protect decrypted traffic from weak protocol choices.
- Decryption profiles let the firewall enforce cryptographic and certificate standards in addition to making content visible. This directly satisfies one of the stated requirement(s).
- Narrow exceptions reduce blind spots and make decryption policy easier to review and govern. This can be valid in another context, but it does not directly satisfy the stated requirement(s): protect decrypted traffic from weak protocol choices.
Learning point: NETSEC-T03-Q028: Attach an appropriate decryption profile that enforces acceptable TLS protocol and certificate behavior.
Question 29
At Proseware Services, the network security team needs to troubleshoot a TLS application that fails only when decryption is enabled. Which approach best meets the requirement?
- Create a narrowly scoped no-decrypt rule and place it appropriately in the decryption policy
- Check certificate trust, decryption logs, protocol support, and certificate-pinning behavior before creating an exception
- Use SSL Inbound Inspection with access to the server certificate and private key where the deployment supports it
- Use SSH Proxy decryption for matching SSH sessions
- Use SSL Forward Proxy decryption for matching outbound client traffic and deploy the required forward-trust certificate
Correct answer: B
Explanation
- A specific no-decrypt rule provides an auditable exception without disabling decryption for unrelated traffic. This can be valid in another context, but it does not directly satisfy the stated requirement(s): troubleshoot a TLS application that fails only when decryption is enabled.
- Failures introduced by decryption commonly relate to trust, protocol negotiation, or applications that resist interception. This directly satisfies one of the stated requirement(s).
- Inbound inspection decrypts traffic destined for a protected server whose certificate material is controlled by the organization. This can be valid in another context, but it does not directly satisfy the stated requirement(s): troubleshoot a TLS application that fails only when decryption is enabled.
- SSH Proxy is the decryption mode used to inspect supported SSH traffic instead of leaving the encrypted tunnel opaque. This can be valid in another context, but it does not directly satisfy the stated requirement(s): troubleshoot a TLS application that fails only when decryption is enabled.
- SSL Forward Proxy places the firewall between internal clients and external TLS servers so encrypted application content can be inspected. This can be valid in another context, but it does not directly satisfy the stated requirement(s): troubleshoot a TLS application that fails only when decryption is enabled.
Learning point: NETSEC-T03-Q029: Check certificate trust, decryption logs, protocol support, and certificate-pinning behavior before creating an exception.
Question 30
Wingtip Logistics is reviewing its Palo Alto Networks deployment. What should the administrator do to preserve inspection while limiting broad decryption exemptions?
- Use separate forward-untrust handling so clients can recognize sessions to servers whose certificates are not trusted
- Start with visibility and controlled policy scope, identify unsupported or pinned applications, then expand coverage deliberately
- Create a narrowly scoped no-decrypt rule and place it appropriately in the decryption policy
- Make exceptions specific by source, destination, URL category, or application context and document the business reason
- Distribute the firewall forward-trust CA certificate to managed endpoints and protect the corresponding private key
Correct answer: D
Explanation
- Forward-untrust behavior prevents the firewall from making an untrusted destination appear normally trusted to the client. This can be valid in another context, but it does not directly satisfy the stated requirement(s): preserve inspection while limiting broad decryption exemptions.
- A staged rollout lets the team discover compatibility issues and create justified exceptions instead of broadly disabling decryption. This can be valid in another context, but it does not directly satisfy the stated requirement(s): preserve inspection while limiting broad decryption exemptions.
- A specific no-decrypt rule provides an auditable exception without disabling decryption for unrelated traffic. This can be valid in another context, but it does not directly satisfy the stated requirement(s): preserve inspection while limiting broad decryption exemptions.
- Narrow exceptions reduce blind spots and make decryption policy easier to review and govern. This directly satisfies one of the stated requirement(s).
- Clients must trust the certificate authority used by the firewall to generate substitute server certificates during forward-proxy inspection. This can be valid in another context, but it does not directly satisfy the stated requirement(s): preserve inspection while limiting broad decryption exemptions.
Learning point: NETSEC-T03-Q030: Make exceptions specific by source, destination, URL category, or application context and document the business reason.