A parks IT security team wants an LLM only to rewrite verbose SIEM alerts into fixed structured fields for a ticketing system. What role limitation best matches that design?
Select an answer to reveal the explanation.
Short Explanation
Here the LLM is a form-filler for you, not your storyteller or forecaster. It's turning messy SIEM prose into tidy ticket fields; it doesn't reverse your summaries into verbose narratives, swap them for CVE enrichments, or mine archives for predictive risk scores. Keep the job to structured rewrite and you'll keep tickets consistent and auditable.
Full Explanation
Parks IT security teams that want an LLM only to rewrite verbose SIEM alerts into fixed structured fields are defining a transformation-only role. Structured transformation maps free-form alert prose into predefined ticket schema—severity, host, rule ID, timestamp, short summary—without granting the model advice authority or control-plane actions. That limitation improves consistency and auditability in municipal ticketing while containing blast radius if the model errs.
The correct role works because the output is constrained to known fields that humans and SOAR already understand. Errors are visible as bad field values, not reversed verbose narratives or off-schema predictive scores. The SIEM remains the detection source of truth; the LLM is a formatter, not a verbose narrative generator, CVE enricher, or predictive risk scorer.
Limiting the LLM to structured transformation of ticket summaries into verbose alert narratives rather than severity scores fails because it reverses the required direction and output. Expanding concise ticket summaries back into verbose narratives breaks the only-rewrite into fixed fields constraint and loses the severity, host, rule ID, timestamp, and summary schema needed for ticketing integration.
Limiting the LLM to structured transformation of alert text into normalized CVE enrichments rather than ad-hoc summaries fails as an expansion beyond structured rewrite into vulnerability enrichment unrelated to the stem. Normalized CVE enrichment is an analysis and correlation task, not mapping verbose SIEM prose into the predefined ticket fields that support parks SOC metrics, escalation SLAs, and reproducible investigations.
Limiting the LLM to structured transformation of historic ticket archives into predictive risk scores rather than incident timelines fails because it changes both the input and the job. Mining historic archives to predict future risk is a forecasting task, not rewriting current verbose SIEM alerts into fixed structured fields, and it violates the transformation-only limitation.
Exam caveat: When the stem says “only rewrite … into fixed structured fields,” select the narrow transformation role and reject options that reverse into verbose narratives, add CVE enrichment, or predict risk scores from archives.
Operational check: Enforce schema-validated outputs that allow only predefined ticket fields to block verbose narratives, deny CVE-lookup or historic-archive analytics permissions from the summarizer service account, and spot-check that ticket fields match the original SIEM alert before analysts escalate.
Prefer to study offline? Printable PDF study book + test engine ($7.50, unofficial). These questions stay free here.