AP Computer Science Principles Quick Review

Good programs are built and improved through structured collaboration, not solo genius --- effective teams divide tasks, agree on a shared design, and give/receive constructive feedback.

Collaboration includes pair programming, code reviews, storyboarding a program before coding, dividing a program into pieces assigned to different people, and revising code based on feedback from teammates or users.

Collaboration $≠$ simply splitting work in half and never communicating --- real collaboration requires a shared plan for how the pieces will connect (agreed data formats, agreed procedure names).

Questions describe a ``collaboration'' scenario and ask which choice best supports it; students pick the option that finishes the program fastest instead of the option that shows genuine communication and shared understanding.

Collaboration $arrow$ shared plan + feedback, not just divided labor.

Programs are built in small, testable pieces --- write a little, test it, fix it, then add the next piece --- rather than writing an entire program at once.

Incremental development = building a program in small pieces and testing each piece as it's added. Iterative development = repeatedly revising a program based on feedback or testing results across the whole design/develop/test cycle.

Incremental (adding new pieces one at a time) vs.\ iterative (looping back to revise existing pieces) --- a program can be built incrementally without ever being revised, and revised without adding new features.

A scenario shows a programmer writing 200 lines before running the program once; students fail to identify this as violating incremental development, which calls for testing in small chunks.

Incremental = add piece by piece; iterative = revise, revise, revise.

Documentation --- comments plus external descriptions of a program's purpose, inputs, and outputs --- lets other programmers, and the original author later, understand and maintain code without re-reading every line.

Good documentation states a program's or procedure's purpose, inputs, outputs, and assumptions. Comments should explain WHY a choice was made, not just restate WHAT the code already shows.

Documentation vs.\ debugging output --- DISPLAY statements used only to test a program are temporary diagnostic tools, not documentation, and should usually be removed before final submission.

Students think any comment counts as ``good documentation,'' but exam items reward the comment that explains algorithm purpose or edge cases over one that just repeats the line of code in English.

Comments explain WHY, not WHAT the code already says.

Systematic testing --- tracing code by hand, testing boundary/edge cases, testing across a range of inputs --- finds errors faster and more reliably than randomly changing code and re-running it.

Syntax errors: bad code structure, caught before the program runs. Runtime errors: the program crashes while running (e.g.\ dividing by zero). Logic errors: the program runs to completion but produces the wrong output --- the hardest to catch, found by tracing and test cases.

Runtime error (program crashes) vs.\ logic error (program runs to completion but produces incorrect results) --- a program with only logic errors still executes successfully.

A question gives a program that runs without crashing but returns a wrong value; students misclassify this as a ``syntax error'' instead of a logic error because ``the code looks fine.''

Syntax = won't run. Runtime = crashes mid-run. Logic = runs, wrong answer.

Abstraction hides implementation details behind a simpler interface --- a name, a set of inputs/outputs --- so programmers can reason about a large program without holding every detail in their head at once.

Abstraction appears throughout CS: procedural abstraction (a named procedure hides its internal steps), data abstraction (a list name hides the individual values it holds), and hardware abstraction (a ``device'' hides its underlying circuitry).

Abstraction (hiding unnecessary detail to manage complexity while the program still works correctly) vs.\ vague simplification for its own sake --- abstraction must preserve correct behavior.

Students think ``abstraction'' only means ``using a function,'' missing that exam items also test data abstraction (grouping data into a list/object) as a distinct form of abstraction.

Abstraction = hide detail behind a name you can trust.

All data in a computer --- numbers, text, images, sound --- is ultimately stored as sequences of binary digits (bits), each either 0 or 1, because digital circuits reliably distinguish only two states.

With $n$ bits you can represent $2^n$ distinct values (e.g., 8 bits $arrow 2^8=256$ values, numbered 0--255). Converting binary to decimal sums the place values ($…,2^3,2^2,2^1,2^0$) where a 1 appears.

Bit (a single 0/1) vs.\ byte (a group of 8 bits) --- file sizes are usually reported in bytes, kilobytes, megabytes, not raw bit counts.

