A is incorrect: Retraining an AI model during live playbook execution is not a practical response to a single low-confidence verdict. Model retraining is a scheduled MLOps activity that requires curated datasets, validation testing, and controlled deployment pipelines. Attempting real-time retraining would introduce latency, instability, and potential model degradation into an active incident response workflow without resolving the immediate alert disposition requirement.

B is correct: Routing the alert to an analyst for manual review is the correct action when an AI triage node returns a low confidence verdict. In AI-integrated SOAR playbooks, confidence scores drive conditional branching logic that determines appropriate next steps. Low or medium confidence verdicts indicate the AI model is uncertain about its classification, making human verification essential to prevent incorrect automated actions such as prematurely closing a legitimate threat or triggering unnecessary containment on a false positive. This approach ensures classification accuracy while preserving the benefits of AI-assisted triage for the SOC.

C is incorrect: Bypassing the AI decision node and restarting the playbook would create repetitive processing if the same alert continues to produce low confidence scores. Well-designed SOAR playbooks include fallback branches specifically for low-confidence scenarios that route uncertain verdicts to human analysts rather than discarding the AI output entirely or reprocessing the alerts repeatedly in a loop.

D is incorrect: Automatically closing an alert with a low confidence score is inappropriate because the AI model lacks sufficient certainty about the classification. Auto-closure is reserved for high-confidence false positive verdicts where the model has strong statistical certainty that the alert is benign. Closing low-confidence alerts risks dismissing genuine threats and undermines the security posture of the organization, as the model uncertainty indicates the alert warrants additional investigation by a human analyst.

A is incorrect: Data poisoning attacks target the training phase of a machine learning model by injecting malicious or corrupted data into the training dataset to compromise the model's future behavior. Since the scenario describes suspicious activity at the inference layer against an already deployed model, data poisoning does not apply. The attacker is probing the model's predictions at runtime, not modifying its training data, making this an inference-time privacy attack rather than a training-time integrity attack. Reference: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-2e2025.pdf

B is correct: Membership inference attacks involve an adversary querying a model with specific records and analyzing the confidence scores to determine whether those records were part of the training dataset. The healthcare model scenario shows classic membership inference behavior where the attacker systematically tests known patient records and observes confidence patterns that differ between training members and non-members. Runtime monitoring detects this through anomalous query patterns targeting specific records with focused attention on confidence outputs. Reference: https://owasp.org/www-project-machine-learning-security-top-10/docs/ML04_2023-Membership_Inference_Attack

C is incorrect: Adversarial evasion attacks involve crafting inputs specifically designed to cause the model to misclassify or produce incorrect outputs, typically by adding subtle perturbations that exploit decision boundaries. The attacker in this scenario is not trying to cause misclassification but is instead analyzing confidence scores to infer training data membership. Evasion attacks target model integrity at inference time, whereas the described behavior is a privacy attack targeting data confidentiality through confidence analysis. Reference: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-2e2025.pdf

D is incorrect: Model extraction attacks aim to replicate the functionality of a target model by sending a large number of diverse queries to learn its decision boundaries and behavior across the full input space. While model extraction also involves high-volume queries, the key distinction is that this attacker is focused on analyzing confidence scores for specific known patient records rather than broadly sampling inputs to reconstruct model logic. The targeted record-specific nature of the queries points to membership inference, not extraction. Reference: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-2e2025.pdf

A is incorrect: NLP-based summarization condenses lengthy threat reports into concise summaries for executive communication, but it does not address the operational challenge of deduplicating and prioritizing thousands of raw indicators arriving from multiple intelligence feeds.

B is correct: Machine learning-based deduplication identifies and consolidates duplicate indicators across multiple feeds, while confidence scoring assigns reliability values based on source quality and contextual analysis. Together, these AI capabilities reduce noise and focus analyst attention on the most actionable threat intelligence.

C is incorrect: Reinforcement learning for firewall rule optimization improves network perimeter device performance through iterative feedback-based tuning. This capability operates at the network infrastructure level and does not address indicator volume management within a TIP.

D is incorrect: Deep learning malware classification analyzes submitted samples in sandbox environments to identify malware families and behaviors. While valuable for malware analysis, it does not address the TIP-specific challenge of managing high-volume indicator feeds.

