Select Two (Multi-Select) Questions

IPsec VPNike gateway settings

Why it fails: IKE gateway settings belong to IPsec VPN configuration, not UTM, which inspects traffic after it is decrypted and matched. It is tempting because both features are configured on the same SRX and both concern traffic handling, but IKE negotiation occurs in the VPN profile, not the UTM policy profile.

BGP routing protocol parameters

Why it fails: BGP is a routing protocol handled by the routing engine, entirely separate from UTM's content-security inspection pipeline. It is tempting because UTM profiles are configured on SRX devices that also run BGP, but routing parameters belong in routing-instance and protocol configuration, not a UTM policy.

packet-drop-immediate

Why it fails: Junos offers session-init, session-close and session-policy-change as logging modifiers; packet-drop-immediate is not one. It is tempting because packet drops are logged by other Junos facilities, so the phrase sounds like plausible drop-reporting behaviour rather than a fabricated policy logging modifier.

state-change-alert

Why it fails: Junos security policy logging modifiers are session-init, session-close and session-policy-change; state-change-alert is not among them. It is tempting because stateful firewalls do track session state transitions, so the wording sounds like genuine session logging terminology rather than an invented modifier.

VLAN bridge domain definitions

Why it fails: VLAN bridge domains are Layer 2 constructs configured under [edit bridge-domains] or [edit interfaces], not the security hierarchy, which holds zones, screen options and policies. It is tempting because VLAN segmentation underpins security design, and bridge domains would be the right place when defining Layer 2 broadcast domains on an SRX.

BGP routing protocol peering parameters

Why it fails: BGP peering parameters sit under [edit protocols bgp], a routing hierarchy entirely separate from [edit security], which contains zones, screen and policies. It is tempting because security devices do run BGP, and configuring peering would be correct when the SRX must exchange routes with upstream routers.

Custom applications automatically generate Application Layer Gateways for proprietary protocols without manual configuration.

Why it fails: Custom apps do not auto-generate ALGs.

Custom applications are restricted to global policies only and cannot be used in zone-to-zone policies.

Why it fails: Custom applications can be used in any security policy.

Custom applications can overwrite built-in predefined Junos applications if named identically.

Why it fails: Predefined applications cannot be overwritten; name collisions cause commit errors.

Cluster control ports must connect to an external public internet switch.

Why it fails: Chassis cluster control and fabric links must interconnect the two SRX nodes directly, typically via dedicated ports on a private segment; routing them through a public internet switch exposes heartbeats to latency and tampering, breaking failover. External switching is only relevant for out-of-band management reachability, not cluster transport.

Both devices must have different Junos OS major versions to prevent split-brain.

Why it fails: Cluster formation demands identical Junos OS releases on both nodes; mismatched major versions prevent the control plane from synchronising and are unsupported. Different versions are never a split-brain guard — that role belongs to the control link and heartbeat. Version parity is required precisely so both nodes run the same cluster daemons.

Executing physical layer framing on physical interface transceivers

Why it fails: Physical layer framing is performed by interface hardware such as PIMs and transceivers, not by the Routing Engine, which handles control-plane functions including routing protocols, chassis management and CLI access. It is tempting because the RE manages interface configuration, but framing itself is a data-plane function.

Processing high-speed security sessions and firewall policy enforcement

Why it fails: High-speed session processing and policy enforcement run on the Services Processing Unit and data plane, not the Routing Engine, which handles control-plane functions such as routing protocols and chassis management. It is tempting because the RE does run Junos control processes, but forwarding and policy enforcement are deliberately offloaded.

Performing hardware-accelerated NAT translations in the data plane

Why it fails: Hardware-accelerated NAT translation occurs in the data plane on the Services Processing Unit, not on the Routing Engine, which handles control-plane tasks such as routing protocol adjacencies and CLI management. It is tempting because NAT is configured via the RE, but the actual translation is performed by forwarding hardware.

BGP autonomous system number

Why it fails: A BGP autonomous system number belongs to routing-protocol configuration, not to defining a logical unit; the unit needs a unit number and an IP address for routing. It is tempting because BGP runs over interfaces, and it would be correct when configuring an external BGP peer session.

Chassis cluster redundancy group ID

Why it fails: A redundancy group ID applies to chassis cluster failover, not to logical unit definition; IP routing needs a unit number and an address. It is tempting because cluster configuration references interfaces, and it would be correct when assigning an interface to a redundancy group for failover.

MAC address override

Why it fails: A MAC address override is optional and only alters the source MAC on the logical unit; IP routing requires a logical unit number and an IP address. It is tempting because MAC settings appear in interface configuration, and it would be correct when the upstream device expects a specific MAC.

