Hard Difficulty Questions

Traffic is automatically forwarded without NAT translation.

Why it fails: Packets cannot bypass translation once a source NAT rule matches; the SRX drops them instead of forwarding untranslated. Forwarding without NAT would leak private addresses and defeat the configured policy. Untranslated forwarding occurs only when no NAT rule matches, not when the pool is exhausted.

The SRX reboots automatically to clear port tables.

Why it fails: An exhausted source NAT pool causes the SRX to drop packets requiring translation, since no port can be allocated; it never triggers a reboot. Reboots stem from crashes or manual action. Pool exhaustion is diagnosed precisely through the utilisation output shown, confirming drops rather than device restart.

Traffic is diverted to the backup routing instance.

Why it fails: Pool exhaustion drops the session; traffic is not redirected to another routing instance. Backup routing instances serve failure isolation or traffic segregation, not NAT resource shortages. The packet simply cannot obtain a translated address, so forwarding halts at the NAT stage rather than diverting elsewhere.

Convert all source NAT rules to interface-based NAT to bypass pool evaluation errors.

Why it fails: Interface-based NAT still evaluates the same rule-set ordering, so the restrictive Zone A rule continues to match Zone B traffic first; it does not bypass evaluation. It tempts because interface NAT suits single-zone egress with one egress interface, where pool selection is unnecessary.

Enable global zone-bypass mode for all source NAT pools.

Why it fails: Global zone-bypass mode disables zone-based NAT rule evaluation entirely, which removes the zone scoping that the shared pool depends on and breaks isolation between Zone A and Zone B. It is tempting as a quick fix, and it would be correct only where zone context is irrelevant to NAT matching.

Merge all zones into a single security zone to eliminate rule-set evaluation discrepancies.

Why it fails: Merging zones removes the zone boundary that the restrictive Zone A rule relies on, so the generic rule would then apply to all users and the intended restriction is lost. It is tempting because it eliminates evaluation discrepancies, and it would be correct only where no per-zone policy differentiation is required.

Virtual machine snapshot scheduling

Why it fails: Snapshot scheduling only captures point-in-time VM disk images for backup or rollback; it does not expose SR-IOV or virtio ring interfaces to the guest, so DMA and driver offload remain unavailable. It is tempting because snapshots are a familiar vSRX operational task, and it would be correct when protecting a working configuration before an upgrade.

SNMP v3 trap forwarding

Why it fails: SNMP v3 trap forwarding only transports encrypted event notifications to a management station; it does not alter the virtual NIC model, so DMA and optimised drivers stay absent. It is tempting because monitoring is part of vSRX deployment, and it would be correct when integrating the device into an existing SNMP-based network management platform.

RADIUS accounting synchronization

Why it fails: RADIUS accounting synchronisation only reports session start, stop and interim usage records to an authentication server; it has no bearing on how the hypervisor hands packets to the vSRX data plane. It is tempting because RADIUS appears throughout Juniper security configuration, and it would be correct when centralising user session accounting for auditing.

The security policy action must be changed from 'permit' to 'allow-pasv'.

Why it fails: Junos security policies have no 'allow-pasv' action; actions are permit, deny, reject and count. PASV failures stem from the control session permitting only junos-ftp, so the dynamically negotiated data ports are dropped. The fix is an application-set or ALG permitting junos-ftp plus the PASV data channel.

FTP must be replaced with SFTP because security policies cannot support stateful FTP parsing.

Why it fails: Junos security policies do perform stateful FTP ALG inspection, so SFTP is unnecessary and changes the protocol entirely. It is tempting because SFTP avoids FTP's data-channel complexity, and it would be the right choice when policy constraints genuinely forbid FTP.

A separate security policy must be created allowing traffic from untrust back to trust for port 20.

Why it fails: PASV mode opens data connections from the server to a client-chosen high port, so a port 20 policy is irrelevant. It is tempting because active FTP does use server port 20, and that policy would be the right choice for classic active-mode transfers.

The TCP proxy is disabled in the security zone.

Why it fails: TFTP uses UDP port 69, so a TCP proxy setting is irrelevant to its traffic. It is tempting because proxy configuration exists in security zones, but the actual cause is the SRX's default UDP session timeout expiring before the transfer completes, not TCP proxying.

Address books are blocking high-numbered UDP ephemeral ports.

