App-ID and Content-ID practice questions

The firewall has not received the latest App-ID update.

Why it fails: App identification is done locally; updates add new apps but do not affect existing ones.

SSL decryption is not configured.

Why it fails: YouTube is identified without decryption.

A security rule is blocking the sub-application.

Why it fails: If blocked, traffic would be denied, not reclassified.

The 'web-browsing' application does not include HTTP.

Why it fails: It does.

A custom application must be created for port 8080.

Why it fails: No, web-browsing works on any port.

App-ID cannot identify HTTP over non-standard ports.

Why it fails: App-ID can identify HTTP on any port.

Application Override

Why it fails: Application override is part of App-ID.

URL Filtering

Why it fails: URL filtering is a separate feature.

Packet size exceeds the maximum transmission unit.

Why it fails: Packet size is unrelated.

Identifying the application regardless of port.

Why it fails: That is App-ID.

Applying QoS policies to applications.

Why it fails: QoS is separate.

The application is not actually matching the rule.

Why it fails: Logs show the rule is matched.

A DoS protection policy is blocking the traffic.

Why it fails: DoS protection would not typically reset.

App-ID is incorrectly identifying the traffic.

Why it fails: The exhibit shows myapp is identified.

Enable SSL decryption to allow App-ID to identify the Outlook traffic.

Why it fails: Outlook client traffic to Office 365 uses MAPI over HTTPS, which App-ID can identify without decryption; enabling SSL decryption would not resolve the missing sub-application identification and adds overhead. It is tempting because decryption exposes encrypted payloads, but App-ID already recognises Office 365 apps via TLS SNI and certificates.

Create a new rule that allows 'outlook' application specifically.

Why it fails: A rule allowing the 'outlook' application does not help, because the firewall is not identifying Outlook traffic as a sub-application at all; the parent office365-base rule already permits it. It is tempting because application-specific rules are normal practise, but the identification gap must be fixed first.

Change the rule to allow 'office365-base' and set Action to 'allow' with a QoS policy.

Why it fails: QoS policy affects bandwidth treatment, not application identification, so it cannot make App-ID recognise Outlook sub-applications. It is tempting because QoS is configured alongside security rules, but the actual requirement is enabling the Office 365 sub-application identification, not altering rule action or traffic shaping.

SSL decryption is not enabled for the custom application.

Why it fails: Decryption is not required for App-ID.

The custom application needs to be added to the 'ssl' application group.

Why it fails: Groups are not required.

The application override was not committed.

Why it fails: Assuming it was committed.

Create URL filtering profile, then apply the profile to a security policy, then configure SSL decryption, then test and verify.

Why it fails: This is incorrect because SSL decryption must be configured before applying the URL filtering profile to a security policy. If HTTPS traffic is not decrypted, URL filtering will not inspect encrypted URLs, leading to ineffective filtering.

Configure SSL decryption, then apply the profile to a security policy, then create URL filtering profile, then test and verify.

Why it fails: This is incorrect because you cannot apply a URL filtering profile that hasn't been created yet. The profile must exist before it can be attached to a security policy.

Test and verify, then create URL filtering profile, then configure SSL decryption, then apply the profile to a security policy.

Why it fails: This is incorrect because testing should occur after all configuration steps are completed. Testing before creating the profile or applying it to a policy would not validate the actual URL filtering functionality.

Trust: Zone for publicly accessible servers.

Why it fails: This describes the DMZ zone, not Trust.

Untrust: Zone for internal trusted networks.

Why it fails: This describes the Trust zone, not Untrust.

Using a Data Filtering profile.

Why it fails: Data Filtering is for content inspection, not application identification.

Using a URL Filtering profile.

Why it fails: URL Filtering is for content categorization, not application identification.

Using a custom application signature with a port match.

Why it fails: Port matching is part of service definitions, not custom App-ID signatures.

Define a custom service for the port.

Why it fails: Custom services are for port mapping, not application identification.

Use a Content-ID profile.

Why it fails: Content-ID profiles enforce security, not identification.

Disable SSL Decryption.

Why it fails: Disabling SSL decryption would make it harder to identify encrypted applications.

The security rules are misconfigured.

Why it fails: Security rules control whether traffic is allowed or denied; they do not perform application identification, so misconfiguration cannot stop App-ID from resolving. Checking rule configuration is tempting because it is the usual first troubleshooting step. App-ID requires the application signature content to be current and the session to be decrypted.

The firewall needs a license for App-ID.

