Scripting and Programming Foundations (D278) Exam Topics and Questions

This topic puts you in the position of matching a scripting or programming approach to a stated need. The exam is not asking you to write code from scratch; it is asking whether you can look at a requirement and identify which type of script, language category, or automation tool fits it. That distinction trips up candidates who study syntax but never step back to think about why a particular tool exists in the first place.

The examinable skill here is purposeful selection. You need to know what shell scripts, batch files, interpreted scripts, and compiled programs each do well, and more importantly where each one breaks down. A requirement that involves rapid system administration on a Unix host points somewhere different from one that involves a portable, user-facing GUI application. The exam will give you a described requirement and expect you to map it to the right category.

Pay attention to constraints buried in the requirement: operating system, execution environment, whether the task is one-off or recurring, and whether performance or portability matters more. Candidates who read requirements loosely and jump to a familiar tool tend to lose marks here. Read the requirement precisely, then match.

How Identifying Scripts for Computer Program Requirements is tested

Items in this topic present a short scenario describing what a program or script must accomplish, then ask you to identify the most appropriate scripting approach, language type, or tool. The demand is on purposeful reasoning: you must connect the requirement to the right category, not just recall a definition.

Candidates lose marks by defaulting to whichever language they know best rather than reading what the scenario actually requires. An item may describe an environment or constraint that rules out an otherwise familiar choice. Items reward reading every constraint in the scenario before committing to an answer.

Watch for requirements that mention a specific operating system, a performance ceiling, or a portability need. Each of those details narrows the field. Candidates who treat the scenario as background noise and focus only on the question stem tend to miss those signals. The strongest responses come from candidates who treat the requirement description as the primary evidence.

Where the previous topic asks you to choose a tool, this one asks you to read code-like logic and trace what it produces. The word "simple" in the topic name is not a promise of easy marks; it means the algorithms are short enough to trace by hand, which is exactly what the exam expects you to do. Candidates who try to pattern-match to a remembered answer instead of actually tracing execution are the ones who get this wrong.

The domain covers sequence, selection, and iteration: the three building blocks that appear in every algorithm regardless of language. You need to be comfortable stepping through conditional branches and loops, tracking variable values as they change, and stating what the algorithm outputs or does at the end. Off-by-one errors in loop boundaries and misread conditional logic are where marks disappear.

How Explaining Logic and Outcomes of Simple Algorithms is tested

Items present pseudocode or a short algorithm and ask what the output is, what a variable holds after execution, or what happens under a specific condition. The exam is testing trace skill, not vocabulary. You do not need to name the pattern; you need to follow it.

The most common trap is skimming the loop boundary or the conditional operator. A loop that runs while a counter is less than a value behaves differently from one that runs while it is less than or equal to it, and items are written to exploit that difference. Items reward candidates who step through execution one line at a time rather than estimating the result.

A second trap is assuming the algorithm does what its variable names suggest. If a variable is called "total" but the logic never adds to it inside the loop, the output reflects what the code says, not what the name implies. Read the logic, not the intent.

After tracing algorithms in the previous topic, this topic pulls back to the conceptual layer that underlies every scripting and programming decision you will make. It covers the vocabulary and mental models that programmers use before they write a single line: data types, variables, operators, the difference between compiled and interpreted execution, and the relationship between source code and a running process.

The risk here is assuming you already know this material because you have written code before. Practical experience and exam-level precision are not the same thing. The exam will probe whether you can state exactly what a data type determines, or exactly what happens at each stage of interpretation, not whether you can write a working script.

How Scripting and Programming Foundations is tested

Items in this topic test definitional precision and conceptual boundaries. You may be asked to identify which data type is appropriate for a given value, distinguish between how a compiled language and an interpreted one handle source code, or recognise what an operator does to its operands in a specific context.

Candidates lose marks by treating this topic as pure memorisation and then freezing when a question applies a concept to an unfamiliar example. The exam rewards candidates who understand why a concept works the way it does, not just what it is called.

Pay particular attention to type behaviour: what operations are legal between types, what happens when types are mixed, and what a variable declaration actually reserves. These details appear in scenario-based items where the concept is applied rather than named. Candidates who can only recall the label but not the behaviour tend to miss those applications.

This topic is where the conceptual groundwork from earlier topics meets applied execution. You are expected to demonstrate that you can use programming elements correctly: control structures, functions, input and output operations, and basic data structures. The shift from "explain" to "use" is deliberate. Items here are less likely to ask you to define a loop and more likely to show you one and ask what it does, or show you a broken one and ask what is wrong.

Candidates who coasted through the earlier topics on recognition will feel the increase in demand here. You need to be comfortable enough with these elements to evaluate their behaviour under specific conditions.

How Using Fundamental Programming Elements is tested

Items present code fragments, pseudocode scenarios, or described program behaviours and ask you to evaluate correctness, identify errors, or determine output. The topic rewards candidates who can hold a mental model of program state as elements interact, not just those who can name the elements.

Control flow is the most fertile ground for traps. A nested conditional or a loop with a non-obvious exit condition will behave in ways that differ from a quick read. Items reward stepping through the logic rather than reading for intent.

Functions are another area where precision matters. Scope rules, parameter passing, and return values each have specific behaviours that the exam will probe with applied scenarios. Candidates who are vague on what a function receives versus what it can access tend to choose poorly when the item hinges on that boundary.

Going into this topic with timed practice already behind you puts you in a much stronger position than arriving cold.