Why it fails: Address books hold IP prefixes and cannot block UDP ephemeral ports; they are used for policy matching, not port filtering. It is tempting because address books affect traffic flow, but TFTP failure here stems from the SRX's default UDP session timeout, not address-book entries.

Screen options are misinterpreting TFTP data packets as a UDP flood attack.

Why it fails: Screen options detect floods by packet rate, not by inspecting TFTP payload content, so they would not misread data packets as a UDP flood. It is tempting because screens do police UDP floods, but TFTP's failure across an SRX arises from the short default UDP session timeout.

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.

/var/tmp/trace/

Why it fails: Flow traceoptions writes its output to /var/log, not /var/tmp/trace. The /var/tmp path holds temporary files such as crash dumps and configuration rollback copies, so it would be the right location only for those artefacts, not security flow debugging.

/var/db/security/logs/

Why it fails: /var/db/security/logs stores security log and session data, not flow traceoptions output, which lands in /var/log. This directory would be the correct answer if the question asked where session logs or policy logging records are written.

/config/logging/

Why it fails: /config/logging is not where flow traceoptions writes; trace output defaults to /var/log. The /config hierarchy holds the committed configuration and related persistent files, so it would be relevant when locating configuration backups rather than debugging traces.

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.

It timestamps every transit packet passing through the security zone for latency analysis.

Why it fails: SCREEN options drop or log matching traffic; they do not append timestamps to transit packets for latency measurement. It is tempting because timestamping sounds like a diagnostic feature, and would be correct if the goal were per-packet latency analysis, which is performed by other tools rather than a zone SCREEN.

It drops all ICMP packets that have invalid timestamp header fields.

Why it fails: The icmp timestamp SCREEN option detects and blocks ICMP timestamp requests and replies used for reconnaissance, not packets with malformed timestamp header fields. It is tempting because the name suggests header validation, and would be correct if the feature inspected timestamp field contents rather than the ICMP type itself.

It synchronizes the SRX system clock using ICMP timestamp replies from trusted gateways.

Why it fails: SCREEN options are stateless packet filters applied to zone traffic; they never synchronise the SRX clock, which is handled by NTP. It is tempting because the word 'timestamp' implies timekeeping, and would be correct if the requirement were clock synchronisation from trusted gateways rather than attack mitigation.

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.

The device reboots to clear the session table and re-evaluate all rules.

Why it fails: Junos does not reboot to enforce schedulers; the device re-evaluates policy against the session table without restarting. It is tempting because a reboot would clear all sessions, which is the right action when troubleshooting requires flushing stale state, not schedule enforcement.

Existing sessions are immediately converted to 'reject' action state and send ICMP unreachable messages.

Why it fails: Scheduler expiry does not alter established sessions; the policy is evaluated only when a session is initiated, so existing flows persist until they close or time out. The reject action with ICMP unreachable applies to new connection attempts arriving outside the window, which is why the scheduler is attractive for time-based access control.

Existing active sessions are immediately terminated the moment the schedule window closes.

Why it fails: Junos does not tear down established sessions when a schedule window closes; existing sessions persist until they end naturally, and only new sessions are denied. It is tempting because immediate termination matches strict access control expectations, which is correct when policy demands no lingering access.

AppID profiles must be configured under the [edit security utm] hierarchy.

Why it fails: Incorrect. AppID is part of AppSecure, configured under security application-tracking or policies, not UTM.

AppID is exclusively available for global security policies and cannot be used in zone-based policies.

Why it fails: Incorrect. AppID is fully supported in both zone-based and global policies.

AppID policies automatically bypass stateful inspection for encrypted payloads.

Why it fails: Incorrect. Stateful inspection remains active.

The source zone does not have host-inbound-traffic enabled for UDP.

Why it fails: Incorrect. Host-inbound-traffic is for traffic destined to the SRX control plane, not transit traffic.

UDP traffic cannot be matched by security policies and requires stateless filters.

Why it fails: Incorrect. Security policies fully support UDP traffic.

Global policies always block custom applications by default.

Why it fails: Incorrect. Global policies support custom applications.

show security spc processes

Why it fails: SPC processes are not displayed via system process summaries.

show kernel cpu-usage

Why it fails: Incorrect command syntax.

show chassis cpu-processes

Why it fails: This is not a valid Junos operational command.

Manually restart the flow processing daemon (flowd) after every time zone change.

Why it fails: Restarting flowd does not synchronise the clock; the device still runs UTC while the schedule expects local time, so windows stay misaligned. It is tempting as a quick remediation, but flowd restart affects packet processing, not the system time source that schedules reference.