Students compute $2^n$ but forget the range is $0$ to $2^n-1$, off-by-one-ing the maximum representable value (saying 8 bits max out at 256, not 255).

$n$ bits $arrow 2^n$ values, numbered $0$ to $2^n-1$.

Because computers only store bits, any real-world data type --- text, color, sound, image --- needs an agreed-upon encoding scheme mapping bit patterns to meaningful values.

Text uses character encodings like ASCII (7-bit, 128 characters) and Unicode (supports far more characters/languages worldwide). Images are grids of pixels, each pixel's color encoded in bits (e.g., RGB values). Sound is sampled at intervals, each sample's amplitude stored as a number.

ASCII vs.\ Unicode --- ASCII is a small subset covering only basic English characters/symbols; Unicode was created specifically to represent characters from many world languages that ASCII cannot.

A question describes needing to store non-English text, and students pick ``increase the sample rate,'' confusing an audio concept with text encoding.

Text $arrow$ ASCII/Unicode. Image $arrow$ pixels. Sound $arrow$ samples.

Compression re-encodes data to use fewer bits, trading off between preserving every detail (lossless) and accepting some loss of information for a much smaller file (lossy).

Lossless compression (e.g., ZIP) allows the exact original data to be reconstructed. Lossy compression (e.g., JPEG, MP3) permanently discards some data to shrink the file further and cannot be perfectly restored.

Lossy vs.\ lossless --- lossy is not simply ``worse,'' it's a deliberate trade-off appropriate when small file size matters more than perfect fidelity (streaming video/audio); lossless is required when every bit must be recoverable (software, text documents).

Students assume more compression is always better; the exam tests recognizing when lossy compression is inappropriate (e.g., compressing source code or medical images where every detail matters).

Lossless = perfectly restorable. Lossy = smaller, but some data gone forever.

Raw data only becomes useful information once it's cleaned, filtered, transformed, or visualized to reveal patterns, trends, or answers to a question --- data alone doesn't ``speak.''

Common techniques: filtering (removing irrelevant rows), sorting, combining/joining multiple data sets, summarizing (averages, counts), and visualizing (charts/graphs) to make patterns visible to humans.

Data (raw, unprocessed facts, like a spreadsheet of numbers) vs.\ information (the meaning extracted after processing, like a trend or conclusion presented for people to use).

A scenario asks how to find a pattern in a huge data set, and students pick ``read through it manually'' instead of the choice describing computational tools (sorting, filtering, visualization) needed at real-world scale.

Data + processing $arrow$ information.

Large data sets (big data) are stored in databases and searched/queried using software tools because they are too large for a person to read completely, and metadata makes searching them efficient.