Clear the routing forwarding table.

Why it fails: Clearing the routing forwarding table removes learned routes, disrupting all traffic without freeing any NAT source ports; port exhaustion stems from pool size or translation timeout settings. It is tempting because clearing forwarding tables is a standard remedy for stale or incorrect route entries, which is a routing problem, not a NAT port allocation problem.

Convert all Source NAT rules into Destination NAT rules.

Why it fails: Destination NAT rewrites the destination address of inbound traffic and cannot translate outbound source addresses, so converting rules removes the source translation that clients require. It is tempting because both are NAT rule types configurable in the same policy hierarchy, but destination NAT serves inbound publishing, not outbound internet access.

Disable security flow processing on the trust zone.

Why it fails: Disabling security flow processing on the trust zone halts session creation entirely, so no new NAT translations occur and the symptom is masked rather than resolved. It is tempting because disabling flow processing is used diagnostically to isolate whether the security module is dropping traffic, not to reclaim exhausted NAT ports.

Policy configuration changes take effect immediately without requiring a commit command.

Why it fails: Junos uses a candidate configuration model, so policy changes remain inactive until you issue a commit. Changes are not applied immediately on entry; commit, commit check and rollback control when the candidate becomes the active configuration.

Policies can only be configured via J-Web and are unsupported on the CLI.

Why it fails: Junos security policies are configured through the CLI as well as J-Web, so claiming CLI is unsupported is false. Both interfaces edit the same candidate configuration; J-Web merely provides a graphical alternative to the set and edit commands.

HTTP (Hypertext Transfer Protocol)

Why it fails: HTTP payloads contain no embedded address or port requiring inspection, so Junos OS passes it without an ALG. It is tempting because it is a widely used application protocol, and would be correct only for protocols such as FTP, SIP or TFTP that negotiate dynamic ports.

SSH (Secure Shell)

Why it fails: SSH operates on a single TCP port and does not use an ALG.

BGP

Why it fails: BGP is a routing protocol that exchanges reachability information between autonomous systems; it transports no payload files for antivirus inspection. It is tempting because BGP is configured on SRX devices in routing scenarios, and it would be correct if the question asked which protocol populates the routing table for traffic forwarding.

SNMP

Why it fails: SNMP carries device management and monitoring data such as interface counters and traps, not user file transfers, so no content reaches the antivirus scanner. It is tempting because SNMP is commonly enabled on SRX for monitoring, and it would be correct if the question concerned polling device health or receiving alerts.

NTP

Why it fails: NTP synchronises clocks between network devices; it carries no file content, so the SRX antivirus engine has nothing to scan. It is tempting because NTP is a standard protocol configured on SRX devices for time accuracy, and it would be the right answer to a question about log timestamp correlation or certificate validation.

show security alg status

Why it fails: ALG status shows application-layer gateway behaviour for protocols such as SIP or FTP, revealing nothing about IKE Phase 1, Phase 2 or installed security associations. It would be the right command when troubleshooting NAT or ALG-related session failures, not IPsec tunnel establishment.

show security flow session summary

Why it fails: Flow session summary counts active sessions and shows whether traffic matches a policy, but exposes no IKE Phase 1 or Phase 2 state and no security association details. It suits general traffic-flow troubleshooting; verifying tunnel negotiation requires the ike and ipsec security-associations commands.

show chassis routing-engine

Why it fails: This command reports Routing Engine CPU, memory and uptime, not flow or session data held in the session table. It tempts because chassis and RE health monitoring feels adjacent to security monitoring, but it would be correct for diagnosing control-plane resource exhaustion, not inspecting active sessions.

show system processes

Why it fails: This displays running processes and resource consumption on the device, not security flow sessions. It tempts because process monitoring is a legitimate operational task, but it would be correct for troubleshooting daemon crashes or CPU spikes, not for observing active session state in real time.

show security zone statistics

Why it fails: Zone statistics counters show packet and byte totals per zone, not individual session entries or their state. It tempts because zone-level traffic visibility sounds like session monitoring, but it would be correct for confirming whether traffic traverses a zone or triggering thresholds, not listing live sessions.

Set the security policy action to 'reject' for the targeted traffic.

Why it fails: Trace output requires the session to match a policy that permits logging, so a reject action terminates the flow before trace data is captured. Reject is tempting because it confirms policy enforcement, and it would be the right choice when the goal is to block and log denied traffic rather than diagnose an existing drop.

Enable kernel-level debugging via the FreeBSD shell.

