Device Security Analysis FRQ Guide

The Device Security Analysis free-response question is the single FRQ on the AP Cybersecurity Exam, and this guide shows you how to work through it efficiently. You will get several simulated sources about one digital device and need to analyze them to identify security issues, find evidence of attacks, describe how configuration or permission changes affect the device and users, and evaluate how security controls, such as firewalls or automated systems, influence network traffic and device behavior.

This guide gives you an optional reading workflow, a source-by-source checklist, and a worked mini-example using safe defensive evidence.

Where This Shows Up on the Exam

The exam is 2 hours and 10 minutes: 60 multiple-choice questions (70%) and one FRQ (30%). The FRQ section is 50 minutes, and that is the suggested time for the Device Security Analysis prompt.

The exam description emphasizes Skill Categories 2 (Mitigate Risk) and 3 (Detect Attacks), and the skills reference marks Skill Category 1 (Analyze Risk) as FRQ-applicable too. Be ready to identify vulnerabilities, threats, attack methods, exploited assets, likelihood, and impact when the sources call for that reasoning. Expect to use course knowledge about risk, controls, permissions, configurations, logs, detection, and device behavior without assuming the prompt comes from one specific unit.

The sources are several simulated sources about one digital device. They may include broad categories such as security policies, firewall configurations, file-system permissions, and log files. The exact source names and formats can vary, so read the provided labels instead of expecting a specific operating system, service, or file path.

Students are expected to cite evidence from the provided sources and explain their reasoning when describing attacks, permission settings, or the impact of policy or configuration modifications. Treat that as a core FRQ habit: claim, source evidence, and reasoning.

Know Your Task Verbs

The prompt uses precise task verbs, and matching your answer to the verb is how you earn credit.

If a part says Explain, an answer that only identifies will fall short. Pair the claim with source evidence when the part asks you to describe an attack, explain a permission setting, or explain the impact of a policy or configuration change.

If a part says Write, provide the command itself in print form and make sure it has the indicated defensive effect. Read the source context first so your command matches the system, path, permission, firewall rule, or cryptographic action the prompt actually describes.

A 5-Step Reading Workflow

Use this order so you do not waste time rereading sources.

1. Read the scenario and every prompt part first. Underline the task verb and the exact deliverable in each part.
2. Skim the source list and label what each source can tell you (policy, firewall, permissions, logs).
3. Read the security policy and firewall settings to set the baseline of what should be allowed.
4. Read the logs against that baseline, marking lines that conflict with policy or show repeated failures.
5. Draft answers part by part, using specific source details when the part asks for evidence or reasoning. When the evidence connects across sources, combine them: a policy can define the expected behavior, a configuration can show the control, and a log can show what actually happened.

One practical approach is to spend a short opening block reading and annotating, then use the rest of the 50 minutes to write and review. Answer in the order asked unless one part clearly unlocks another.

Source-by-Source Checklist

Security policies

Policies are your rulebook. Note password and account-lockout rules, who should have access to what, and which services are allowed. When a log or setting contradicts the policy, that gap is your security issue.

Firewall configurations

A firewall uses an access control list to allow or deny traffic entering or leaving the device. Check which ports and addresses are permitted, whether the default action is deny, and whether any rule allows traffic the policy says to block. An overly broad allow rule is a common issue to flag.

File-system permissions

Linux permission strings show read, write, and execute access for owner, group, and others. Watch for files or directories where others have more access than the policy intends, or where regular users hold administrative privileges. Weak access control lets an adversary read, edit, or destroy files if an account is compromised.

Log files

Logs are your evidence of activity. Match each suspicious entry to a baseline expectation, then classify what it suggests. Look for patterns like repeated failures, unusual times or sources, blocked or allowed traffic that contradicts policy, and activity that appears after a configuration or permission change.

Automated systems

Automated systems may appear as security controls or source outputs, such as alerts, detections, enforcement rules, or automated responses. Ask what the system observed, what action it took or recommended, and how that action changed network traffic or device behavior. Then evaluate whether the automated control actually addresses the issue shown in the other sources.

Worked Mini-Example

Suppose the policy states the account-lockout threshold should be five failed attempts, and a login log shows:

</>Code
Failed password for user jdoe from 10.0.0.7 port 52211
Failed password for user jdoe from 10.0.0.7 port 52212
Failed password for user jdoe from 10.0.0.7 port 52213
Failed password for user jdoe from 10.0.0.7 port 52214
Failed password for user jdoe from 10.0.0.7 port 52215
Failed password for user jdoe from 10.0.0.7 port 52216
Accepted password for user jdoe from 10.0.0.7 port 52217

Identify: there are six consecutive failed logins for one account from a single source, followed by a success.

Detect and classify: this pattern is an indicator of compromise consistent with a password-guessing attack that eventually succeeded.

Evaluate the control: the policy sets a lockout at five failed attempts, but six failures were allowed, so the account-lockout policy was either not configured or not enforced on this device. Configuring the lockout to trigger at five failures would have blocked the attempt before the success, reducing the chance an adversary guesses a valid password.

Notice that the answer cites specific evidence, classifies the activity, and ties the gap back to a control and its impact on device behavior.

Describing Configuration and Permission Changes

Some parts ask how a change would affect the device and users. When the prompt asks for both, structure your answer around two effects: security effect and user effect.

For example, tightening a directory so only the research group has access protects confidentiality, but it also means other users can no longer read those files. If you remove a firewall allow rule, you block that traffic and reduce exposure, but legitimate users of that service lose access too. State both sides when the prompt asks about both device behavior and user impact.

Evaluating Controls

When you evaluate a control such as a firewall, host-based protection, or an automated system, judge how well it addresses the issue you found and what it costs. Tie your judgment to the evidence: a control that would have blocked the exact activity in the logs is strong, while one that misses the observed pattern is weak. State how the control changes network traffic, device behavior, and legitimate user access where relevant. Mention layered controls when one control alone leaves a gap, since defense in depth is a core idea in the course.

Common Mistakes to Avoid

• Answering without evidence-based reasoning. Explain parts need support from the sources, and Determine parts need a clear result grounded in the provided information.
• Ignoring the task verb. Identify and Explain are not interchangeable, and only Write expects an actual command.
• Describing impact one-sidedly when the prompt asks for both dimensions. Note the security benefit and the effect on legitimate users when both are part of the deliverable.
• Treating logs as proof of nothing or proof of everything. Compare entries to the policy baseline before classifying.
• Reading sources before reading the prompt. You will reread and lose time.
• Forgetting to evaluate, not just identify, when the part asks you to judge a control's impact.

Quick Pre-Submit Check

Before time runs out, confirm each answer matches its task verb, uses source evidence where the prompt requires reasoning, and addresses the full deliverable. For impact and evaluation parts, make sure you answered the exact dimensions asked, such as device behavior, user impact, network traffic, or control effectiveness.