A is incorrect: Static rules that count anomalies within a time window do not understand the relationships between different entities or the contextual significance of how the anomalies are connected. Three unrelated anomalies occurring simultaneously would trigger the same alert as a genuine lateral movement chain, leading to false positives without providing the contextual understanding that cross-entity behavioral correlation delivers.

B is incorrect: Lowering detection thresholds would increase the volume of captured alerts without improving the ability to identify meaningful attack chains from the noise. This approach would worsen alert fatigue without providing the contextual correlation needed to link related anomalies across different entity types. The correct solution requires intelligent cross-entity correlation of existing anomalies, not simply capturing more of them.

C is incorrect: Signature-based detection relies on matching known attack patterns and cannot identify novel lateral movement sequences that use legitimate tools and actions. Advanced threat actors frequently use unique combinations that do not match predefined playbooks. Cross-entity correlation through behavioral analytics detects attack chains based on anomalous behavioral relationships between entities, not predefined signatures.

D is correct: Cross-entity alert correlation is a core UEBA capability that connects individually low-risk anomalies across different entity types to reveal multi-stage attack patterns. By linking the user authentication anomaly, the server connection anomaly, and the database transfer anomaly together, UEBA identifies the complete lateral movement chain even when each individual signal is insufficient to trigger an alert on its own. This correlation approach is critical for detecting advanced persistent threats that distribute activity across entities.

A is incorrect: Autoencoders used for anomaly detection do not generate synthetic attack traffic for training. They are trained exclusively on normal network traffic to learn the statistical properties of benign behavior. Detection relies on the model's inability to accurately reconstruct anomalous inputs, not on comparison to a library of attack patterns. Generating synthetic attacks is associated with adversarial training techniques, which serve a different purpose.

B is correct: An autoencoder is an unsupervised deep learning model that learns to compress and reconstruct input data. When trained exclusively on normal network traffic, the autoencoder develops an efficient internal representation of typical traffic patterns. During detection, traffic that differs significantly from normal patterns produces a high reconstruction error because the model cannot accurately reconstruct inputs it has not learned to represent. This elevated error score signals an anomaly that may indicate a network intrusion or zero-day threat.

C is incorrect: Comparing packet hashes against a repository of known malicious fingerprints describes a signature-based or hash-matching detection approach, not an unsupervised machine learning model. Autoencoders do not use hash comparisons; they use neural network-based reconstruction to evaluate whether traffic aligns with learned patterns of normal behavior. Hash-based methods also cannot detect novel threats absent from the repository.

D is incorrect: Classification into predefined threat categories using labeled examples describes a supervised learning approach, not an unsupervised autoencoder. Supervised classifiers require labeled training data with known attack types, whereas autoencoders learn from unlabeled normal traffic data and identify anomalies based on reconstruction error. Autoencoders do not require attack samples in their training set to detect intrusions.

A is incorrect: Encrypting notebooks and restricting repository access improves security but does not address the root cause. The credentials remain embedded in the notebooks, meaning anyone with decryption access or repository permissions can still extract them. Additionally, encrypted notebooks are difficult to use in automated pipelines and do not support credential rotation or centralized management. The correct approach is to remove credentials from notebooks entirely and store them in a dedicated secrets manager. Reference: https://cheatsheetseries.owasp.org/cheatsheets/Secure_AI_Model_Ops_Cheat_Sheet.html

B is incorrect: Replacing API keys with OAuth tokens improves the authentication mechanism but storing any credential type in a configuration file within the pipeline codebase still constitutes hardcoding secrets. Configuration files are often committed to version control and can be accessed by anyone with repository permissions. The underlying vulnerability of storing credentials in plain text within the code repository remains unresolved regardless of the token type being used. Reference: https://cheatsheetseries.owasp.org/cheatsheets/Secure_AI_Model_Ops_Cheat_Sheet.html

