JN0-336 Security, Specialist (JNCIS-SEC) Questions and Answers

The correct answers are A and B. In Security Director-managed environments, Security Director can download the signature database and then install the active signature database update on selected managed devices. Juniper’s Security Director workflow states that after the signature database is downloaded, you install the active database, select the target devices, and Security Director sends the full or incremental signature database update to those devices. That confirms that Security Director stores and manages the signature database package centrally for deployment.

Option B is also correct because the SRX Series device must have the application signature database installed locally for AppID/AppSecure features such as AppFW, AppTrack, AppQoS, and IDP application matching. Juniper’s AppID documentation states that the application package is installed in the application signature database on the device, and that AppID signature updates enable AppSecure features on the SRX.

Option C is wrong because Juniper provides and maintains the predefined AppID database through Juniper’s security download infrastructure, not a third-party host. Juniper explicitly describes the predefined application identification database as provided by Juniper Networks and updated through a subscription service. Option D is wrong because a local storage server can be used only as part of an offline/manual update workflow; it is not where the AppID database normally resides. Reference topics: Security Director, AppID database, application signatures, SRX AppSecure services, signature database installation.

The correct answers are B and C. Adaptive Threat Profiling allows SRX Series Firewalls to act either as inline enforcement devices or as tap-based sensors. In an inline deployment, the SRX is directly in the traffic path and can enforce policy actions such as blocking, denying, or adding threat indicators to Security Intelligence feeds for real-time mitigation. In a tap deployment, the SRX observes copied traffic from a TAP/SPAN-style feed and contributes intelligence without being the active forwarding device. Juniper’s ATP Cloud documentation states that Adaptive Threat Profiling enables SRX devices to be deployed as sensors on Tap ports, identifying and sharing intelligence to inline devices for real-time enforcement. It also describes a “Tap-based SRX Series Firewall sensor” and contrasts it with an inline device.

Option A, bridge, is not the deployment mode being tested here. Bridge/transparent forwarding is a firewall deployment style, not the named Adaptive Threat Profiling mode. Option D, promiscuous, is also wrong; promiscuous mode is an interface behavior, not the ATP Adaptive Threat Profiling deployment model. Reference topics: ATP Cloud, Adaptive Threat Profiling, tap sensors, inline enforcement, Security Intelligence feeds.

The correct answer is B. count. In Junos security policy configuration, count is the policy parameter used for accounting and tabular operational visibility. Juniper’s security policy configuration rules state that accounting and auditing elements can be specified with count and log, while logging itself is enabled at either session-init or session-close.

The operational result is visible through commands such as show security policies hit-count, which displays a table of policy hit counters, including fields such as index, from-zone, to-zone, policy name, policy count, and action. Juniper defines this command as displaying the number of times a security policy rule matches traffic, and the sample output is explicitly tabular. Option A, permit, is an action, not a counter or logging/accounting parameter. Option C, session-init, logs at the beginning of a session, and option D, session-close, logs at session teardown. Those two parameters generate logs, but they do not provide the tabular policy-count view being asked about. Reference topics: security policy accounting, count parameter, hit-count, operational-mode policy monitoring, session-init/session-close logging.

The correct answer is B. ESP. In IPsec, the security protocol responsible for encrypting protected traffic is Encapsulating Security Payload (ESP). Juniper defines ESP as the IPsec protocol used for encrypting the IP packet and authenticating its contents. In practical SRX VPN design, ESP is the normal protocol selected when confidentiality is required because it can provide encryption, packet integrity, authentication, and anti-replay protection depending on the configured IPsec proposal.

Option A, SHA-1, is incorrect because SHA-1 is an authentication/hash algorithm, not an IPsec security protocol and not a payload encryption mechanism. Option C, AH, is incorrect because Authentication Header validates packet source and integrity but does not encrypt payload data. AH is therefore unsuitable when the requirement explicitly says payload data must be encrypted. Option D, PFS, is incorrect because Perfect Forward Secrecy is a key-exchange property used during Phase 2 rekeying; it strengthens key independence but does not itself encrypt packets. In Junos IPsec configuration logic, the security protocol decision is between ESP and AH, and encryption requires ESP. Reference topics: IPsec VPN, ESP, AH, IPsec security protocols, payload confidentiality, IPsec proposal design.

The correct answer is B. LDAP. In Juniper identity-aware firewall deployments, the SRX Series Firewall integrates with Microsoft Active Directory so that user and group information can be used in security policy decisions. Juniper’s Active Directory identity-source documentation states that the LDAP protocol helps identify the groups to which users belong, and that username and group information are queried from the LDAP service running on the Active Directory domain controller. It also explains that the device uses Lightweight Directory Access Protocol to obtain user and group information required for Active Directory identity-source operation.

