Platform Solutions Services And Tools practice questions

Objects > Licenses > Activation

Why it fails: Licenses are managed at the Panorama system level, not under Objects.

Panorama > Licenses

Why it fails: This is the correct path for viewing and activating license entitlements for managed devices.

Device > Software > Update

Why it fails: This is used for software images, not license activation.

show system license

Why it fails: This command does not exist.

check license-status

Why it fails: This is not a valid CLI command.

debug license fetch

Why it fails: This is a debug-level command not intended for standard verification.

Enable 'Local Policy Precedence' on all firewalls.

Why it fails: This would allow local policies to override SCM, the opposite of the requirement.

Disable 'Management Plane Access' for local admins.

Why it fails: This prevents local management but doesn't handle policy inheritance.

Configure 'Auto-Commit' on every firewall.

Why it fails: Auto-commit does not control policy precedence.

Execute 'request system software upgrade' on each firewall sequentially via CLI.

Why it fails: This is manual and does not leverage Panorama's orchestration.

Use an external script to trigger reboots.

Why it fails: While possible, it is not the native Panorama best practice for management.

Set the 'Maintenance Window' in Device Group settings.

Why it fails: Panorama does not have a global 'Maintenance Window' setting for automated reboots.

SSH

Why it fails: SSH is for CLI access, not automated configuration synchronization.

HTTP

Why it fails: HTTP is insecure and not used for configuration management.

SNMPv3

Why it fails: SNMP is used for monitoring, not configuration sync.

Manually export and import XML configurations for every device group.

Why it fails: While possible, this does not integrate the management plane as required.

Enable Panorama mode on SCM.

Why it fails: SCM operates as a unified manager, not a Panorama clone.

Re-register all managed firewalls directly to SCM via serial number.

Why it fails: This would break existing management and is not the intended migration path.

Only manage the Active unit in Panorama.

Why it fails: Both must be visible to Panorama for monitoring and health tracking.

Add both firewalls as independent devices and push separate configs.

Why it fails: This would break HA synchronization and create conflicts.

Disable HA before adding to Panorama, then re-enable.

Why it fails: This is unnecessary and disruptive.

Export the policy to CSV and re-import.

Why it fails: This is irrelevant to policy cleanup.

Immediately delete the rule.

Why it fails: This is risky; the rule should be disabled first for a period of time.

Rename the rule to 'Old_Rule' and leave it.

Why it fails: This causes rule base clutter and is not a clean management practice.

Configure a static route to the SCM cloud URL.

Why it fails: Static routing is usually handled via DHCP or standard gateway settings.

Create a local admin user with full permissions.

Why it fails: SCM manages identity centrally.

Enable Panorama mode on the firewall.

Why it fails: SCM uses its own cloud-agent, not the Panorama-agent.

Generate license renewal quotes.

Why it fails: Quotes are handled through sales channels, not the SCM interface.

Configure threat signature update frequency.

Why it fails: Signature frequency is configured in the Device tab, not the Subscription Management tab.

Check the firewall's local 'Traffic' log.

Why it fails: Traffic logs do not display configuration push status.

System log export

Why it fails: System logs are for historical review, not real-time monitoring.

Use the CLI 'show system state' command.

Why it fails: This command shows hardware status, not commit status.

A static public IP for the firewall.

Why it fails: Panorama can manage a firewall whose public address changes, provided the firewall initiates the connection; a static public IP is unnecessary. It is tempting because static addressing does simplify inbound management access, which suits firewalls with directly reachable, unchanging public interfaces.

SNMP community string configured.

Why it fails: Panorama manages firewalls over its own management plane using certificates and service routes; SNMP is for monitoring and traps, not management connectivity. It tempts because SNMP is commonly configured on firewalls for health polling, and would be relevant when integrating devices into a network monitoring platform.

Enable 'Log Forwarding' and select the 'Include Source IP' option.

Why it fails: 'Log Forwarding' is the feature that sends logs to external servers, but there is no 'Include Source IP' option within it. The source IP is typically included by default in traffic logs, but for other log types, you might need to use a custom log format. This option is wrong because it references a non-existent setting.

Enable 'Enhanced Logging' in the log forwarding profile.

Why it fails: Enhanced Logging adds extra fields to logs, but it does not specifically ensure the source IP of the original sender is included. It is used for additional metadata and is not the correct setting for this requirement. This option is a distractor because it sounds like it would enhance logs, but it does not address the specific need.

Configure the syslog server to use TCP instead of UDP.

Why it fails: Using TCP for syslog improves reliability but does not affect the content of the logs, including the source IP. The protocol choice does not determine whether the original sender's IP is logged. This option is incorrect because it addresses transport reliability, not log content.

Compliance Profile

Why it fails: Compliance Profile is not a native object in Strata Cloud Manager for defining evaluation logic. While profiles exist for other features like security profiles, they are not used for compliance checks. The correct component for defining check logic and severity is the Compliance Check itself, not a profile.

Compliance Rule

Why it fails: Compliance Rule is not a valid object in Strata Cloud Manager. The platform uses Compliance Checks and Compliance Policies. A rule might be confused with a security rule, but that is unrelated to compliance evaluation. The evaluation logic and severity are configured within a Compliance Check.

Compliance Policy

Why it fails: A Compliance Policy in Strata Cloud Manager groups multiple compliance checks and assigns them to scopes, but it does not define the evaluation logic or severity for an individual check. The evaluation logic and severity are defined within the check itself, not the policy. The policy simply organizes checks and determines which devices they apply to.