Metadata is ``data about data'' (e.g., a photo's timestamp, location, camera model) and is often what makes searching/organizing huge collections practical. Combining multiple data sets can reveal information not visible in any single data set alone.

Metadata (data describing other data, like a file's creation date) vs.\ the data itself (the file's actual content) --- metadata can reveal information even if the underlying content is never opened.

Students underestimate metadata's power; a scenario may show that combining seemingly harmless metadata (timestamps + locations) from multiple posts identifies a person, and students miss that this is a privacy concern.

Metadata = data about data $arrow$ often more revealing than the data itself.

Conclusions drawn from data are only as good as the data collected --- an unrepresentative sample, missing data, or a flawed collection method produces biased or misleading conclusions even with perfectly correct computation.

Bias can enter through sampling (who/what is measured), collection method (how it's measured), and the questions asked. Larger data sets reduce random error but do not fix a systematically biased sampling method.

Bias in the data collection process vs.\ a calculation/rounding error --- fixing bias requires collecting better/more representative data, not recomputing the same flawed data set more precisely.

Students think ``more data always fixes bias''; the exam tests recognizing that a bigger biased sample is still biased --- only a differently or better-sampled data set fixes it.

More data $≠$ less bias. Fix the sample, not just the size.

A variable is a named storage location whose value can change while a program runs; the assignment operator ($≤ftarrow$ in AP pseudocode) stores a new value, overwriting whatever was there before.

variable $≤ftarrow$ expression evaluates the right side first, then stores the result. x $≤ftarrow$ x + 1 takes x's current value, adds 1, and stores that back into x --- a common counter/increment pattern.

Assignment ($≤ftarrow$, one-directional, changes a value) vs.\ equality/comparison ($=$, checks whether two values are equal, used inside conditions) --- AP pseudocode uses $≤ftarrow$ specifically to avoid this ambiguity.

In a trace-the-code question, students evaluate the right-hand expression using the variable's NEW value instead of its value BEFORE the assignment line executes.

$≤ftarrow$ stores. Evaluate the right side first, using OLD values.

A list groups multiple related values under a single name so an algorithm can process many pieces of data with the same code instead of writing a separate variable for each item.

In AP pseudocode, list indices start at 1 (list[1] is the first element). Key operations: LENGTH(list), APPEND(list, value) adds to the end, INSERT(list, i, value) inserts at position i, REMOVE(list, i) deletes the item at position i.

AP pseudocode lists are 1-indexed, while many real programming languages (Python, Java, JavaScript) are 0-indexed --- always check which convention a given question uses.

The single most common slip on both the MCQ exam and the Create PT: assuming list[0] is the first element in AP pseudocode, causing an off-by-one error when tracing or writing loop bounds.

AP pseudocode lists start at index 1, not 0.

Every algorithm is built from exactly three control structures: sequencing (steps run in order), selection (a branch chooses between paths based on a condition), and iteration (a block repeats).

Selection: IF(condition)/ELSE IF(condition)/ELSE. Iteration: REPEAT n TIMES (fixed count), REPEAT UNTIL(condition) (repeats until the condition becomes true, checked before each pass), and FOR EACH item IN list (runs once per list element).

REPEAT UNTIL(condition) stops when the condition becomes TRUE --- the opposite logic of a ``while this is true, keep going'' loop; mixing this up flips how many times the loop runs.

Students trace a REPEAT UNTIL loop and stop it as soon as the condition is first checked as false, instead of continuing to repeat until it becomes true.

REPEAT UNTIL $arrow$ stops when condition turns TRUE.

A Boolean expression evaluates to exactly one of two values, TRUE or FALSE, and is what selection/iteration structures use to decide which path to take or whether to keep repeating.

Relational operators: $=,≠,>,<,≥q,≤q$. Logical operators combine Booleans: NOT (flips true/false), AND (true only if both are true), OR (true if at least one is true).

AND vs.\ OR --- an AND of two conditions is stricter (needs both true) than an OR of the same two conditions (needs only one true).

Applying NOT to a compound expression, students mis-negate NOT(a AND b) as (NOT a) AND (NOT b) instead of the correct (NOT a) OR (NOT b).

NOT(a AND b) = (NOT a) OR (NOT b) --- flip and flip the operator too.

A procedure (function/method) packages a named, reusable sequence of instructions that can be called multiple times, optionally taking parameters that customize its behavior each time it's called.

PROCEDURE name(parameter1, parameter2) defines a procedure; RETURN(value) sends a value back to the caller and ends execution. A parameter is the placeholder name in the definition; an argument is the actual value passed in when the procedure is called.

Parameter (the variable name listed in the procedure's definition) vs.\ argument (the specific value supplied at the call site) --- exam wording uses both terms precisely.

On the Create PT, a procedure that has a parameter but is only ever called once, or always called with the same hard-coded value, does NOT satisfy the requirement that the parameter change what the procedure does --- it must be called with different arguments that visibly change behavior.

Parameter = placeholder in the definition. Argument = real value at the call.

Once a procedure is written and tested, other code can call it without knowing how it works internally --- this lets programmers build on existing libraries/APIs instead of reinventing every low-level operation.

An API (Application Programming Interface) exposes a set of procedures another program can call, hiding the implementation. Using a library/API speeds up development and reduces bugs because the underlying code has already been tested by others.

Using an API/library call vs.\ writing the same functionality from scratch --- both can produce the same output, but only the API call counts as abstraction being USED, not created.

Students assume calling any pre-built procedure automatically satisfies the Create PT's ``student-developed procedure'' requirement --- it does not; that specific required procedure must be written by the student, not just an API call.

APIs let you call code you didn't write and don't need to understand.

Strings (sequences of characters) support their own operations --- accessing individual characters, finding substrings, concatenating --- letting programs process and transform text data.

Common operations: concatenation (joining strings together), finding a string's length, and accessing/extracting a substring. Strings are often treated like lists of characters for indexing purposes.

Concatenation (joining two strings end-to-end, e.g., ``cat'' + ``fish'' = ``catfish'') vs.\ numeric addition --- combining two strings that look like numbers (``5'' and ``3'') concatenates to ``53,'' it does not add to 8.

A trace question mixes a numeric variable and a string variable in an expression; students perform arithmetic addition when the pseudocode intends string concatenation, or vice versa.

``5'' + ``3'' as strings $arrow$ ``53,'' not 8.

Because a list groups many values, algorithms almost always process it with a loop that visits (``traverses'') each element once, commonly to search for a value, compute a total, or transform every element.

A FOR EACH item IN list loop automatically visits every element in order. A counting loop using indices (tracking position i) is used when the position itself matters, e.g.\ comparing neighboring elements.

Traversing to search (can stop early once found) vs.\ traversing to process every element (must visit all, e.g., summing) --- a summing algorithm that stops early gives a wrong (too small) total.

In a ``search for a value'' trace, students let the loop keep running after the target is found, then trace extra unnecessary iterations, sometimes mis-reporting the final matched index.

FOR EACH $arrow$ visits every item automatically, in order.

Different algorithms that produce the same correct result can take drastically different amounts of time depending on input size, so algorithms are compared by how their running time grows as input size grows, not by their runtime on one specific input.

An efficient algorithm's runtime grows manageably as input size $n$ grows (e.g., proportional to $n$). An inefficient algorithm's runtime can grow so fast (e.g., proportional to $2^n$) that even a fast computer can't finish it for large $n$. A heuristic finds a good-enough, not always optimal, solution quickly when no efficient exact algorithm is known.

An algorithm that is slow on one particular input vs.\ one that is inefficient in general --- efficiency is about how runtime scales as $n$ grows large, not about a single run's speed.

Students assume ``brute force'' (checking every possibility) is always bad --- it's the correct choice when $n$ is small enough that its runtime is still reasonable; brute force only becomes impractical as $n$ grows large.

Efficiency = how runtime SCALES with input size, not one run's speed.

Some problems cannot be solved by ANY algorithm, no matter how much time or computing power is available --- these are called undecidable problems, a fundamentally different category from problems that are merely slow.

The classic example is the halting problem: no general algorithm can always correctly determine, for every possible program and input, whether that program will eventually stop running or run forever.

Undecidable (provably impossible for any algorithm to always solve correctly) vs.\ merely inefficient (solvable, just impractically slow) --- more computing power can eventually help an inefficient problem but can never solve an undecidable one.

Students describe a problem as ``undecidable'' just because it's hard or would take a long time to run --- undecidability is a much stronger, formally proven claim, not a synonym for ``difficult.''

Undecidable = provably impossible for ANY algorithm, ever --- not just slow.

A simulation is a computer program that models a real-world or hypothetical process, letting people study, test, or predict outcomes that would be too costly, dangerous, slow, or impossible to test in reality.

Simulations often use randomness (RANDOM(a, b) in AP pseudocode returns a random integer from a to b, inclusive) to model unpredictable real-world variation. Simulations trade off accuracy for speed/cost/safety and always simplify the real system in some way.

A simulation (a simplified, running model used to explore/predict behavior) vs.\ the real phenomenon itself --- a simulation's results are only as trustworthy as the assumptions built into the model.

Students treat a simulation's output as guaranteed real-world fact rather than as a prediction dependent on the model's simplifying assumptions --- the exam rewards recognizing simulation limitations.

Simulations model reality --- faster/safer/cheaper, but only as good as their assumptions.

Testing a program only with ``typical'' expected inputs misses bugs that appear at boundaries or with unusual/random inputs --- robust programs are tested against edge cases and unpredictable input values.

Edge cases include empty lists, the smallest/largest allowed values, zero, and negative numbers where they weren't expected. RANDOM(a, b) is often used in test generation to efficiently try many varied inputs.

Testing with typical/expected values (confirms the ``normal'' case works) vs.\ testing edge/boundary cases (confirms the program doesn't break at the limits) --- both are necessary; passing only typical-case tests does not prove correctness.

A scenario shows a program tested only with a few ``nice'' numbers; students conclude the program is fully correct, missing that it was never tested against an edge case (like an empty list or 0) where it actually fails.

Typical-case tests pass $≠$ program is correct --- always test the edges.

The Internet is a network of independently operating networks that all agree to communicate using shared, open protocols --- no single organization owns or controls it, which is central to its scalability and reliability.

Data sent across the Internet is broken into small units called packets, each labeled with sender/destination addresses, sent independently (possibly by different routes), and reassembled in order at the destination.

The Internet (the global physical/logical network infrastructure --- routers, cables, protocols) vs.\ the World Wide Web (a system of linked documents that runs ON TOP of the Internet using HTTP) --- the Web is one application that uses the Internet, not the Internet itself.

Students use ``Internet'' and ``Web'' interchangeably on questions that specifically distinguish the transport infrastructure from the application layer built on top of it.

Internet = the network. Web = pages/documents that ride on top of it.

A protocol is an agreed-upon set of rules that lets different devices, built by different manufacturers running different software, communicate successfully --- protocols make the Internet's openness and interoperability possible.

TCP/IP breaks data into packets and routes/reassembles them reliably. HTTP/HTTPS governs transferring web pages (the ``S'' adds encryption). DNS (Domain Name System) translates human-readable domain names (example.com) into numeric IP addresses.

An IP address (a numeric identifier for a device on the network) vs.\ a domain name (a human-readable name that DNS translates into an IP address) --- domain names exist only for human convenience; the network actually routes using IP addresses.

A question describes DNS failing or being unavailable, and students think the Internet itself is down --- but the underlying IP-address-based routing can still work; only the human-friendly name lookup fails.

DNS translates names $arrow$ IP addresses, for humans' convenience only.

A fault-tolerant system continues operating correctly even when some individual component fails, by building in redundancy so no single point of failure can bring down the whole system.

The Internet's packet-based, decentralized design provides fault tolerance --- if one router or path fails, packets can be automatically rerouted through other available paths to still reach their destination.

Fault tolerance (the system as a whole keeps working despite a component failing) vs.\ fixing/repairing the failed component itself --- fault tolerance is about resilience and redundancy, not repair.

Students assume fault tolerance means ``the system never has failures'' --- it actually means individual failures are expected and tolerated without taking down the overall system.

Fault tolerance = system survives even when a PART of it fails.

Breaking a large computational problem into smaller pieces that run at the same time (parallel computing) or across multiple separate computers (distributed computing) can solve problems faster than one processor working alone.

Sequential computing performs one task at a time. Parallel computing performs multiple subtasks simultaneously on multiple processors. Distributed computing spreads tasks across multiple independent, often networked, computers to combine their computing power.

Parallel computing (typically multiple processors within one system working simultaneously) vs.\ distributed computing (multiple separate, often geographically spread-out computers cooperating) --- distributed systems add communication overhead that pure parallel systems within one machine don't have.

Students assume splitting any task among more processors always makes it proportionally faster --- the exam tests recognizing that tasks with dependencies (steps that must happen in order) can't be fully parallelized, limiting the speedup.

More processors help only for tasks that can be SPLIT UP --- dependent steps limit the speedup.

Nearly every computing innovation produces a mix of beneficial and harmful effects, often for different groups of people at the same time --- evaluating an innovation means weighing both sides, not assuming new technology is purely good or bad.

The same innovation (social media, GPS, facial recognition, AI-driven algorithms) can be described with legitimate beneficial effects (efficiency, connection, access) AND legitimate harmful effects (privacy loss, job displacement, unequal access, misuse) simultaneously.

An effect being ``unintended'' vs.\ ``harmful'' --- an unintended effect can be beneficial or harmful; the exam separately tests whether students identify effects as intended/unintended AND as beneficial/harmful.

Students pick only the most obvious/well-known effect of an innovation, missing that the correct answer often requires identifying a DIFFERENT effect than the one already described in the question stem.

Every innovation $arrow$ has BOTH benefits and harms, often for different groups.

Unequal access to computing devices, reliable Internet, and the skills to use them creates a ``digital divide'' that can reinforce or worsen existing social and economic inequalities.

The digital divide includes gaps in physical access (devices, broadband) and in the skills/literacy needed to use technology effectively. It can occur across socioeconomic status, geography (urban vs.\ rural), age, and countries (developed vs.\ developing).

The digital divide (unequal ACCESS to computing/Internet) vs.\ the participation gap (unequal ability to meaningfully PARTICIPATE/create using technology even when basic access exists) --- having a device is not the same as having the skills or opportunity to use it fully.

Students assume providing devices alone closes the digital divide --- exam scenarios test recognizing that access without training, infrastructure, or affordability doesn't fully solve the problem.

Digital divide = unequal ACCESS. Closing it needs devices AND skills AND connectivity.

Computing enables crowdsourcing --- gathering input, data, labor, or ideas from a large, distributed group of people, often via the Internet --- to accomplish tasks that would be slow or impossible for a small team alone.

Examples: collaboratively edited encyclopedias, citizen science projects (volunteers classify images/data for researchers), open-source software development, and crowdfunding. Crowdsourcing scales problem-solving but raises challenges around quality control and verifying contributor accuracy.

Crowdsourcing (structured collection of contributions from a large public group toward a specific goal) vs.\ general social media use (posting/sharing without a coordinated collective task) --- crowdsourcing implies an organized project soliciting specific input.

Students assume crowdsourced information is automatically reliable because ``many people contributed'' --- the exam tests recognizing crowdsourced data still needs verification, since more contributors doesn't guarantee accuracy.

Crowdsourcing = many people, one coordinated task --- still needs quality checks.

Creative and computing works (software, images, music, writing) are protected by intellectual property law by default, but creators can choose to share their work more openly using explicit licenses.

Copyright automatically protects original creative work. Open-source software makes source code publicly available to view, use, and modify, often under a specific license. Creative Commons licenses let creators grant specific public permissions (e.g., allow sharing, require attribution, restrict commercial use) while keeping some rights.

``Publicly available online'' vs.\ ``legally free to use/reuse'' --- content being viewable on the Internet does NOT automatically mean it is free of copyright protection or safe to reuse without permission.

Students assume any image or code found online is free to use because it was easy to access --- the exam rewards recognizing that legal reuse requires checking its actual license or copyright status.

Findable online $≠$ free to use. Check the license.

Because data travels across a network many other devices can potentially access, protecting it requires deliberate security measures --- encryption being the primary tool for keeping data confidential in transit or storage.

Encryption scrambles data (plaintext) into unreadable ciphertext using a key, reversible only with the correct key. Symmetric encryption uses the SAME key to encrypt and decrypt (must be securely shared beforehand). Asymmetric (public key) encryption uses a public key to encrypt and a different private key to decrypt, avoiding the need to share a secret key in advance.

Symmetric encryption (one shared secret key for both directions) vs.\ asymmetric/public-key encryption (a public key anyone can use to encrypt, but only the matching private key can decrypt) --- HTTPS relies on public-key techniques to safely establish a shared session key.

Students think a longer/more complex password alone is ``encryption'' --- encryption specifically means mathematically transforming the data itself, not just adding an access barrier like a login password.

Symmetric = 1 shared key. Asymmetric = public key locks, private key unlocks.

Because computing systems store and transmit sensitive personal data, deliberate safe-computing practices --- both technical and behavioral --- are needed to protect that data from unauthorized access or misuse.

Malware is software designed to harm or exploit a system (viruses, worms, ransomware, spyware, keyloggers). Phishing uses deceptive messages/sites to trick people into revealing sensitive info. Multi-factor authentication (2+ independent proofs of identity) protects accounts even if one credential is stolen.

A computer virus (malicious code that attaches to and needs a host program plus user action to spread) vs.\ a worm (self-replicating malware that spreads across a network on its own).

Students label any suspicious email as ``a virus'' --- the exam distinguishes phishing (a social-engineering scam to trick users into revealing info) from malware (malicious code itself) as separate, specifically defined threats.

Virus needs a host + user action. Worm spreads itself, no help needed.

Algorithms and the data used to train/run them are created by people, and can therefore encode and even amplify existing human biases --- producing systematically unfair outcomes for particular groups even when no individual intends harm.

Bias can enter an algorithm through unrepresentative training data, biased design choices (which features to include), or biased human decisions embedded into rules. Once deployed at scale, a biased algorithm can affect enormous numbers of people faster and more consistently than a single biased human decision-maker.

Bias caused by the underlying DATA vs.\ bias caused by the ALGORITHM'S design/rules themselves (which factors to weigh, and how) --- a perfectly unbiased data set can still produce biased outcomes if the algorithm's logic treats groups unfairly.

Students assume ``the computer/algorithm is neutral because it's just math'' --- the exam specifically tests recognizing that algorithms reflect the biases, intentional or not, of their human designers and data.

Algorithms aren't neutral --- they reflect the bias of their data AND their designers.

A short list of numbers and encoding facts shows up repeatedly across the MCQ exam.

$2^n$ values (0 to $2^n-1$); 8 bits/byte; lists start at 1; 70 MCQ/120 min/70%; Create PT/30%/6 pts.

Precision vocabulary is the fastest, cheapest way to gain or lose points on the MCQ exam --- these pairs are the exam's favorite traps.

When two terms sound alike, ask: does it store or compare? Hide detail or add it? One key or two? Access or ability?

The exam frequently tests matching a networking or systems term directly to its role --- memorize this list as pairs.

Client asks, server answers; router forwards; DNS names; API hides; database stores; firewall filters.

AP CSP is language-agnostic, so both the MCQ exam and code-tracing questions use one official pseudocode --- know every symbol and command cold.

$≤ftarrow$ assigns; IF/ELSE selects; REPEAT n TIMES/REPEAT UNTIL/FOR EACH iterate; lists start at 1.

Code-tracing questions reward a consistent, repeatable process for turning unfamiliar pseudocode into a confidently correct final value.

Table $arrow$ line by line $arrow$ old values first $arrow$ re-check every loop pass $arrow$ trace calls fully.

Knowing the exact structure of both the MCQ exam and the Create Performance Task lets you pace your studying and your submission checklist correctly.

MCQ: 70 Qs/120 min/70%. Create PT: code + 1-min video + PPR (code images only) via Portfolio, then 2 written-response Qs during the exam, 6 pts, 30%.

Treating the Create Performance Task as a defined pipeline --- not one big last-minute push --- is what actually satisfies the rubric.

Idea $arrow$ design $arrow$ build in pieces $arrow$ test edge cases $arrow$ record ( 1 min) $arrow$ PPR (code images only) $arrow$ submit final $arrow$ written responses on exam day.

When a question asks you to convert or calculate with binary values and file sizes, use this checklist instead of guessing.

Binary$≤ftrightarrow$decimal via place values; $2^n≥q k$ for bits needed; pixels $×$ bits/pixel $$ 8 = bytes.

These statements sound intuitively true but are exactly the kind of overgeneralization the exam is designed to catch --- know why each is wrong.

Before trusting a ``sounds true'' statement, ask: does it sneak in index 0, partial credit, or ``the computer is neutral''?

5 Big Ideas, 34 topics, one pseudocode standard, 70 MCQ + a 6-point Create PT --- if you can explain WHY each pair above is distinct, you're ready.