{"id":20324,"date":"2026-09-23T12:33:45","date_gmt":"2026-09-23T12:33:45","guid":{"rendered":"https:\/\/www.examlabs.com\/certification\/?p=20324"},"modified":"2026-09-23T12:33:45","modified_gmt":"2026-09-23T12:33:45","slug":"fortinet-nse7_soc_ar-7-6-practice-test-questions-and-exam-dumps-part19-q361-380","status":"publish","type":"post","link":"https:\/\/www.examlabs.com\/certification\/fortinet-nse7_soc_ar-7-6-practice-test-questions-and-exam-dumps-part19-q361-380\/","title":{"rendered":"Fortinet NSE7_SOC_AR-7.6 Practice Test Questions and Exam Dumps Part19 Q361-380"},"content":{"rendered":"

View Full <\/b>Fortinet NSE7_SOC_AR-7.6 Exam Dumps<\/b><\/a> and Practice Test Dumps.<\/b><\/p>\n


\n<\/b>Q361. Why should a SOC correlate a newly created privileged account with subsequent authentication activity?<\/b><\/p>\n

    \n
  1. <\/b> It can reveal whether the new account was immediately used in a way consistent with persistence or unauthorized access<\/span><\/li>\n
  2. <\/b> Newly created accounts are always malicious<\/span><\/li>\n
  3. <\/b> Authentication events become irrelevant after account creation<\/span><\/li>\n
  4. <\/b> Account creation automatically proves privilege escalation<\/span><\/li>\n<\/ol>\n

    Correct Answer: 1. It can reveal whether the new account was immediately used in a way consistent with persistence or unauthorized access<\/b><\/p>\n

    Explanation:<\/b><\/p>\n

    Creation of a privileged account can be legitimate administrative activity, but attackers may also create accounts to maintain persistence or obtain durable access. Analysts should therefore correlate account-creation events with the creator identity, source host, privilege assignments, subsequent logins, remote access, and other related actions. If the account appears without an approved change and is quickly used across sensitive systems, the behavior becomes more suspicious. Account creation alone is not proof of compromise. The investigation should combine identity, endpoint, and network evidence to determine whether the new account belongs to authorized administration or adversary activity.<\/span><\/p>\n

    Q362. What is the BEST reason to compare a suspicious security event with an organization\u2019s approved change window?<\/b><\/p>\n

      \n
    1. <\/b> All activity during a change window is automatically trusted<\/span><\/li>\n
    2. <\/b> Change windows make SIEM rules unnecessary<\/span><\/li>\n
    3. <\/b> Approved changes may explain unusual administrative behavior that would otherwise appear suspicious<\/span><\/li>\n
    4. <\/b> Security monitoring should stop during maintenance<\/span><\/li>\n<\/ol>\n

      Correct Answer: 3. Approved changes may explain unusual administrative behavior that would otherwise appear suspicious<\/b><\/p>\n

      Explanation:<\/b><\/p>\n

      Maintenance activities can generate unusual process execution, service restarts, configuration changes, privileged logins, and network connections. Comparing suspicious activity with approved change records can help analysts determine whether the event has a legitimate operational explanation. However, a maintenance window should not become a blanket exemption because adversaries can also operate during those periods. Analysts should verify the identities, systems, timing, and exact actions against the approved change. Change context improves triage accuracy while preserving the need for security validation and evidence-based conclusions.<\/span><\/p>\n

      Q363. A FortiSIEM rule should detect when one workstation attempts to access many internal TCP ports on a single server in a short time. What behavior is the rule MOST likely designed to identify?<\/b><\/p>\n

        \n
      1. <\/b> Normal DNS resolution<\/span><\/li>\n
      2. <\/b> Port scanning or service discovery<\/span><\/li>\n
      3. <\/b> User password expiration<\/span><\/li>\n
      4. <\/b> Email delivery<\/span><\/li>\n<\/ol>\n

        Correct Answer: 2. Port scanning or service discovery<\/b><\/p>\n

        Explanation:<\/b><\/p>\n

        Rapid attempts to connect to many different ports on one target can indicate scanning or service discovery. An attacker may perform this activity to identify exposed services before attempting exploitation or lateral movement. A suitable FortiSIEM rule could group events by source and destination, count distinct destination ports, and apply an appropriate time window. Legitimate vulnerability scanners or administration tools may produce similar behavior, so asset context and approved scanner exclusions are important. The rule should detect the pattern without automatically assuming that every multi-port connection sequence is malicious.<\/span><\/p>\n

        Q364. Why should FortiSIEM rule thresholds be tested against normal enterprise activity before production deployment?<\/b><\/p>\n

          \n
        1. <\/b> Thresholds automatically determine asset criticality<\/span><\/li>\n
        2. <\/b> Testing guarantees zero false negatives<\/span><\/li>\n
        3. <\/b> Testing removes the need for future tuning<\/span><\/li>\n
        4. <\/b> It helps determine whether the threshold distinguishes suspicious behavior from normal operational volume<\/span><\/li>\n<\/ol>\n

          Correct Answer: 4. It helps determine whether the threshold distinguishes suspicious behavior from normal operational volume<\/b><\/p>\n

          Explanation:<\/b><\/p>\n

          A threshold that appears reasonable in theory may generate excessive incidents or miss meaningful activity when applied to real organizational data. Historical testing helps engineers understand typical event rates, business processes, service accounts, and burst patterns before enabling the rule broadly. The threshold can then be adjusted to improve signal quality while preserving useful detection. No amount of testing guarantees perfect future performance because environments and threats evolve. Detection rules should therefore be monitored and tuned after deployment as additional true-positive and false-positive evidence becomes available.<\/span><\/p>\n

          Q365. What is the BEST reason to use asset tags, groups, or classifications in FortiSIEM queries?<\/b><\/p>\n

            \n
          1. <\/b> They can restrict or organize searches according to meaningful business or technical asset categories<\/span><\/li>\n
          2. <\/b> They automatically patch vulnerable systems<\/span><\/li>\n
          3. <\/b> They increase network bandwidth<\/span><\/li>\n
          4. <\/b> They replace all event fields<\/span><\/li>\n<\/ol>\n

            Correct Answer: 1. They can restrict or organize searches according to meaningful business or technical asset categories<\/b><\/p>\n

            Explanation:<\/b><\/p>\n

            Asset groupings can make investigation queries more relevant. For example, an analyst might search only domain controllers, payment servers, cloud workloads, or executive systems instead of reviewing the entire environment. This reduces noise and helps connect technical events with business context. Asset classifications can also support detection rules and incident prioritization. They do not replace normalized event fields, and they do not directly change the assets themselves. Their value lies in giving FortiSIEM additional contextual information that analysts can use during searching, correlation, and incident analysis.<\/span><\/p>\n

            Q366. A FortiSIEM query returns no matching events after an analyst adds several filters at once. What is the BEST troubleshooting method?<\/b><\/p>\n

              \n
            1. <\/b> Delete the underlying logs<\/span><\/li>\n
            2. <\/b> Disable the data source<\/span><\/li>\n
            3. <\/b> Replace the search with a FortiSOAR playbook<\/span><\/li>\n
            4. <\/b> Remove or test filters incrementally to identify which condition is excluding the expected events<\/span><\/li>\n<\/ol>\n

              Correct Answer: 4. Remove or test filters incrementally to identify which condition is excluding the expected events<\/b><\/p>\n

              Explanation:<\/b><\/p>\n

              Complex query logic can fail because of one incorrect field, value, operator, time range, or Boolean grouping. Testing criteria incrementally helps isolate the condition that removes expected matches. Analysts can begin with a known broad search, confirm the events exist, and then add filters one at a time until the problem appears. This approach preserves evidence and avoids unnecessary changes to collection. Disabling data sources or deleting logs would reduce visibility. Methodical query troubleshooting is an important skill when investigating incidents in large FortiSIEM environments.<\/span><\/p>\n

              Q367. Why should an analyst examine process command-line arguments rather than only the process name?<\/b><\/p>\n

                \n
              1. <\/b> Command-line arguments always reveal the attacker\u2019s identity<\/span><\/li>\n
              2. <\/b> They can show how a legitimate executable is being used and reveal suspicious parameters or actions<\/span><\/li>\n
              3. <\/b> Process names are never useful<\/span><\/li>\n
              4. <\/b> Command lines automatically prove malware execution<\/span><\/li>\n<\/ol>\n

                Correct Answer: 2. They can show how a legitimate executable is being used and reveal suspicious parameters or actions<\/b><\/p>\n

                Explanation:<\/b><\/p>\n

                Attackers frequently abuse trusted system utilities, scripting engines, and administrative tools. The executable name may therefore look completely legitimate while the command-line parameters reveal credential dumping, encoded scripts, remote execution, suspicious downloads, or other risky behavior. Analysts should compare command lines with parent processes, user context, target systems, and network activity. Command-line analysis does not automatically prove malicious intent because administrators may use advanced parameters legitimately. Its value is in adding detail about what the process was instructed to do.<\/span><\/p>\n

                Q368. A threat hunt starts with a malicious domain and identifies several endpoints that contacted it. What is the BEST next pivot?<\/b><\/p>\n

                  \n
                1. <\/b> Close the hunt immediately<\/span><\/li>\n
                2. <\/b> Delete the domain from all events<\/span><\/li>\n
                3. <\/b> Examine the responsible processes, users, timing, and additional network activity on the identified endpoints<\/span><\/li>\n
                4. <\/b> Assume every endpoint is equally compromised<\/span><\/li>\n<\/ol>\n

                  Correct Answer: 3. Examine the responsible processes, users, timing, and additional network activity on the identified endpoints<\/b><\/p>\n

                  Explanation:<\/b><\/p>\n

                  The domain provides a useful starting indicator, but the hunter still needs to understand why each endpoint contacted it. Process execution can reveal which application initiated communication, while user context and timing can help determine whether the activity was expected. Additional network behavior may expose command-and-control, downloading, or lateral movement. Not every system contacting a malicious or compromised domain is necessarily fully compromised, so the hunt should pivot into local endpoint evidence. Threat hunting becomes stronger when indicators lead to behavioral analysis rather than automatic conclusions.<\/span><\/p>\n

                  Q369. What is the BEST reason to identify common characteristics across multiple successful threat hunts?<\/b><\/p>\n

                    \n
                  1. <\/b> Recurring patterns may reveal opportunities for new continuous detections or improved telemetry coverage<\/span><\/li>\n
                  2. <\/b> Every successful hunt should remain manual forever<\/span><\/li>\n
                  3. <\/b> Common characteristics should be removed from reports<\/span><\/li>\n
                  4. <\/b> Repeated findings prove existing detections are unnecessary<\/span><\/li>\n<\/ol>\n

                    Correct Answer: 4. Recurring patterns may reveal opportunities for new continuous detections or improved telemetry coverage<\/b><\/p>\n

                    Explanation:<\/b><\/p>\n

                    When separate threat hunts repeatedly identify similar attacker behavior, the SOC should consider whether that behavior can be converted into a reliable detection rule or whether additional telemetry would make detection easier. This feedback loop turns human discovery into scalable monitoring. The SOC should still validate the pattern carefully before production deployment to avoid excessive noise. Threat hunting does not replace continuous detection, and continuous detection does not eliminate the need for hunting. The two disciplines strengthen one another when findings are reviewed systematically.<\/span><\/p>\n

                    Q370. A hunt hypothesis focuses on suspicious account use outside normal working hours. What contextual information would MOST improve the analysis?<\/b><\/p>\n

                      \n
                    1. <\/b> Only the number of SIEM users<\/span><\/li>\n
                    2. <\/b> The user\u2019s normal schedule, role, historical login times, source devices, and current business context<\/span><\/li>\n
                    3. <\/b> The playbook connector version<\/span><\/li>\n
                    4. <\/b> The incident queue color<\/span><\/li>\n<\/ol>\n

                      Correct Answer: 2. The user\u2019s normal schedule, role, historical login times, source devices, and current business context<\/b><\/p>\n

                      Explanation:<\/b><\/p>\n

                      After-hours activity can be suspicious, but many legitimate users work remotely, travel, perform maintenance, or have irregular schedules. The hunter should compare current events with the user\u2019s normal behavior and business role, identify the source device and location, and determine whether approved work explains the activity. Historical authentication patterns provide a useful baseline. Context prevents the SOC from treating every after-hours login as malicious while still highlighting genuine deviations. Threat hunting should test behavior against evidence rather than rely on simplistic assumptions.<\/span><\/p>\n

                      Q371. Why is it useful to link an indicator record to the incidents in which it appears in FortiSOAR?<\/b><\/p>\n

                        \n
                      1. <\/b> It automatically blocks the indicator<\/span><\/li>\n
                      2. <\/b> It can show repeated sightings and help analysts understand the indicator\u2019s relationship across cases<\/span><\/li>\n
                      3. <\/b> It deletes duplicate incidents<\/span><\/li>\n
                      4. <\/b> It prevents enrichment<\/span><\/li>\n<\/ol>\n

                        Correct Answer: 2. It can show repeated sightings and help analysts understand the indicator\u2019s relationship across cases<\/b><\/p>\n

                        Explanation:<\/b><\/p>\n

                        An indicator can appear in multiple incidents over time. Linking it to related cases helps analysts see whether the value has been encountered previously, whether its reputation changed, and whether similar systems or users were involved. This shared context can reveal recurring campaigns or provide useful historical information during triage. Relationship management does not automatically make the indicator malicious or perform containment. Instead, it helps organize investigation data so analysts can understand how entities recur across the SOC\u2019s incident history.<\/span><\/p>\n

                        Q372. A critical incident remains unassigned because the primary analyst is unavailable. What should a well-designed FortiSOAR process do?<\/b><\/p>\n

                          \n
                        1. <\/b> Wait indefinitely for the primary analyst<\/span><\/li>\n
                        2. <\/b> Close the incident automatically<\/span><\/li>\n
                        3. <\/b> Route or escalate the incident to an available qualified analyst or queue according to shift and escalation rules<\/span><\/li>\n
                        4. <\/b> Delete all pending tasks<\/span><\/li>\n<\/ol>\n

                          Correct Answer: 3. Route or escalate the incident to an available qualified analyst or queue according to shift and escalation rules<\/b><\/p>\n

                          Explanation:<\/b><\/p>\n

                          High-priority cases should not depend on one specific person being available. FortiSOAR queues and shifts can help route work according to current staffing, while escalation rules can notify another analyst or team if a case remains unattended. This supports continuous SOC operation and reduces delays in containment. Closing or deleting the incident would hide unresolved risk. Fortinet explicitly includes creation of queues and shifts for workload management in the Security Operations Architect exam objectives. (<\/span>training.fortinet.com<\/span><\/a>)<\/span><\/p>\n

                          Q373. A playbook must request additional analyst input before proceeding because the incident lacks a required business-impact value. What is the BEST design?<\/b><\/p>\n

                            \n
                          1. <\/b> Create a task or manual-input step that gathers the missing value before dependent actions continue<\/span><\/li>\n
                          2. <\/b> Assume the highest possible impact<\/span><\/li>\n
                          3. <\/b> Close the incident<\/span><\/li>\n
                          4. <\/b> Ignore the missing value and execute every action<\/span><\/li>\n<\/ol>\n

                            Correct Answer: 4. Create a task or manual-input step that gathers the missing value before dependent actions continue<\/b><\/p>\n

                            Explanation:<\/b><\/p>\n

                            Automation should not invent business context when an important value is missing. A task or manual-input step allows the appropriate analyst or system owner to supply the information needed for a safe decision. The workflow can pause or follow a controlled branch until that value is available. This is particularly important when later actions could isolate critical systems or affect users. Hybrid automation lets FortiSOAR handle repeatable work while retaining human judgment where data cannot be derived reliably from technical sources.<\/span><\/p>\n

                            Q374. Why should a playbook validate an IP address before sending it to a firewall block action?<\/b><\/p>\n

                              \n
                            1. <\/b> To reduce the risk of malformed or unintended input causing an incorrect containment action<\/span><\/li>\n
                            2. <\/b> Validation increases the connector\u2019s permissions<\/span><\/li>\n
                            3. <\/b> Every incident field contains a valid IP automatically<\/span><\/li>\n
                            4. <\/b> Firewalls cannot process IP addresses<\/span><\/li>\n<\/ol>\n

                              Correct Answer: 1. To reduce the risk of malformed or unintended input causing an incorrect containment action<\/b><\/p>\n

                              Explanation:<\/b><\/p>\n

                              Containment actions should validate target data before modifying external security controls. A malformed value, blank field, internal address, or unexpected string could cause the connector to fail or potentially create an incorrect policy. Validation can check format, presence, address type, and other organization-specific criteria. High-impact automation benefits from additional safeguards such as asset checks or approval logic. Data validation does not change connector permissions; it ensures the workflow acts on the intended object with correctly formatted input.<\/span><\/p>\n

                              Q375. A connector returns a comma-separated string of indicators, but the next playbook stage expects a list. What should be used?<\/b><\/p>\n

                                \n
                              1. <\/b> A Jinja transformation that splits the string into a list using the expected delimiter<\/span><\/li>\n
                              2. <\/b> A new FortiSIEM incident rule<\/span><\/li>\n
                              3. <\/b> Analyst reassignment<\/span><\/li>\n
                              4. <\/b> A shift change<\/span><\/li>\n<\/ol>\n

                                Correct Answer: 3. A Jinja transformation that splits the string into a list using the expected delimiter<\/b><\/p>\n

                                Explanation:<\/b><\/p>\n

                                Playbook actions often exchange data in different formats. If one connector returns several indicators in a delimited string while the next stage expects a list, Jinja can split and normalize the value before downstream processing. The workflow should also consider trimming whitespace and removing empty or duplicate entries. Correct data transformation improves interoperability and reduces runtime errors. Fortinet explicitly includes manipulating data using Jinja filters in the current Security Operations Architect exam blueprint. (<\/span>training.fortinet.com<\/span><\/a>)<\/span><\/p>\n

                                Q376. Why should a playbook write a clear reason when it skips a containment action?<\/b><\/p>\n

                                  \n
                                1. <\/b> To provide audit context showing why automation deliberately chose not to act<\/span><\/li>\n
                                2. <\/b> To increase SIEM retention<\/span><\/li>\n
                                3. <\/b> To make connector failures invisible<\/span><\/li>\n
                                4. <\/b> To prevent human review<\/span><\/li>\n<\/ol>\n

                                  Correct Answer: 1. To provide audit context showing why automation deliberately chose not to act<\/b><\/p>\n

                                  Explanation:<\/b><\/p>\n

                                  A skipped action can be just as important as an executed one. If the playbook decides not to isolate a host because the asset is critical, the confidence score is low, or approval was denied, analysts should be able to understand that decision later. Recording the reason supports incident handoff, auditing, post-incident review, and troubleshooting. Without such context, someone may incorrectly assume containment was forgotten or failed. Transparent automation makes decisions visible instead of hiding the logic behind workflow branches.<\/span><\/p>\n

                                  Q377. A FortiSOAR connector occasionally returns success but with incomplete response data. What is the BEST playbook safeguard?<\/b><\/p>\n

                                    \n
                                  1. <\/b> Assume success means all expected data is present<\/span><\/li>\n
                                  2. <\/b> Validate required response fields before dependent steps use them<\/span><\/li>\n
                                  3. <\/b> Ignore the connector output entirely<\/span><\/li>\n
                                  4. <\/b> Automatically close the incident<\/span><\/li>\n<\/ol>\n

                                    Correct Answer: 4. Validate required response fields before dependent steps use them<\/b><\/p>\n

                                    Explanation:<\/b><\/p>\n

                                    An API can report request success while still omitting optional or expected data. If later playbook steps assume those fields exist, the workflow can fail or make incorrect decisions. The playbook should therefore validate required output fields and follow a safe branch if information is missing. Depending on the use case, it may retry, request analyst review, or continue with reduced functionality. Robust automation validates not only transport-level success but also whether the returned data is sufficient for the intended downstream operation.<\/span><\/p>\n

                                    Q378. A playbook behaves differently in production because an incident field has a different name than in the test environment. What should be improved?<\/b><\/p>\n

                                      \n
                                    1. <\/b> Environment-aware field mapping and controlled testing with production-equivalent schemas<\/span><\/li>\n
                                    2. <\/b> Connector privileges<\/span><\/li>\n
                                    3. <\/b> War-room membership<\/span><\/li>\n
                                    4. <\/b> Analyst shift duration<\/span><\/li>\n<\/ol>\n

                                      Correct Answer: 1. Environment-aware field mapping and controlled testing with production-equivalent schemas<\/b><\/p>\n

                                      Explanation:<\/b><\/p>\n

                                      Automation can fail when test and production environments use different field names, record schemas, connector versions, or configurations. Developers should validate mappings against the target environment and make environment-specific values configurable when appropriate. Testing should use data structures that closely resemble production before deployment. Connector privileges or workforce settings do not correct a field-name mismatch. This illustrates why end-to-end playbook testing is necessary even when individual logic works correctly in a development environment.<\/span><\/p>\n

                                      Q379. What is the BEST reason to test failure paths in addition to successful playbook execution?<\/b><\/p>\n

                                        \n
                                      1. <\/b> Real incidents can encounter missing data, connector outages, permission failures, and unexpected responses<\/span><\/li>\n
                                      2. <\/b> Failure testing guarantees external systems never fail<\/span><\/li>\n
                                      3. <\/b> Successful paths are irrelevant<\/span><\/li>\n
                                      4. <\/b> Failure paths should never reach analysts<\/span><\/li>\n<\/ol>\n

                                        Correct Answer: 3. Real incidents can encounter missing data, connector outages, permission failures, and unexpected responses<\/b><\/p>\n

                                        Explanation:<\/b><\/p>\n

                                        Production workflows rarely encounter only ideal inputs. Credentials expire, APIs return errors, fields may be missing, and external services can become unavailable. Testing failure paths verifies that the playbook reacts safely rather than continuing with invalid assumptions. Useful responses can include retries, tasks, analyst notifications, or stopping dependent actions. Success testing confirms expected functionality, while failure testing confirms resilience. Fortinet explicitly includes debugging and troubleshooting FortiSOAR playbooks in the current exam objectives.<\/span><\/p>\n

                                        Q380. After containment succeeds, what is the BEST reason to leave the incident open until eradication and recovery are validated?<\/b><\/p>\n

                                          \n
                                        1. <\/b> Containment limits immediate risk but does not prove the root cause, persistence, or malicious artifacts have been removed<\/span><\/li>\n
                                        2. <\/b> Incidents can never be closed after containment<\/span><\/li>\n
                                        3. <\/b> Recovery should always happen before eradication<\/span><\/li>\n
                                        4. <\/b> Containment deletes all evidence<\/span><\/li>\n<\/ol>\n

                                          Correct Answer: 2. Containment limits immediate risk but does not prove the root cause, persistence, or malicious artifacts have been removed<\/b><\/p>\n

                                          Explanation:<\/b><\/p>\n

                                          Containment is intended to stop or limit active attacker behavior, but the system may still contain malware, persistence mechanisms, compromised credentials, or vulnerable configurations. Responders should complete eradication, validate remediation, restore normal operations carefully, and monitor for recurrence before closing the case. Fortinet\u2019s Security Operations Architect training includes both eradication of malicious artifacts and release of compromised hosts from quarantine after recovery, reinforcing that containment is only one stage of the incident-response lifecycle.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

                                          View Full Fortinet NSE7_SOC_AR-7.6 Exam Dumps and Practice Test Dumps. Q361. Why should a SOC correlate a newly created privileged account with subsequent authentication activity? It can reveal whether the new account was immediately used in a way consistent with persistence or unauthorized access Newly created accounts are always malicious Authentication events become irrelevant after […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[1648,1647],"tags":[],"_links":{"self":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/20324"}],"collection":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/comments?post=20324"}],"version-history":[{"count":1,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/20324\/revisions"}],"predecessor-version":[{"id":20325,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/20324\/revisions\/20325"}],"wp:attachment":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/media?parent=20324"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/categories?post=20324"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/tags?post=20324"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}