Option A, SSH, is wrong because SSH is a device management protocol, not the protocol SRX uses to query Active Directory user/group membership. Option C, DNS, is wrong because DNS can resolve names but does not provide Active Directory group mapping to the firewall. Option D, NETCONF, is wrong because NETCONF is used for network device configuration and automation, not Windows domain-controller identity queries. In a complete identity-aware firewall workflow, SRX may also use WMI/DCOM-related mechanisms to read Windows event-log data, but among the available protocol choices, LDAP is the correct answer because it is the directory protocol used to query user and group information. Reference topics: Active Directory identity source, LDAP, domain controller communication, user and group mapping.

The correct answer is C. device policy rules. In Junos Space Security Director, policy scope matters. A rule intended for one specific SRX Series device must be placed in a device policy, because Juniper defines a device policy as a firewall policy created per device and used when you want to push a unique firewall policy configuration per device. Security Director also distinguishes this from group policies, which are shared with multiple devices, and from all-devices policy rules, which are global in scope rather than device-specific.

Option A is wrong because all-devices prerules are global rules evaluated before device-specific rules; they are not intended for a unique single-device exception. Option B is wrong because group policy prerules apply to devices within a group, not to one individually targeted SRX firewall. Option D is wrong because all-devices postrules are still globally scoped, even though they occur later in policy order. The clean Security Director design is to use device policy rules when the policy must apply only to one SRX device. Reference topics: Security Director, firewall policy hierarchy, device policy, group policy, all-devices prerules/postrules.

The correct answers are C and D. Once the SSL proxy profile already exists, the SRX still needs a security policy that matches the SSL/TLS traffic and applies the SSL proxy profile as an application service. Juniper’s SSL proxy configuration procedure explicitly shows creating the security policy match criteria and then applying the SSL proxy profile with then permit application-services ssl-proxy profile-name. It also states that SSL forward and reverse proxy require the profile to be configured at the firewall rule level.

Option D is correct because SSL proxy is not an end goal by itself; it decrypts SSL/TLS traffic so Layer 7 security services can inspect it. Juniper states that decrypted SSL traffic is available for security services and provides examples where the SSL proxy profile and a Content Security/UTM policy are both attached to the same security policy. Option A is wrong because host-inbound-traffic HTTPS controls HTTPS access to the SRX itself, not transit SSL proxy inspection. Option B is wrong because SSL proxy profiles are not referenced under a security zone for this function; they are applied under the matching security policy. Reference topics: SSL Proxy, SSL proxy profile, security policy application-services, Layer 7 inspection, UTM/IDP/ATP integration.

The correct answers are A and D. Juniper documentation describes domain PC probing as a supplement to event-log reading. When a user logs in to the domain, the domain controller event log normally provides the user-to-IP mapping. If that IP address-to-username mapping is not available from the event log, JIMS initiates a domain PC probe to the endpoint to obtain the active username and domain. JIMS can also use probes to determine a device’s status after the logged-in state expires, so the operational idea is not blind periodic probing; it is used to resolve or validate identity state when normal event-log information is missing or stale.

Option D is correct because the result of identity collection is reported back to SRX Series devices. JIMS generates reports containing IP address, username, and group relationship information, keeps a list of reports communicated to SRX devices, and sends those reports so SRX devices can create authentication-table entries for identity-aware policy enforcement. Options B and C are wrong because the tested PC-probe behavior is not “every 30 seconds” or “every 60 seconds.” Those values confuse PC probing with other timers or query intervals. Reference topics: JIMS, domain PC probing, event-log identity mapping, SRX authentication table, identity-aware security policies.

The correct answers are A and D. Juniper provides predefined IDP policy templates to simplify IDP deployment. These templates are supplied by Juniper Networks and include common templates such as client protection, server protection, DMZ services, DNS server, file server, web server, IDP default, and recommended policies. Juniper’s IDP documentation states that predefined templates are available from a secured Juniper Networks website, and the listed templates are explicitly described as being provided by Juniper Networks.

Option D is correct because these templates are not automatically present as usable policies in a factory-default SRX configuration. Juniper’s procedure says that to use predefined IDP policy templates, you download the policy templates and then install them. The CLI process includes request security idp security-package download policy-templates followed by request security idp security-package install policy-templates; committing then makes them available under the IDP policy hierarchy.

