Infrastructure Management And CDSS practice questions

debug wildfire connectivity

Why it fails: This is a debug command, not the primary command for checking registration status.

show jobs id wildfire-sync

Why it fails: This command shows job history, not service availability.

test wildfire cloud-reachability

Why it fails: This command does not exist in the standard PAN-OS CLI.

Enable 'Packet Capture' for all security policies.

Why it fails: This increases log volume but does not speed up WildFire analysis.

Increase the WildFire cloud region to the nearest geographic site.

Why it fails: While helpful for latency, it does not change the analysis mode.

Set the WildFire forwarding to 'Legacy' mode.

Why it fails: Legacy mode does not support real-time analysis.

Configure a URL Filtering profile to block the top-level domain.

Why it fails: URL Filtering operates at the HTTP/HTTPS layer and does not control DNS query resolution.

Enable DNS Security and rely on the default 'Command and Control' category block.

Why it fails: Default categories are not designed for specific subdomain granularity.

Add the full domain to the DNS sinkhole whitelist.

Why it fails: Whitelisting does not provide the granularity needed to block specific subdomains while allowing others.

Disable SSL decryption for the proxy traffic.

Why it fails: This would prevent the firewall from seeing the actual threats.

Create a specific 'Proxy' zone and apply an App-ID policy.

Why it fails: This does not help with identifying the end host or content.

Configure the proxy as a 'Trusted' source in the Device > Setup menu.

Why it fails: This does not enable deep packet inspection of the proxied traffic.

Global Find

Why it fails: Global Find is for locating objects, not auditing policy attributes.

ACC (Application Command Center)

Why it fails: ACC is for traffic analysis, not policy configuration auditing.

Threat Log viewer

Why it fails: The log viewer shows results of existing policies, not their configuration status.

Objects > Security Profiles > DNS Security

Why it fails: This is where the profile is defined, not where it is enabled on traffic.

Network > Zones > [Zone Name]

Why it fails: Zones define traffic boundaries but do not contain security service profiles.

Device > Setup > Services > DNS

Why it fails: This is for configuring the firewall's own DNS settings.

Enable 'WildFire' in the Antivirus profile.

Why it fails: WildFire forwarding is a separate setting in the File Blocking profile.

Add the server's IP to the 'WildFire Analysis' whitelist.

Why it fails: Whitelisting prevents analysis.

Configure a 'Log Forwarding' profile for WildFire.

Why it fails: Log forwarding handles existing logs, not file submission.

Only apply groups to traffic destined for the Internet.

Why it fails: Internal traffic also requires security profiling.

Avoid using groups and always apply individual profiles to rules.

Why it fails: Individual profiles are harder to manage at scale.

Create a unique group for every single security policy rule.

Why it fails: This creates administrative overhead and is not a best practice.

The number of packets in the flow.

Why it fails: Packet count does not determine policy matching.

The total duration of the session.

Why it fails: Duration is not a matching criterion for policies.

The physical MAC address of the source.

Why it fails: MAC addresses are not used for security policy matching.

Enable 'Alert' as the only action.

Why it fails: Alert does not block or upload the file.

Disable 'Session Log' in the Security Profile.

Why it fails: Session logs should be enabled for auditability.

Enable 'Push Notifications' in the Device > Setup menu.

Why it fails: There is no such feature for signature delivery.

Use a local WildFire appliance in 'Synchronous' mode.

Why it fails: Local appliances are for privacy, not for faster global signature propagation.

Force a manual 'Check Now' every hour.

Why it fails: Manual checks are less efficient than the automatic 1-minute schedule.

Block

Why it fails: Standard action to stop the threat.

Allow

Why it fails: 'Allow' is not an action in a threat profile, as threats are by definition blocked.

Monitor

Why it fails: 'Monitor' is not a valid action in the standard Vulnerability Protection profile.

Network > Interfaces.

Why it fails: Network > Interfaces configures interface settings, zones and virtual routers, with no subscription information. It is tempting because interface configuration is where you would verify traffic paths for licensed features, and that is correct when troubleshooting connectivity — but CDSS subscription status lives under Device > Licenses and the dashboard.

Monitor > Logs.

Why it fails: Monitor > Logs displays traffic, threat and system logs rather than subscription entitlements. It is tempting because logs reveal whether CDSS-dependent detections are firing, and that is the right place to troubleshoot detection behaviour — but licence and subscription status appear under Device > Licenses and the dashboard.

Policies > Security.

Why it fails: Policies > Security holds security policy rules and profiles, not subscription licensing state. It is tempting because security profiles are where content inspection is configured, and that is the correct place to verify which profiles are applied — but CDSS subscription validity is reported under Device > Licenses and the dashboard's subscription widgets.

Application names (App-ID).

Why it fails: App-ID is not used in URL category definitions.

Threat signature IDs.

Why it fails: Threat signatures are used in Threat profiles, not URL categories.

Disable SSL decryption globally and rely on threat prevention without decryption.

Why it fails: Disabling SSL decryption globally would stop inspection of all encrypted traffic, reducing security posture. It would allow access to the bank site, but it fails to meet the requirement of still inspecting other traffic. The scenario requires a targeted exception, not a global disable.

Modify the decryption profile to allow weak protocols and ciphers for the bank's site.

Why it fails: Modifying the decryption profile to allow weak protocols and ciphers would not resolve the issue because the problem is likely due to certificate pinning or client trust, not cipher strength. Allowing weak ciphers could also introduce security vulnerabilities, and it does not address the need for a no-decryption exception.

Import the bank's certificate into the firewall's trusted CA list and enable decryption.

Why it fails: Importing the bank's certificate into the firewall's trusted CA list does not prevent decryption issues. The firewall would still decrypt the traffic and present its own certificate to the client, which may be rejected if the client expects the bank's original certificate. This approach does not solve the access problem.

