Use the Jinja Editor to Troubleshoot Jinja Expressions NSE6-FORTISOAR-ANALYST Practice Questions (Page 1)

Questions 1–5

1. 1application · medium

   A playbook uses `{{ alert | selectattr('severity', 'equalto', 'High') | list | length }}` to count high-severity alerts. The output is `0` even though the alert list contains high-severity items. Which step should the analyst take to debug this in the Jinja editor?

   • AInspect the raw JSON of the alert list to confirm the field is named `severity` and the values are strings like 'High'.
   • BChange `equalto` to `==` in the expression.
   • CUse `alert | list | length` to check the total count of items in the list.
   • DReplace `selectattr` with `map(attribute='severity')` to extract the values first.
   Reveal Solution Discussion Select an answer first
2. 2application · medium

   An analyst is using the Jinja editor to test `{{ alert.created_at | datetimeformat('%Y-%m-%d') }}` but the output is the original string unchanged. The `created_at` field is a string like '2025-03-15T10:30:00Z'. What is the most likely reason the filter is not working?

   • AThe `datetimeformat` filter is not a built-in Jinja filter and must be provided by FortiSOAR's custom filter set.
   • BThe `%Y-%m-%d` format string is incorrect; it should be `%y-%m-%d` for a four-digit year.
   • CThe expression is missing a `|string` filter to ensure the output is a string.
   • DThe filter expects a datetime object, not a string, so the analyst must first convert the string using `|to_datetime`.
   Reveal Solution Discussion Select an answer first
4. 3expert · hard

   A playbook fails when processing an alert where `alert.attachments` is `None`. The expression `{{ alert.attachments | length }}` throws an error. The analyst needs a single expression that returns `0` when the field is `None` and the actual count otherwise. Which expression achieves this?

   • A`{{ alert.attachments or [] | length }}`
   • B`{{ alert.attachments | default([]) | length }}`
   • C`{{ alert.attachments | default(0) | length }}`
   • D`{{ alert.attachments | length if alert.attachments else 0 }}`
   Reveal Solution Discussion Select an answer first
5. 4application · easy

   An analyst is testing a Jinja expression in the editor: `{{ alert.severity | upper }}`. The output is `HIGH`, but the analyst expected `High`. What is the most likely reason for the unexpected output?

   • AThe analyst should use the `capitalize` filter instead to get `High`.
   • BThe expression is missing a `|lower` filter before `|upper`.
   • CThe `alert.severity` field is stored in uppercase, so the filter has no effect.
   • DThe `upper` filter converts the entire string to uppercase, which is its intended behavior.
   Reveal Solution Discussion Select an answer first
6. 5expert · hard

   An analyst is debugging a Jinja expression that fails only for certain alerts. The expression is `{{ alert.indicators | map(attribute='value') | join(', ') }}`. For most alerts, it works, but for one alert, it throws an error. The analyst inspects the alert and sees that `alert.indicators` is a list of dictionaries, but one dictionary is missing the `value` key. Which modification makes the expression resilient to missing keys?

   • A`{{ alert.indicators | map(attribute='value', default='') | join(', ') }}`
   • B`{{ alert.indicators | selectattr('value', 'defined') | map(attribute='value') | join(', ') }}`
   • C`{{ alert.indicators | map(attribute='value') | select('defined') | join(', ') }}`
   • D`{{ alert.indicators | map(attribute='value') | default('') | join(', ') }}`
   Reveal Solution Discussion Select an answer first