Fortinet NSE7_SOC_AR-7.6 Practice Test Questions and Exam Dumps Part14 Q261-280

View Full Fortinet NSE7_SOC_AR-7.6 Exam Dumps and Practice Test Dumps.


Q261. What is the MOST important reason to correlate a suspicious process execution with DNS activity during incident analysis?

  1. DNS events automatically prove malware execution
  2. Process events contain complete network payloads
  3. DNS correlation replaces endpoint evidence
  4. It can link a process to domains it attempted to resolve and reveal possible command-and-control behavior

Correct Answer: 4. It can link a process to domains it attempted to resolve and reveal possible command-and-control behavior

Explanation:

Correlating endpoint process activity with DNS events helps analysts connect execution on a host with external infrastructure the process may be trying to contact. For example, a newly observed executable resolving an unusual domain shortly after launch can provide stronger evidence than either event viewed alone. Analysts should also examine destination reputation, user context, network sessions, and similar activity on other systems. DNS evidence alone does not prove malware, but the relationship between execution and communications can reveal command-and-control, download, or exfiltration behavior that would otherwise be difficult to recognize.

Q262. A SOC analyst finds a security alert involving an account that was disabled two weeks earlier. What should be investigated FIRST?

  1. Whether the account was re-enabled, duplicated, or represented incorrectly in the event data
  2. Whether every active account should be disabled
  3. Whether the FortiSOAR queue contains too many records
  4. Whether event retention should be shortened

Correct Answer: 1. Whether the account was re-enabled, duplicated, or represented incorrectly in the event data

Explanation:

Activity associated with a supposedly disabled account is unusual and deserves validation. The analyst should verify the current directory status, determine whether the account was re-enabled legitimately or maliciously, check whether another identity has a similar name, and confirm that the event was parsed correctly. Historical or delayed events may also explain the observation. Immediate broad containment without validating identity context can disrupt operations unnecessarily. Identity status, account lifecycle, and event accuracy should therefore be checked before concluding that an attacker has bypassed account controls.

Q263. Why is detecting unusual use of remote administration protocols important in a SOC?

  1. Remote administration protocols are always malicious
  2. They cannot be logged
  3. Attackers may abuse legitimate remote-management services for lateral movement or control
  4. They automatically disable endpoint protection

Correct Answer: 3. Attackers may abuse legitimate remote-management services for lateral movement or control

Explanation:

Remote administration protocols are legitimate business tools, but adversaries can also abuse them after gaining credentials or privileged access. Suspicious use may include new source systems, unusual users, unexpected destinations, abnormal times, or activity followed by process execution and privilege changes. Analysts should compare the observed behavior with normal administrative patterns rather than treating all remote access as malicious. Contextual detection helps distinguish expected IT operations from attacker lateral movement. This is a good example of why SOC analysis focuses on behavior and relationships instead of relying only on individual tools or protocols.

Q264. What is the BEST reason to correlate vulnerability information with a FortiSIEM incident?

  1. Vulnerability data proves exploitation occurred
  2. It can show whether the affected asset has weaknesses relevant to the observed attack behavior
  3. It replaces network telemetry
  4. It automatically determines incident closure

Correct Answer: 2. It can show whether the affected asset has weaknesses relevant to the observed attack behavior

Explanation:

Vulnerability context can help analysts determine whether a suspicious event is technically plausible and potentially high risk. If an alert indicates exploitation of a service and the affected asset is known to have the relevant vulnerability, the incident may deserve faster investigation. However, vulnerability presence does not prove successful exploitation, and absence of a known vulnerability does not eliminate all risk. Analysts should combine vulnerability context with event evidence, endpoint behavior, network activity, and asset importance. Enrichment is most useful when it strengthens analysis rather than replacing it.

Q265. A FortiSIEM incident rule should detect a single user authenticating from more than five different source hosts in ten minutes. What rule logic is MOST suitable?

  1. Group authentication events by user and count distinct source hosts within the time window
  2. Group events only by destination port
  3. Trigger on every successful login
  4. Count all users together

Correct Answer: 1. Group authentication events by user and count distinct source hosts within the time window

Explanation:

The behavior being modeled is one account appearing across an unusual number of source systems during a short interval. The rule should group by username, count unique source hosts, and apply the ten-minute correlation window. This helps detect possible credential misuse or automated account activity while avoiding irrelevant aggregation across unrelated users. A simple event count would not answer how many distinct sources are involved. Effective FortiSIEM correlation rules should reflect the exact entity relationship and temporal behavior the SOC wants to detect.

Q266. Why should detection-rule exceptions be documented?

  1. To make the rule impossible to change later
  2. To ensure every analyst ignores the excluded behavior
  3. To remove the need for testing
  4. To preserve the reason, scope, and business justification for suppressing specific activity

Correct Answer: 4. To preserve the reason, scope, and business justification for suppressing specific activity

Explanation:

Exceptions can be necessary for approved scanners, service accounts, maintenance jobs, or other known benign behavior. Without documentation, future engineers may not understand why an exclusion exists or whether it is still appropriate. Clear records should explain what is excluded, why it is safe, who approved it, and what conditions make the exception valid. Periodic review can then determine whether the exception remains necessary. Poorly documented exceptions can become permanent blind spots, especially when systems or business processes change over time.

Q267. A FortiSIEM query should identify events where a specific user accessed either Server-A or Server-B. Which logic is MOST appropriate?

  1. User condition OR server condition only
  2. User condition AND (Server-A OR Server-B)
  3. NOT user condition
  4. Server-A AND Server-B simultaneously

Correct Answer: 2. User condition AND (Server-A OR Server-B)

Explanation:

The investigation requires two conditions: the event must involve the specified user, and the destination must be either Server-A or Server-B. Boolean grouping is important because incorrect logic can broaden or narrow a search unintentionally. Using AND between the user condition and a grouped OR expression for the two servers produces the intended result. Without correct grouping, the query might return unrelated events from either server or from the user on other systems. Fortinet explicitly includes building FortiSIEM event-log queries in the current exam objectives.

Q268. Why might an analyst export selected FortiSIEM query results during an investigation?

  1. To delete them from FortiSIEM
  2. To stop future correlation
  3. To preserve or share a focused evidence set for deeper analysis, reporting, or collaboration
  4. To disable event normalization

Correct Answer: 3. To preserve or share a focused evidence set for deeper analysis, reporting, or collaboration

Explanation:

A focused export can help analysts preserve relevant evidence, share it with another response team, perform additional analysis, or include supporting data in an investigation report. The exported set should be selected carefully so it contains the information needed without exposing unnecessary sensitive data. Exporting results does not remove the original events or stop FortiSIEM correlation. It is simply one method of working with a curated subset of evidence outside the immediate query interface while maintaining the broader investigation context.

Q269. What is the MOST important reason to examine event frequency during incident analysis?

  1. Frequency can reveal bursts, repetition, periodic behavior, or other patterns that may indicate automation or attacker activity
  2. Higher frequency always means higher severity
  3. Event frequency determines analyst permissions
  4. Low-frequency events can never be malicious

Correct Answer: 4. Frequency can reveal bursts, repetition, periodic behavior, or other patterns that may indicate automation or attacker activity

Explanation:

The timing and frequency of events can expose behavior that individual records do not reveal. Repeated authentication failures, regularly timed outbound connections, or rapid requests across many hosts can indicate automated attacker activity, malware beaconing, or scanning. However, frequency alone does not establish severity because legitimate jobs and applications can generate repetitive events. Analysts should combine frequency with entity relationships, timing intervals, asset context, and other evidence. Pattern analysis is especially useful when trying to distinguish isolated activity from a coordinated or automated sequence.

Q270. A threat hunter finds outbound connections occurring every five minutes from one endpoint. What is the BEST next step?

  1. Investigate the responsible process, destinations, timing consistency, and whether the pattern resembles legitimate scheduled activity or beaconing
  2. Immediately wipe the endpoint
  3. Ignore the pattern because traffic is periodic
  4. Disable all network monitoring

Correct Answer: 1. Investigate the responsible process, destinations, timing consistency, and whether the pattern resembles legitimate scheduled activity or beaconing

Explanation:

Regularly timed outbound traffic can indicate malware beaconing, but many legitimate services also communicate on schedules. The hunter should identify the process or application generating the connections, inspect the destination infrastructure, compare the behavior with historical activity, and determine whether other endpoints exhibit the same pattern. Context is essential before deciding whether containment is warranted. A periodic pattern is a useful hypothesis lead rather than proof. Threat hunting should use available evidence to distinguish automated legitimate services from adversary command-and-control behavior.

Q271. Why should threat hunters include known-good behavior in their analysis when possible?

  1. Known-good behavior can provide a comparison baseline that makes suspicious deviations easier to recognize
  2. Known-good activity should be deleted from telemetry
  3. Legitimate activity can never resemble attacks
  4. Baselines eliminate the need for hypotheses

Correct Answer: 2. Known-good behavior can provide a comparison baseline that makes suspicious deviations easier to recognize

Explanation:

Understanding legitimate behavior helps analysts interpret anomalies. For example, knowing which systems normally run administrative tools, which countries a user typically authenticates from, or which domains an application usually contacts can make deviations more meaningful. A baseline does not prove that deviations are malicious, and attackers may attempt to imitate normal behavior. Still, comparison with known-good patterns can reduce noise and improve hunting efficiency. Threat hunting remains hypothesis-driven and should combine baselines with current event evidence and threat context.

Q272. A threat hunt reveals repeated suspicious behavior across several hosts but no FortiSIEM incident was generated. What should the SOC consider?

  1. The behavior must be benign because no incident exists
  2. FortiSOAR should be disabled
  3. Whether a detection gap exists and a new or modified FortiSIEM rule is warranted
  4. Deleting the hunt results

Correct Answer: 3. Whether a detection gap exists and a new or modified FortiSIEM rule is warranted

Explanation:

Threat hunting often discovers behaviors that existing detection logic does not identify. If the behavior is consistently malicious or strongly suspicious and can be represented using available telemetry, the SOC should evaluate whether a new rule or modification to an existing rule can detect it automatically. This converts manual discovery into repeatable coverage. The rule still requires testing and tuning before broad deployment. Fortinet’s official exam covers both threat-hunting analysis and FortiSIEM rule configuration, making this feedback loop between hunting and detection especially relevant.

Q273. Why is incident ownership important when several FortiSOAR analysts collaborate on the same case?

  1. It establishes one accountable person or role for ensuring the case continues to progress
  2. Ownership prevents anyone else from contributing
  3. Ownership automatically determines technical root cause
  4. It disables war-room collaboration

Correct Answer: 2. It establishes one accountable person or role for ensuring the case continues to progress

Explanation:

Collaboration can involve many responders, but clear ownership prevents the incident from becoming everyone’s responsibility and therefore no one’s responsibility. The owner helps coordinate tasks, monitor pending actions, escalate blockers, and ensure investigation and response continue. Other analysts can still contribute through tasks, notes, war rooms, and playbooks. Ownership may also transfer as the incident moves between teams or shifts. Effective case management combines shared collaboration with clear accountability for overall progress.

Q274. What is the BEST reason to use an approval task before restoring a quarantined production server?

  1. To ensure the appropriate responder confirms remediation and business readiness before recovery
  2. To make the incident longer unnecessarily
  3. To stop all automated recovery permanently
  4. To remove evidence from the case

Correct Answer: 1. To ensure the appropriate responder confirms remediation and business readiness before recovery

Explanation:

Returning a critical system to production can create risk if malware, persistence, or vulnerabilities remain. An approval task allows a responder or system owner to confirm that eradication steps are complete, required validation has succeeded, and business dependencies are ready. The approval creates a documented control point in the recovery process. Fortinet’s Security Operations Architect training specifically includes releasing compromised hosts from quarantine after recovery, making controlled validation an important response concept.

Q275. A playbook receives an incident with no indicators. What is the BEST design if enrichment actions require indicators?

  1. Attempt every enrichment action anyway
  2. Validate that indicators exist and route the workflow appropriately when they are absent
  3. Delete the incident
  4. Generate random indicators

Correct Answer: 4. Validate that indicators exist and route the workflow appropriately when they are absent

Explanation:

Playbooks should validate required data before calling external services. If no indicator exists, enrichment actions that require an IP address, domain, URL, or hash cannot produce a meaningful result. The workflow should detect the missing data and either skip those steps, create an analyst task, or follow another appropriate branch. Generating meaningless values or repeatedly calling connectors would create errors and wasted API usage. Robust playbooks are designed around the actual data available at runtime rather than assuming every incident has the same structure.

Q276. Why might a playbook transform a connector response before storing it in an incident field?

  1. To normalize or simplify the data into a format that is useful for analysts and later playbook logic
  2. To increase the connector’s administrative privileges
  3. To bypass authentication
  4. To change FortiSIEM event timestamps

Correct Answer: 1. To normalize or simplify the data into a format that is useful for analysts and later playbook logic

Explanation:

Connector responses can contain deeply nested structures, lists, technical metadata, or fields that are irrelevant to the incident. A Jinja transformation can extract the useful value, normalize it, and store only what later conditions or analysts need. This improves readability and reduces the complexity of downstream steps. Data manipulation does not change connector permissions or bypass security. Fortinet explicitly includes manipulating data using Jinja filters as part of the current SOAR Playbook Development exam domain.

Q277. A playbook calls the same containment connector action twice because of duplicate indicators. What is the BEST improvement?

  1. Increase connector privileges
  2. Normalize and deduplicate indicators before executing containment actions
  3. Disable all playbook history
  4. Create additional duplicate records

Correct Answer: 2. Normalize and deduplicate indicators before executing containment actions

Explanation:

Duplicate inputs can cause repeated API calls, unnecessary errors, or confusing execution history. Before enrichment or containment, the workflow can normalize values and reduce them to a unique set. This is especially important for high-impact actions such as firewall blocks, account changes, or endpoint isolation. Jinja filters can help transform and deduplicate collections where appropriate. The playbook should also be designed so repeating a containment action does not create unintended consequences. Data hygiene improves both efficiency and reliability.

Q278. A connector action fails only in production but works in a test environment. What should be compared FIRST?

  1. Analyst names
  2. Incident titles
  3. Endpoint URL, network access, credentials, permissions, and production-specific configuration
  4. FortiSIEM retention periods

Correct Answer: 3. Endpoint URL, network access, credentials, permissions, and production-specific configuration

Explanation:

A connector can behave differently across environments because production may use different API endpoints, firewall paths, proxies, credentials, permissions, certificates, or service versions. Comparing these dependencies helps isolate why the same action succeeds in testing but fails in production. The administrator should also inspect the exact error and runtime parameters. Analyst names and incident titles are generally irrelevant. Fortinet explicitly tests connector configuration and FortiSOAR playbook troubleshooting, so distinguishing environment-specific integration issues is an important skill.

Q279. Why should a playbook stop or branch safely after a critical containment action fails?

  1. Later steps may incorrectly assume the threat has been contained when it has not
  2. Every later step is always dangerous
  3. Failure automatically closes the incident
  4. The connector should never be retried

Correct Answer: 4. Later steps may incorrectly assume the threat has been contained when it has not

Explanation:

Workflow steps often depend on previous actions succeeding. If a host-isolation or account-disable action fails, later steps should not automatically proceed as though containment were complete. The playbook may need to stop, retry, notify an analyst, or create a manual task. Otherwise, the incident record could incorrectly state that the threat is controlled while the attacker still has access. Designing dependencies and failure branches explicitly is a key part of safe SOAR automation and playbook troubleshooting.

Q280. What is the BEST reason to periodically review automation permissions granted to FortiSOAR connectors?

  1. To ensure permissions still match current workflow requirements and least-privilege principles
  2. To maximize administrative access for every integration
  3. To avoid testing playbooks
  4. To increase FortiSIEM event volume

Correct Answer: 3. To ensure permissions still match current workflow requirements and least-privilege principles

Explanation:

Connector roles can accumulate unnecessary privileges as workflows evolve. Periodic access reviews help confirm that each integration still needs the permissions it has and that obsolete capabilities are removed. This limits potential impact if credentials are exposed or a playbook behaves incorrectly. High-impact actions should be available only to connectors that genuinely require them. Permission review complements secure credential storage, monitoring, rotation, and change control. A SOAR platform should have enough authority to perform its approved tasks but no more than necessary.