Vulnerability Protection security profile

Why it fails: Vulnerability Protection profiles protect against exploits targeting known vulnerabilities. While important, it is a separate profile and is not one of the two required to enable antivirus and anti-spyware scanning. The question specifically asks for components to perform antivirus, anti-spyware, and vulnerability protection, but the two correct answers are antivirus and anti-spyware; vulnerability protection is a third profile that would also be needed, but only two are to be chosen.

URL Filtering profile

Why it fails: URL Filtering profiles control access to websites based on categories. While they contribute to overall security, they do not perform antivirus, anti-spyware, or vulnerability protection. They are not required to enable those specific threat inspections on allowed traffic.

File Blocking profile

Why it fails: File Blocking profiles control the transfer of files based on file type and direction. They do not perform antivirus scanning, anti-spyware scanning, or vulnerability protection. They are used to block or allow specific file types, not to inspect content for threats.

Configure a Decryption profile with 'Block Unsupported SSL' enabled.

Why it fails: A Decryption profile with 'Block Unsupported SSL' controls how the firewall handles SSL traffic that cannot be decrypted, such as unsupported ciphers or protocols. It does not address the failure of content inspection engines. This setting is unrelated to ensuring traffic is blocked when inspection engines fail.

Enable 'Fail Open' in the Security Profile Group.

Why it fails: Enabling 'Fail Open' would allow traffic to pass uninspected if the content inspection engines fail. This defeats the purpose of security inspection and could allow malicious traffic through. The requirement is to block traffic in case of failure, so 'Fail Open' is the opposite of what is needed.

Set the action to 'Reset Client' in the security policy rule.

Why it fails: Setting the action to 'Reset Client' in a security policy rule determines what happens to traffic that matches the rule but is denied. It does not control behavior when content inspection engines fail. This action is used for resetting connections, not for fail-close behavior of security profiles.

Add the partner's internal CA certificate to the firewall's trusted certificate authority list and enable it for the decryption profile.

Why it fails: Importing the partner's internal CA into the firewall's trust store lets the firewall validate the server certificate, but the user browsers still receive a certificate re-signed by the firewall's forward trust CA. If the issue is the firewall rejecting the untrusted upstream chain, this helps the firewall side, yet the scenario says users see errors, so the browser trust relationship must also be addressed; importing the CA alone is not the cleanest fix.

Add the partner's domain to the SSL Decryption Exclusion list and remove the decryption rule that matches outbound HTTPS.

Why it fails: SSL Decryption Exclusion exempts specific server certificates from decryption based on certificate attributes, but removing the general outbound HTTPS decryption rule disables inspection for all sites, which contradicts the goal of maintaining decryption elsewhere. The exclusion list alone would be viable, yet combining it with removing the broad rule over-broadens the fix and reduces security coverage.

Disable the Forward Proxy profile on the decryption rule and rely on Forward Trust for all outbound TLS sessions.

Why it fails: Removing the Forward Proxy profile changes how the firewall proxies and re-signs sessions but does not exempt the partner's site from decryption. The browser would still receive a firewall-generated certificate chain, so the untrusted internal CA problem persists. This broadens the change to all outbound traffic rather than isolating the single problematic destination.

Enable the DNS Security service in the security zone where the internal DNS servers reside and apply a DNS Rewrite profile.

Why it fails: DNS Security is applied through security policy profiles, not by enabling a service on a zone. DNS Rewrite is a separate feature that rewrites DNS responses for specific domains and does not itself detect or block malicious C2 domains. Relying on zone-level configuration and DNS Rewrite would leave malicious resolutions unblocked.

Create a custom DNS Security category and add all internal domain names to it to prevent false positives.

Why it fails: Custom categories in DNS Security are used to allow or block specific domains with tailored actions, but adding internal domains does not detect or block external C2 domains. This action addresses false-positive tuning rather than the stated goal of detecting and blocking malicious DNS-based command-and-control traffic.

Configure the DNS Security profile to use only the 'Alert' action so that all malicious domains are logged for later review.

Why it fails: The Alert action generates logs but does not block the DNS resolution, so the endpoint still learns the malicious IP and can reach the C2 server. For a requirement to detect and block DNS-based C2, alert-only leaves the channel open. Logging is valuable for visibility but must be paired with a blocking action such as sinkhole or block.

Block sessions with weak ciphers

Why it fails: The Decryption profile does not have a specific setting named 'Block sessions with weak ciphers'. Instead, it has options like 'Block sessions with unsupported versions' and 'Block sessions with unsupported cipher suites'. While blocking weak ciphers is desirable, the exact setting is not present. The requirement mentions weak protocols and ciphers, but the profile does not have a direct 'weak ciphers' toggle; it uses 'unsupported cipher suites' which is different. Therefore, this is not the correct choice.

Block sessions with client authentication

Why it fails: Blocking sessions with client authentication would prevent mutual TLS (mTLS) connections, which are used for enhanced security in some applications. This is not a best practice for general SSL Forward Proxy; it would break legitimate applications that require client certificates. The requirement is to block weak protocols and untrusted certificates, not to block client authentication.

Block TLS 1.0 and TLS 1.1

Why it fails: While blocking weak protocols like TLS 1.0 and 1.1 is a good security practice, the Decryption profile does not have a specific setting to block them directly. Instead, you would use a custom URL category or security policy to block based on TLS version, or use a Decryption profile with 'Block sessions with unsupported versions' which may include older versions. However, the explicit requirement here is about weak protocols and ciphers, but the profile does not have a dedicated TLS 1.0/1.1 block option; it has a 'Block sessions with unsupported versions' which can be configured, but the specific option is not present. Therefore, it is not the best answer.