Why it fails: App-ID requires no separate licence; it is included with the base firewall and works once content updates are installed. It is tempting because many Palo Alto features (Threat Prevention, WildFire, URL Filtering) do need licences, so a lapsed subscription would be the correct answer for those.

App-ID is disabled.

Why it fails: App-ID is enabled by default on Palo Alto firewalls and cannot be disabled; the output would still show application names. It is tempting because disabling a feature sounds like a plausible cause of no identification, and would be the answer if App-ID were a licensed subscription that had lapsed.

SSL decryption is not configured.

Why it fails: SSL decryption would not cause blocking of non-decrypted traffic.

The profile group is blocking Facebook.

Why it fails: No profile group is configured in the rule.

The rule order is incorrect.

Why it fails: Without additional rules, this rule would match all traffic, but Facebook is not in the application list.

Use a file blocking profile.

Why it fails: File blocking blocks file types, not applications.

Change application to ['unknown-tcp', 'unknown-udp'].

Why it fails: That would only block unidentified traffic, not all non-web-browsing apps.

Change category to ['misccategory'].

Why it fails: Categories are not used to block applications.

Use an Application Override to identify executables.

Why it fails: Application Override reclassifies traffic to a custom application on a specified port; it cannot inspect payload content to identify executables. File Blocking performs that signature-based detection over HTTP and HTTPS. Application Override suits custom or non-standard applications that App-ID misidentifies, not granular file-type enforcement.

Create a Data Filtering Profile to block executable file types.

Why it fails: Data Filtering inspects file content and blocks by file type, but it requires the file transfer to begin before detection, and it does not restrict by URL category. It is the correct feature for blocking sensitive data patterns such as credit card numbers in transit.

Configure a URL Filtering Profile to block executables.

Why it fails: URL Filtering blocks by URL category or reputation, not by file type, so executable downloads from allowed categories pass through. It is the right feature when restricting access to categories such as malware or phishing sites, not for file-extension control.

Application Filter with conditions matching Microsoft Teams.

Why it fails: An Application Filter is a reusable container that groups applications for filtering elsewhere; it cannot itself be referenced in the Application column to permit one app and deny peers. It would be correct when building a named collection of applications to reuse across multiple rules.

Service object for Microsoft Teams' ports.

Why it fails: A Service object matches TCP/UDP port and protocol only, so any chat application using those ports would pass; it cannot identify Microsoft Teams by App-ID. It is correct when the requirement is to permit traffic to specific ports regardless of the application generating it.

Application Group named 'Chat_Apps' containing all chat apps.

Why it fails: An Application Group listing all chat apps permits every member, so rival chat clients would be allowed rather than denied. It is tempting because grouping chat applications is the natural approach when the requirement is to allow all chat traffic, not single out Microsoft Teams.

Ensure the security rule includes the application 'pdf-download' in the Application list.

Why it fails: There is no 'pdf-download' application; PDF is a file type.

Check that the File Blocking Profile has 'PDF' selected under 'File Types to Block'.

Why it fails: The profile likely has it; the issue is the rule's application.

Verify the URL Category of the web application is included in the rule.

Why it fails: URL Category is separate from file blocking.

The 'malware' URL Category is not added to the security rule's URL Category list.

Why it fails: URL categories are used in the profile, not the rule's category list.

The 'web-browsing' application is not being identified correctly by App-ID.

Why it fails: If web-browsing is allowed, it is likely identified.

SSL Decryption is not enabled, so the firewall cannot inspect HTTPS URLs.

Why it fails: URL Filtering works even without SSL Decryption for HTTPS, using host and URI.

The traffic is denied by the implicit deny rule at the end.

Why it fails: The implicit deny only applies when no rule matches; the exhibit's policy explicitly addresses the FTP session, so a matching rule governs the outcome. Implicit deny is genuinely the fallback for unmatched traffic, and would be correct if no rule referenced the relevant application or service.

The traffic is allowed because 'Allow-Web' matches web-browsing over port 80 or 443.

Why it fails: Allow-Web matches only web-browsing on ports 80 and 443, so it cannot match FTP on TCP port 21. This option is tempting because web-browsing rules are commonly present and permissive, but the application and port in the stem fall outside that rule's scope.

The traffic is allowed because no rule explicitly blocks it.

Why it fails: Palo Alto Networks firewalls deny traffic by default when no security rule matches, so an implicit deny drops the session before it reaches the FTP server. The tempting idea that unmatched traffic passes reflects permissive ACL logic, where a final permit-any rule is often configured; here no such rule exists, so the connection fails.