Convert all schedule parameters in the policy configuration to use absolute epoch timestamps.

Why it fails: Junos security schedules accept day and time-of-day parameters, not epoch timestamps, so this configuration is unsupported. It is tempting as a way to remove time-zone ambiguity, but the actual fix is synchronising the device clock via NTP so local-time schedules evaluate correctly.

Disable stateful inspection so that schedule checks occur on every individual packet.

Why it fails: Disabling stateful inspection does not correct the clock mismatch; schedules still evaluate against the device's UTC time, so access windows remain wrong. It is tempting as a troubleshooting step, but stateful inspection is unrelated to schedule evaluation, which depends on synchronised system time.

Yes, provided the virtual routers are interconnected by internal tunnels.

Why it fails: Security zones bind to a single virtual router's interfaces; internal tunnels between virtual routers do not let one zone contain interfaces from two routing instances. Tunnels suit inter-VR connectivity, not zone membership, which requires interfaces within the same routing instance.

No, unless logical systems (Logical Systems) are configured on the SRX device.

Why it fails: Logical systems partition a device into separate administrative domains, but they do not enable a single security zone to span virtual routers; zones still bind to interfaces within one routing instance. Logical systems suit multi-tenant separation, not cross-VR zone membership.

Yes, by defining the security zone at the global routing instance level.

Why it fails: No global routing instance exists to host security zones across virtual routers; each zone attaches to interfaces within one routing instance. A global instance concept suits shared routing tables, not zone definition, so this does not permit zones spanning separate virtual routers.

show security session timeout-status

Why it fails: No such operational command exists on Junos; timeout-status is not a valid show security session keyword, so it returns a syntax error rather than the configured TCP ageing values. It is tempting because it sounds like a status query, but timeout inspection is done via show security flow session or configuration display, not a dedicated status command.

show firewall timeout-settings

Why it fails: show firewall timeout-settings does not exist in Junos; firewall timeout values live under security flow tcp-session, inspected via show configuration security flow or show security flow session. It tempts because "firewall" implies SRX policy scope, but the command syntax belongs to no real Junos hierarchy.

show system connection-timeout

Why it fails: show system connection-timeout is not a valid Junos operational command; SRX session ageing is configured under security flow tcp-session and viewed with show security flow session, not a system-level connection-timeout keyword. It tempts because "system" suggests global settings, but that hierarchy holds host-level parameters, not firewall session timeouts.

/config/trace/

Why it fails: Junos stores traceoptions output under /var/log, not /config, which holds the committed configuration and rescue files. /config is tempting because traceoptions are configured in the CLI, but the resulting log file is written to the /var/log directory tree.

/tmp/

Why it fails: Traceoptions write to /var/log, not /tmp, which is volatile scratch space cleared on reboot and not where Junos stores trace output. /tmp is tempting because many Unix tools default there, but Junos traceoptions files are configured under /var/log with a filename.

/var/db/

Why it fails: Traceoptions output goes to /var/log, not /var/db, which holds persistent databases such as licence keys and DHCP bindings. /var/db is tempting as a Junos state directory, but traceoptions files are written to /var/log with the configured filename.

Proxy ARP automatically performs port address translation for ICMP packets.

Why it fails: Proxy ARP is strictly Layer 2 ARP resolution and does not handle Layer 4 port translation.

Proxy ARP is required for internal trusted interface clients accessing local servers.

Why it fails: Proxy ARP is for external interfaces, not internal trusted clients.

[edit system traceoptions screen]

Why it fails: SCREEN traceoptions are configured under [edit security traceoptions], not the system hierarchy, so this path does not exist. It tempts because system traceoptions genuinely host routing and interface daemon traces, which is where that stanza belongs for those processes.

[edit security flow traceoptions screen]

Why it fails: The security flow traceoptions stanza traces session and packet flow processing, not SCREEN attack detection. It tempts because flow tracing is the natural place to debug zone traffic, and would be correct for diagnosing session setup failures rather than SCREEN events.

[edit security zones security-zone screen traceoptions]

Why it fails: SCREEN traceoptions are configured under [edit security screen traceoptions], within the security hierarchy, not nested beneath a security zone. The zone path is tempting because zones hold many security settings. Zone-level configuration covers interfaces, screen profiles and policies, but traceoptions for SCREEN processing sit at the security level.