AP Cybersecurity Source Analysis Guide

The free-response section of the AP Cybersecurity Exam is a single Device Security Analysis task. It hands you several simulated sources about one digital device and asks you to find security issues, spot evidence of attacks, and explain how changes to configuration or permissions would affect the device and its users.

This guide helps you do the one thing that separates strong responses from weak ones: read the sources as a connected set, not as four unrelated documents. You will learn a cross-checking workflow, how to cite evidence so it actually counts, and the traps that cost easy points.

Where This Shows Up on the Exam

The FRQ is worth 30 percent of your score, and you get a suggested 50 minutes for it. Only Skill Categories 2 (Mitigate Risk) and 3 (Detect Attacks) are assessed here, so your job is to detect attacks and reason about controls and mitigations, not to perform a full risk likelihood-and-impact writeup.

The sources all describe the same device captured during a risk assessment. Expect a mix like these:

• Security policies (for example password and account-lockout rules)
• Firewall configurations and access control lists
• File-system permissions
• Log files such as /var/log/auth.log, /var/log/nginx/access_log, and /var/log/app/network_app.log

The task verbs tell you what response shape to give. Identify wants a concept or a piece of evidence. Describe wants information about a process or outcome. Explain wants reasons backed by specific evidence. Determine wants a result you reach by applying criteria. Write wants a correct command that produces a stated effect.

Why Cross-Checking Beats Reading in Isolation

A single source rarely proves anything on its own. A log line that looks routine becomes meaningful only when you compare it against the policy that should have blocked it or the firewall rule that should have stopped the traffic.

Think of each source as one witness. The strongest answers connect two or more witnesses so that the conclusion is supported, not guessed. That linkage is exactly what the Explain prompts reward.

Here is the mental model. The policy tells you what is supposed to be true. The configuration tells you what the device is actually set to do. The logs tell you what really happened. When those three disagree, you have found a security issue worth writing about.

A Cross-Checking Workflow

Use this order so you build context before you draw conclusions.

1. Read the prompt first and list the tasks. Number each sub-question and note its task verb. This tells you whether you need a command, an explanation, or a description.
2. Map the sources. In the margin, label what each source is: policy, config, permissions, or log. Note the device, users, and any timestamps or IP addresses.
3. Establish the baseline. From the policy and config, write down what behavior is supposed to be allowed and denied. This is your expected state.
4. Scan the logs for deviations. Look for activity that contradicts the baseline, such as access that policy should have blocked or repeated failed authentications that exceed the lockout rule.
5. Connect across sources. For each deviation, ask which other source explains or confirms it. Pair a log entry with the rule or permission that allowed or failed to stop it.
6. Answer with evidence and reasoning. Quote or reference the specific source, then state what it shows and why it matters.

How to Cite Evidence That Counts

Vague evidence earns nothing. "The logs look suspicious" does not show you analyzed anything. Point to the exact artifact.

Use this three-part pattern for any Explain response:

• Cite: name the source and the specific detail (a log field, a timestamp, an IP, a permission string, a firewall rule line).
• Interpret: state what that detail indicates.
• Connect: tie it to another source or to the security outcome.

For example: the account-lockout policy sets a threshold of 5 failed attempts, but /var/log/auth.log shows many consecutive failed logins for one account from a single source without a lockout. The mismatch between the policy and the log is your evidence that the lockout control is not enforced, which is an indicator of a possible password attack.

When a prompt says Write, give the actual command, not a description of it. Keep commands defensive and tied to the source, for example setting file permissions, adjusting a host-based firewall rule, or verifying a file hash. Match the command to the effect the prompt asks for.

Worked Mini-Example

Suppose the prompt gives you a firewall ACL, a file-permissions listing, and an nginx access log, and asks you to determine whether a web server was accessed in a way the configuration should have prevented.

Cross-check it like this. If the ACL should deny external traffic to an admin path but the access_log shows successful requests to that path from an external address, you have found an issue. Then look at the permissions: if the relevant files are world-readable, you can explain why that access is more damaging.

Your response would cite the served request line, note that the ACL was supposed to deny it, and connect that to the overly broad permissions to explain the impact. That is a complete chain of evidence and reasoning.

Common Mistakes to Avoid

• Reading sources one at a time and answering separately. Points come from connecting the policy, config, and logs. Always ask which other source confirms your claim.
• Citing the source type instead of the detail. "According to the log" is not evidence. Name the field, line, timestamp, IP, or permission string.
• Stating a conclusion with no reasoning. If the verb is Explain, you must say why the evidence supports the claim, not just what you found.
• Ignoring the policy baseline. Many issues only appear as a gap between what the policy requires and what the config or log shows. Establish the expected state first.
• Describing a command when the prompt says Write. Give the exact command that produces the stated effect.
• Importing essay rubric habits. This is not a history document-based question. There is no thesis or contextualization requirement. Answer each task directly using source evidence and clear reasoning.
• Skipping timestamps and identifiers. Correlating events by time, account, or IP across logs is often how you prove an attack sequence.

Quick Checklist Before You Submit

• Did you answer every numbered task and match its verb?
• Did each claim cite a specific detail from a named source?
• Did you connect at least two sources where the prompt asks you to explain?
• Did you compare what the policy and config require against what the logs show?
• Are your commands exact, defensive, and tied to the requested effect?

Treat the source set as one device telling one story across four documents. When you read across them instead of down each one, the security issues and the evidence to support them tend to surface on their own.