SDSI Select Two (Multi-Select) Questions

Explanation: Option B (Explainability and transparency, XAI) is correct because security automation platforms increasingly rely on AI/ML models to triage alerts and make risk decisions, so analysts and auditors must be able to understand why a model produced a given verdict to trust, validate, and defend it. Option C (API integration and extensibility) is correct because a security automation platform must interoperate with SIEM, SOAR, EDR, ticketing, and threat-intel systems via REST APIs, webhooks, and plugins, so its ability to integrate and be extended determines how well the AI/ML capabilities fit existing workflows. Option E (Data quality and labeling) is correct because ML model accuracy in security use cases depends directly on well-curated, correctly labeled, and representative training data (e.g., labeled true/false positives), and poor data quality leads to high false-positive rates and unreliable automation. Option A is not a key AI/ML design consideration because vendor team headcount does not determine model explainability, integration capability, or data quality. Option D is not a key AI/ML design consideration for platform selection because local GPU acceleration is an infrastructure/deployment detail, not a core AI/ML design factor, and many platforms deliver inference via cloud or vendor-managed services.

Explanation: Option A is correct because strict schema validation on all incoming API requests enforces expected data types, formats, and required fields, which directly mitigates OWASP API threats such as mass assignment, injection, and improper input handling by rejecting malformed or unexpected payloads before they reach backend logic. Option D is correct because continuous monitoring of API traffic for anomalies that indicate data exfiltration helps detect and respond to threats like excessive data exposure and data harvesting, which are core concerns in the OWASP API Top 10. Option E is correct because deploying Cisco API Security to detect Broken Object Level Authorization (BOLA) addresses the top-ranked OWASP API risk, where attackers manipulate object identifiers to access resources belonging to other users; API security tooling can baseline and flag such unauthorized object access patterns. Option B is incorrect because bypassing authentication for performance eliminates access control entirely and would worsen, not mitigate, OWASP API threats such as broken authentication and BOLA. Option C is incorrect because disabling logging of API request headers removes critical audit and forensic visibility needed to detect and investigate attacks, undermining rather than strengthening API security.

Explanation: Cisco XDR (formerly SecureX) is built around an automation pipeline in which Workflow orchestration (A) is a core feature, allowing security teams to design, trigger, and chain automated response actions across integrated Cisco and third-party tools. Incident management and response (B) is also central, since XDR correlates detections into incidents, enriches them, and drives response actions from a single console. Threat intelligence aggregation (C) is likewise a key capability, as XDR ingests and normalizes threat intel from multiple sources (e.g., Cisco Talos, third-party feeds) to enrich detections and inform automated workflows. Automated server patching (D) is not a Cisco XDR function; patching is handled by endpoint management or vulnerability/patch management tools, not by the XDR platform itself. Network packet capture hardware (E) is a physical appliance concern (e.g., dedicated capture devices or switches with SPAN/TAP), not a feature of the Cisco XDR software platform.

Explanation: Infrastructure as Code (IaC) (A) is essential because it lets Cisco device configurations, policies, and cloud/network resources be defined declaratively in version-controlled templates, enabling repeatable, auditable, and peer-reviewed deployments instead of error-prone manual CLI changes. Continuous Monitoring (C) is required to detect drift, unauthorized configuration changes, and threats in real time across Cisco infrastructure, feeding telemetry into SIEM/SOAR and compliance dashboards so issues are caught and remediated quickly. Automated Testing (D) is essential to validate IaC templates and security controls in CI/CD pipelines (e.g., unit, integration, and policy-as-code checks) before changes reach production, preventing misconfigurations from being deployed. Manual Review Committees (B) are not a core DevSecOps component because they introduce slow, human-gated approvals that contradict the automation and continuous-delivery principles of DevSecOps, even if some review may still occur. Isolated air-gapped networks (E) are not essential to a DevSecOps architecture; while useful in specific high-security environments, they prevent the continuous integration, delivery, and monitoring that DevSecOps depends on.

Explanation: Option A, 802.1X with EAP-TLS, is correct because it provides strong, certificate-based mutual authentication that uniquely identifies IoT devices on the enterprise network before granting access. Option D, device profiling with Cisco ISE, is correct because ISE identifies IoT devices by collecting attributes such as MAC OUI, DHCP fingerprints, and HTTP user-agent data to classify and authorize them. Option B, ignoring the device type, is wrong because it provides no identification and defeats access control. Option C, using public Wi-Fi access, is wrong because it is an untrusted network path that does not identify devices to the enterprise. Option E, MAC address spoofing, is wrong because spoofed MAC addresses are easily forged and cannot reliably identify a device.