C is correct: Migrating credentials to a centralized secrets manager is the most appropriate remediation. Hardcoded secrets in source code or notebooks are a well-known security vulnerability in MLOps environments. Secrets managers such as HashiCorp Vault or AWS Secrets Manager provide secure, access-controlled storage with rotation capabilities and audit logging. Injecting secrets at runtime through environment variables or CI secrets injection ensures credentials are never persisted in code repositories, significantly reducing the risk of credential exposure if the repository is compromised. Reference: https://cheatsheetseries.owasp.org/cheatsheets/Secure_AI_Model_Ops_Cheat_Sheet.html

D is incorrect: Moving notebooks to a private repository and implementing network segmentation adds defense layers but does not remediate the core vulnerability. The credentials are still hardcoded in the notebooks, and any authenticated user with repository access can extract them. Network segmentation protects the repository infrastructure from unauthorized network access but does not address the insecure practice of embedding secrets directly in code or notebook files. Reference: https://cheatsheetseries.owasp.org/cheatsheets/Secure_AI_Model_Ops_Cheat_Sheet.html

A is correct: Storing API keys in a secrets manager is the correct approach. According to secure MLOps best practices, teams should never hardcode secrets in source code or notebooks and should instead use secret managers such as AWS Secrets Manager or HashiCorp Vault. Secrets managers provide centralized, encrypted storage with access controls, audit logging, and automatic rotation capabilities. Environment variable injection ensures credentials are dynamically retrieved at runtime without being persisted in code. Reference: https://cheatsheetseries.owasp.org/cheatsheets/Secure_AI_Model_Ops_Cheat_Sheet.html

B is incorrect: Network access control lists restrict connectivity at the network layer but do not address the vulnerability of hardcoded secrets within the code. Any authorized user who can clone the repository still has access to the embedded API keys. This approach also does not prevent secrets from being leaked through repository forks, backups, or CI/CD logs. The vulnerability requires externalizing secrets from the codebase, not restricting network-level access to the repository. Reference: https://cheatsheetseries.owasp.org/cheatsheets/Secure_AI_Model_Ops_Cheat_Sheet.html

C is incorrect: Encrypting entire notebooks before committing them prevents other team members from reviewing or collaborating on the code without the decryption key. This approach creates operational friction, does not solve the underlying problem of secrets being embedded in code, and introduces key distribution challenges. If the encryption key is compromised, all embedded secrets are exposed simultaneously. The correct practice is to externalize secrets, not encrypt the files containing them. Reference: https://cheatsheetseries.owasp.org/cheatsheets/Secure_AI_Model_Ops_Cheat_Sheet.html

D is incorrect: Adding notebooks to .gitignore prevents future commits but does not remove secrets already present in the repository's version history. Additionally, excluding notebooks from version control undermines collaboration, reproducibility, and auditability of ML experiments, which are core MLOps principles. The root cause is that secrets are embedded in code, and the solution should externalize the secrets rather than exclude the code files from the repository. Reference: https://cheatsheetseries.owasp.org/cheatsheets/Secure_AI_Model_Ops_Cheat_Sheet.html

A is incorrect: A report showing total alert volume processed by the playbook provides operational throughput metrics but does not explain why a specific incident received a particular severity classification. The analyst needs to understand the reasoning behind a single triage decision, not aggregate workload statistics. Alert volume metrics are useful for SOC capacity planning but not for individual incident-level explainability.

B is incorrect: Providing raw machine learning model weights does not meaningfully help an analyst understand why a specific incident was classified as high severity. Model weights are internal numerical parameters describing how the model was trained, but they do not translate into human-understandable reasoning for individual classification decisions. Explainable AI outputs should present actionable, interpretable rationale to security practitioners. Reference: https://airc.nist.gov/airmf-resources/airmf/3-sec-characteristics/

C is correct: A reasoning summary that explains the key factors behind the severity classification best addresses the analyst's need. Explainability in AI-powered SOAR playbooks means documenting why the AI arrived at a specific triage decision by providing contributing factors such as matched threat indicators, asset criticality, and behavioral anomalies. This allows the analyst to validate the classification, build trust in the system, and make informed decisions about next steps.

D is incorrect: Average response time metrics measure the overall efficiency of incident handling but provide no insight into why a particular incident received a high severity classification. Response time is a performance indicator for the SOC, not an explainability mechanism. The analyst needs to understand the evidence and factors that led the AI model to its specific triage decision for this incident.