CompTIA SecAI+ — Practice Questions and Mock Exam

The EU AI Act is landmark legislation that establishes a risk-based regulatory framework for artificial intelligence. It categorizes AI systems into four risk tiers: unacceptable risk (banned outright, such as social scoring systems), high risk (subject to strict requirements including conformity assessments, such as AI in hiring or law enforcement), limited risk (transparency obligations, such as chatbots that must disclose they are AI), and minimal risk (no specific requirements, such as spam filters). Organizations deploying AI in the EU or processing EU citizens' data must comply with the relevant tier requirements. The Act also includes provisions for general-purpose AI models like large language models. Understanding the EU AI Act's risk classification is critical for the SecAI+ exam because it represents the most comprehensive regulatory approach to AI governance globally. Exam tip: the EU AI Act has four risk tiers — remember the hierarchy from unacceptable down to minimal.

Two requirements have to be met by one control, and that narrows the field fast. Cost attribution needs per-consumer accounting; fair-share isolation needs a per-consumer ceiling. A token limit policy on the gateway delivers both, because it enforces limits per API consumer based on token usage and lets you set a tokens-per-minute rate alongside a quota over a longer period, keyed to something that identifies the caller such as a subscription key.

Tokens are the right unit. Both cost and backend capacity on a language model scale with tokens rather than with request count, so a plain requests-per-minute limit is a poor proxy: one very long prompt can consume more capacity than a thousand short ones and still pass a request-rate check. Keying the counter per consumer is what turns a global safety valve into isolation, because one team hitting its ceiling gets throttled without touching anyone else's headroom.

The distractors solve different problems. A denied-topics filter is a content-safety control and meters nothing. Semantic caching reduces backend calls for repeated prompts, which helps average cost but guarantees nothing about fairness or attribution. A larger context window increases how much a single request may consume, which makes the starvation risk worse rather than better.

Exam tip: when a gateway question pairs cost with capacity, look for the control whose unit is tokens and whose scope is the consumer key.

Pull the requirements apart and see which technology satisfies each one. Creating a ticket, gathering the relevant logs and suggesting a playbook are actions across different systems, which is orchestration. Running those steps automatically when a high-severity alert fires is event-triggered automation. Suggesting the most relevant playbook from the alert context is where AI assistance adds value. Leaving the final decision with an analyst is human-in-the-loop validation. Analysts confirm high-impact actions, but they do not need to approve every routine step. A SOAR (security orchestration, automation and response) platform is the category built for this combination. Its playbooks are preconfigured sets of remediation actions that run automatically when an alert or incident matches a rule, or that an analyst triggers manually during an investigation.

Each alternative drops at least one requirement. Static correlation rules on their own detect and alert, but nothing in that option opens a ticket or collects logs. A chatbot with no integrations can discuss an incident but cannot reach the ticketing system or the log store, so it cannot carry out any of those steps itself. A runbook driven by scheduled jobs is not event-driven or adaptive. The jobs run on a timer regardless of what happened, and the manual steps still wait for a person.

Exam tip: read the verbs in the stem. Detect points at monitoring, orchestrate and remediate point at response tooling, and an explicit human decision point tells you the intended answer keeps the analyst in the loop rather than removing them.

Objective 1.2 lists data-processing concepts essential to AI data security: data cleansing, verification, lineage, integrity, provenance, augmentation, and balancing. Data provenance records the origin and ownership of data, while data lineage tracks its movement and transformations through the pipeline; together they provide the documented evidence needed to assess trustworthiness and support audits and incident investigation. This matters for security because poisoned or tampered data is far easier to detect when origin and history are documented and verifiable. Do not confuse provenance/lineage with augmentation (creating synthetic data), balancing (fixing class skew), or watermarking (embedding ownership marks or detecting AI-generated content). Exam tip: 'where did the data come from and how was it transformed' equals provenance and lineage.