Why it fails: Kernel-level debugging through the FreeBSD shell is not a security flow traceoption element; trace output requires configuring the traceoptions stanza, the file destination and the relevant flow or packet filters. It is tempting because shell debugging exists for deep packet inspection, but it is unrelated to generating policy trace output.

Functional zone names directly as match criteria for payload inspection

Why it fails: Functional zone names cannot serve as match criteria for payload inspection; Junos security policies match on zone context via from-zone and to-zone, not as an inspection object. This option tempts because functional zones do exist and are referenced in policy configuration, but they define traffic direction rather than being a referencable object for inspection.

SCREEN option profiles

Why it fails: SCREEN option profiles attach to zones for antispoofing, flood and session-limit protection, not to security policies, so they cannot be referenced there. They are tempting because they are security objects configured alongside policies, and would be the right choice when hardening a zone against reconnaissance and DoS attacks.

Hardware crypto processor allocation maps

Why it fails: Hardware crypto processor allocation maps configure which cryptographic engine handles IPsec processing, not match criteria within a security policy. They are tempting because they genuinely appear in Junos security configuration, but under `[edit security]` for IPsec acceleration tuning. A security policy references zones, addresses, applications, and users instead.

SMTP encryption certificate and private key

Why it fails: DNSBL lookups query an external DNS server for the sending IP's reputation; no SMTP encryption certificate or private key is involved in that query. Certificates are configured for SMTP TLS inspection profiles, which is a separate antispam feature.

POP3/IMAP proxy port numbers

Why it fails: DNSBL profiles query DNS servers to check sending IP reputation; they do not proxy POP3 or IMAP, which are mail retrieval protocols. POP3/IMAP proxy ports belong to Juniper's antivirus or content filtering proxy configuration, not to DNSBL antispam inspection.

Changes made in configuration mode take effect immediately without a commit.

Why it fails: Junos configuration changes are held in a candidate configuration and take effect only after a commit, so edits are not immediate. It is tempting because many network operating systems apply commands instantly, but Junos deliberately separates candidate editing from the active configuration until commit.

Configuration commands must be typed entirely in lowercase hexadecimal.

Why it fails: Junos configuration statements use normal alphanumeric syntax with lowercase keywords, not hexadecimal encoding. It is tempting because some low-level identifiers appear numeric, but hexadecimal is a representation format, not the grammar of the configuration hierarchy, which accepts standard text commands.

The CLI cannot display configuration in set format.

Why it fails: Junos OS supports both hierarchical and set formats; the CLI displays configuration in set format via 'show configuration | display set'. The statement is false. It tempts candidates because hierarchical output is the default view, leading some to assume set format is unavailable.

Immediate CPU kernel panic generation

Why it fails: A kernel panic is a fatal crash triggered by unrecoverable errors, not a step in establishing a session; the first packet instead triggers a session lookup miss and route and policy evaluation. It is tempting because security processing does involve the kernel, but panics are a failure symptom, never normal packet-flow behaviour.

Automatic conversion of IPv4 to IPv6

Why it fails: The SRX processes IPv4 and IPv6 packets natively and never translates between them during session setup; translation requires NAT64 or similar explicit configuration. It is tempting because dual-stack handling is a real SRX capability, but automatic protocol conversion is not part of initial packet flow processing.

Immediate flooding of the packet to all zone interfaces

Why it fails: Flooding to all zone interfaces is switch behaviour for unknown unicast, not SRX session establishment; the SRX forwards the first packet only after route lookup and policy evaluation permit it. It is tempting because unknown-destination traffic is flooded in Layer 2 domains, but a firewall never broadcasts a new session's packets across zones.

Application Layer Gateway profiles

Why it fails: Address sets hold addresses, prefixes and nested address sets for use in security policies; ALG profiles are application-layer objects, not address entries. ALG profiles belong in policy statements handling protocols such as SIP or FTP.

Security zone interface names

Why it fails: Address sets group address-book entries — IPv4/IPv6 prefixes, wildcard addresses and pre-defined addresses — not interface names. Interface names belong to zone configuration, which is why the option tempts: zones reference interfaces, but that is a separate hierarchy from address books.

Chassis power supply voltage levels

Why it fails: Traceoptions output covers packet-processing decisions such as ingress interface, session lookup, policy match and drop reason, not hardware telemetry. Chassis voltage readings come from SNMP or chassis alarms, so they never appear in flow traceoptions, however useful they are for diagnosing power faults.

BGP AS path recomputation steps

Why it fails: Flow traceoptions record security-processing steps — session creation, policy lookup, NAT and drop cause — not routing protocol internals. BGP AS path recomputation is diagnosed with routing traceoptions or show route detail, so it cannot appear in security flow traceoptions output.