Option B is wrong because Juniper specifically says you should customize these templates for your network and recommends using a copied template so you can safely make changes. Option C is wrong because they must be downloaded and installed, so they are not simply available in the factory-default configuration. Reference topics: IDP, predefined IDP policy templates, security-package download, security-package install, active IDP policy.

The correct answers are A, C, and E. Junos Space Security Director supports policy hierarchy and policy management at device, group, and global/all-devices levels. A device policy is created for a specific device and is used when a unique firewall policy must be pushed to one SRX Series Firewall. A group policy is shared across multiple devices and is used when the same policy configuration must be applied consistently to a set of managed firewalls. Juniper’s Security Director documentation explicitly describes device policy and group policy behavior, including the fact that device-specific policies are evaluated within the broader policy-ordering model.

The third correct policy type is global, often represented in Security Director workflows as all-devices/global policy behavior. Juniper Security Director product material describes granular control over global, group, and device-level firewall policies, which maps directly to the options in this question. Option B, local, is not the Security Director policy type being tested; local configuration may exist on an SRX, but it is not one of the Security Director policy hierarchy types listed here. Option D, universal, is also not a Junos Space Security Director policy type. Reference topics: Security Director, global policy, group policy, device policy, firewall policy hierarchy, centralized SRX policy management.

The correct answers are A and B. The exhibit shows show chassis cluster statistics. Under Control link statistics, Control link 0 has heartbeat packets sent and received, with heartbeat packet errors: 0. That is the clearest indication that the control link is operating normally. Juniper describes chassis-cluster control-plane verification as checking control-link heartbeat packets sent and received, along with heartbeat errors. If both send and receive counters are incrementing and errors are zero, the control link is functioning.

Option A is also correct because under Fabric link statistics, Child link 0 shows probes sent and probes received. Juniper uses fabric-link probe counters to verify fabric-link operation; nonzero sent and received probe counters indicate that the link is participating in fabric monitoring. Option C is not the safest conclusion from this exhibit alone. Child link 1 shows zero probes sent and received, but the output does not prove that a second fabric child link is configured and failing; it could simply be unused or not configured in this deployment. Option D is directly contradicted by the healthy heartbeat counters. Reference topics: HA Clustering, chassis cluster statistics, control-link heartbeat, fabric-link probes, cluster health verification.

The correct answers are C and D. The exhibit shows ESP encrypted bytes = 0, ESP decrypted bytes = 0, encrypted packets = 0, and decrypted packets = 0. That means no traffic is successfully passing through the IPsec tunnel. Juniper’s show security ipsec statistics command displays ESP encrypted/decrypted packet and byte counters, so zero values on these counters indicate that the tunnel is not successfully carrying protected ESP traffic.

Option C is also correct because the output shows ESP authentication failures and ESP decryption failures. Since ESP is the IPsec protocol responsible for encrypted payload handling, failures in ESP authentication/decryption point to an ESP/IPsec Phase 2 mismatch or incorrect configuration, such as mismatched authentication algorithm, encryption algorithm, keys, proposal parameters, or incompatible negotiated SA settings. Juniper’s IPsec overview explains that Phase 2 negotiates the IPsec SA used to authenticate traffic flowing through the tunnel, so ESP-related failures belong to the IPsec/ESP configuration path rather than AH.

Option A is wrong because the AH counters and AH authentication failures are zero; the evidence is not pointing to AH. Option B is unsupported because the output does not show peer reboot behavior. Reference topics: IPsec VPN, ESP statistics, Phase 2/IPsec SA negotiation, ESP authentication failures, ESP decryption failures.

The correct answer is A. Manually configure and apply an SSL proxy profile. HTTPS traffic is encrypted, so ATP Cloud cannot extract and submit downloaded files for malware analysis unless the SRX can decrypt the SSL/TLS session first. Juniper’s ATP Cloud documentation states that to detect malware in HTTPS traffic, you must configure the SSL inspection CA used for SSL forward proxy, and the ATP Cloud policy workflow specifically includes configuring an SSL proxy profile to inspect HTTPS traffic. Juniper’s example shows the SSL proxy profile being created with a root CA and then applied so HTTPS sessions can be inspected before advanced anti-malware processing occurs.

Option B is wrong because lowering the threat score only changes the enforcement threshold after a file verdict is returned; it does not solve the inability to inspect encrypted payloads. Option C is wrong because changing the ATP device profile alone does not decrypt HTTPS traffic. The exhibit already shows a malware profile and HTTP file-download configuration, but HTTPS malware detection still requires SSL proxy. Option D is wrong because Junos ATP Cloud integration does not require redirecting encrypted traffic to a separate decryption appliance for this task. The SRX performs SSL forward proxy locally, then advanced anti-malware can inspect extracted content. Reference topics: ATP Cloud, HTTPS malware inspection, SSL forward proxy, SSL inspection CA, advanced anti-malware policy.