Configure the firewall to use a Panorama server as its management plane.

Why it fails: Panorama is a separate management platform and is not used for SCM connectivity. Using a Panorama server would direct the firewall to a different management system, preventing it from registering with SCM. This action does not fulfill the requirement for SCM management.

Install a valid WildFire license and configure a log forwarding profile to SCM.

Why it fails: While WildFire and log forwarding are useful features, they are not required for basic SCM management connectivity. SCM management requires a specific cloud management enablement and registration process, not just a WildFire license. This option does not address the core requirement.

Set up a site-to-site VPN tunnel between the firewall and the SCM portal.

Why it fails: SCM communication occurs over the internet using secure outbound connections; a site-to-site VPN is not necessary. SCM is a cloud-based service that firewalls connect to directly. Configuring a VPN tunnel would be an unnecessary and incorrect step for SCM management.

It provides a real-time dashboard of all active sessions and their associated applications, users, and threats.

Why it fails: A real-time session dashboard is a monitoring feature, often found in the ACC or similar tabs. Policy Optimizer does not provide live session tracking; it works on historical logs to suggest rule improvements. The administrator would use a different tool for real-time visibility into active sessions and threats.

It simulates the impact of a policy change by replaying captured packets against the new ruleset before committing.

Why it fails: Policy Optimizer does not replay packets or simulate policy changes. That functionality is provided by separate tools like Policy Test or simulation modes in some firewalls. Policy Optimizer focuses on rule usage analysis and recommendation, not on packet-level simulation, so it cannot provide a pre-commit impact assessment.

It enforces a baseline security policy across all managed devices to ensure compliance with organizational standards.

Why it fails: Enforcing a baseline policy across devices is typically done through templates or device groups in a centralized management system, not through Policy Optimizer. Policy Optimizer is concerned with optimizing existing rules on a single device or managed set, not with pushing a uniform baseline policy to multiple devices.

scm get firewalls

Why it fails: 'scm get firewalls' is not a valid SCM CLI command. The SCM CLI uses 'show' for read operations, not 'get'. Using 'get' will produce a syntax error. The administrator should use 'scm show firewalls' to list managed firewalls.

scm list firewalls

Why it fails: 'scm list firewalls' is not a valid command in the SCM CLI. The CLI uses 'show' for retrieval operations, not 'list'. While 'list' might be intuitive, it is not part of the SCM command set. The administrator should use 'scm show firewalls' to obtain the desired information.

scm show devices

Why it fails: 'scm show devices' is not a valid Strata Cloud Manager CLI command. The correct command to list managed firewalls is 'scm show firewalls'. Using an incorrect command will result in an error or no output, so the administrator must use the exact syntax provided by the SCM CLI.

Tags

Why it fails: Tags are used for metadata and can be used in dynamic address groups, but they are not the primary method for grouping firewalls for policy application in SCM. Folders are the correct construct for hierarchical device grouping and policy targeting.

Device Groups

Why it fails: Device Groups are used in Panorama, not in SCM. In SCM, the equivalent grouping mechanism is different. Using Device Groups would be a misunderstanding of SCM's architecture. SCM does not use Device Groups for policy targeting.

Templates

Why it fails: Templates in SCM are used to define network and device settings, not security policy rules. While templates can be applied to folders, they are not the grouping mechanism for policy application. The question asks for grouping firewalls for policy application, which is done via folders.

A PUT request to /api/?type=config&action=edit&xpath=/config/devices/entry/vsys/entry[@name='vsys1']/address-group/entry[@name='DAG']&element=<dynamic><filter>1.2.3.4</filter></dynamic>

Why it fails: This request attempts to edit the dynamic filter expression of the address group, which defines the tags that determine membership. It does not add a specific IP address to the group at runtime. Changing the filter would alter which tagged IPs belong, but it requires a commit and does not register an individual IP as a DAG member.

A GET request to /api/?type=config&action=set&xpath=/config/devices/entry/vsys/entry[@name='vsys1']/address-group/entry[@name='DAG']&element=<static><member>1.2.3.4</member></static>

Why it fails: This request modifies the static address group configuration, which requires a commit to take effect and is not dynamic. Dynamic Address Groups are populated at runtime by the User-ID process, not by editing the static member list. Using a config set operation would also overwrite existing members and is not the correct API for dynamic registration.

A POST request to /api/?type=op&cmd=<register-ip><ip>1.2.3.4</ip><dag>DAG</dag></register-ip>

Why it fails: The operational command API supports specific commands, but there is no standard 'register-ip' operational command for Dynamic Address Groups. DAG registration is performed through the User-ID API, not through an arbitrary op command. This request would return an error because the command is not recognized by the firewall.

JSON

Why it fails: JSON (JavaScript Object Notation) is a structured format that is widely used, but Palo Alto Networks firewalls do not natively support JSON as a log format for forwarding. While some systems can convert logs to JSON, the firewall itself does not offer a JSON format option in the log forwarding profile.

Syslog

Why it fails: Syslog is a protocol for transmitting logs, not a log format. While logs can be sent via syslog, the format of the log content is separate. The question asks for log format options, and syslog is not a format but a transport method. Thus, it is incorrect.

CEF

Why it fails: CEF (Common Event Format) is another structured format often used with SIEMs, but it is not natively supported by Palo Alto Networks firewalls for log forwarding. While some SIEMs accept CEF, the firewall does not provide a built-in CEF format option. Therefore, it is not a valid choice here.