The correct answer is B. The IPsec VPN is established, and traffic is passing through . The exhibit shows nonzero ESP encrypted bytes , ESP decrypted bytes , encrypted packets , and decrypted packets . On an SRX Series Firewall, those counters indicate that the device is both encrypting outbound traffic into the IPsec tunnel and decrypting inbound ESP traffic from the remote peer. Juniper’s show security ipsec statistics reference identifies ESP statistics as the counters for encrypted/decrypted bytes and packets, and Juniper troubleshooting guidance states that incrementing encrypted and decrypted packet counters confirm traffic flow across the VPN.

Option A is wrong because the error counters show AH authentication failures: 0, Replay errors: 0, ESP authentication failures: 0, ESP decryption failures: 0, Bad headers: 0, and Bad trailers: 0. Option C is wrong because encrypted and decrypted ESP packet counters would not increment if the IPsec tunnel were not established. Option D is wrong because traffic is clearly passing; the nonzero ESP counters prove packet movement through the tunnel. Reference topics: IPsec VPN, ESP statistics, encrypted/decrypted counters, tunnel verification, IPsec troubleshooting.

The correct answers are B and D. On SRX Series Firewalls, SSL proxy is configured by creating an SSL proxy profile and then applying that profile to the relevant security policy as an application service. Juniper’s SSL proxy configuration overview lists the required workflow: configure certificates and CA profile material, configure the SSL proxy profile, create a security policy matching the traffic to be inspected, and apply the SSL proxy profile to that security policy. Juniper further states that SSL proxy is enabled as an application service within a security policy, where the policy match criteria identify the traffic and the SSL proxy profile is applied to that traffic.

Option A is wrong because enabling the SSL ALG is not the required control point for SSL proxy. SSL proxy is a decryption/inspection service applied through policy, not simply an ALG toggle. Option C is wrong because creating a separate SSL application object is not the mandatory SSL proxy configuration action. The policy can match the desired traffic and then invoke SSL proxy through then permit application-services ssl-proxy profile-name. Juniper’s example explicitly shows applying the SSL proxy profile under the security policy action.

Reference topics: SSL Proxy, SSL forward proxy, SSL proxy profiles, security policy application-services, encrypted traffic inspection.

The correct answers are A and C. Juniper ATP Cloud uses a malware-analysis pipeline. When a file is submitted, the first step is a cache lookup based on the file hash. Juniper explains that if the file has already been analyzed, the stored verdict is returned to the SRX Series Firewall and there is no need to re-analyze the file. That directly supports C and eliminates B, because analysis does not continue when a cached verdict is found.

If the cache lookup does not return a verdict, the remaining ATP Cloud analysis techniques are used. Juniper describes the pipeline model in which each analysis technique creates a verdict number, and those verdicts are combined into a final verdict score from 0 to 10. That final threat score is what the SRX compares against ATP Cloud policy settings to permit or block the session.

Option D is wrong because ATP Cloud does not simply return the first score generated by any one feature. The expected behavior is cumulative/final scoring across the remaining analysis pipeline. Reference topics: Juniper ATP Cloud, malware analysis pipeline, cache lookup, verdict number, threat score, SRX enforcement.

The correct answers are B and C. In Junos route-based IPsec VPNs, the default proxy ID is broad: local 0.0.0.0/0, remote 0.0.0.0/0, and service any. This default behavior allows routed traffic entering the secure tunnel interface to determine what is protected by the VPN rather than requiring a narrow policy-based encryption domain. Juniper’s IPsec VPN configuration guidance also states that proxy IDs are used in Phase 2 negotiations, and that a proxy ID mismatch is one of the common causes of Phase 2 failure. For interoperability with some third-party VPN peers, Juniper notes that proxy IDs may need to be manually configured to match the peer.

Option A is wrong because proxy IDs can override default route-based behavior when manually configured, especially when a peer requires specific local and remote protected subnets. Option D is wrong because proxy IDs are not created during IKE Phase 1. Phase 1 builds the secure IKE channel; proxy IDs belong to Phase 2/IPsec SA negotiation, where the peers agree on traffic selectors for encrypted traffic. Reference topics: IPsec VPN, route-based VPNs, proxy IDs, Phase 2 negotiation, traffic selectors, third-party VPN interoperability.