- How the Official Objectives Are Organized
- Domain 1: Core Programming Concepts
- Domain 2: Software Development Principles
- Domain 3: Object-Oriented Programming
- Domain 4: Web Applications
- Domain 5: Databases
- Where the Domains Overlap
- Sequencing Your Preparation by Domain
- What the Objective Document Does Not Tell You
- Frequently Asked Questions
- The ITS-SD exam covers five domains: Core Programming Concepts, Software Development Principles, Object-Oriented Programming, Web Applications, and Databases.
- Pearson's official Software Development objectives are unweighted, so no domain has a published percentage of the exam.
- The objective document references C# and ANSI SQL expectations as context, not as additional exam domains.
- Domain 2 is the broadest, with five subtopics spanning SDLC, version control, data structures, and security risks.
How the Official Objectives Are Organized
The Information Technology Specialist - Software Development (ITS-SD) certification is governed by Pearson, and its scope is defined in a published objective document. That document lists five numbered domains, each broken into numbered subtopics (1.1, 1.2, and so on). Those subtopics are the real unit of study. Each one is a compact bundle of related skills, and the exam can draw on any of them.
Two features of the objective document shape how you should read it:
- The objectives are unweighted. Unlike many certifications, there is no published percentage attached to each domain. You cannot safely skip a domain on the assumption that it is a small slice of the exam.
- Technology references are context, not extra domains. The document includes C# and ANSI SQL expectations and mentions prerequisite technologies. These help you understand the depth of knowledge assumed, but they do not form a sixth content area.
If you are still orienting yourself to the credential itself, start with What Is ITS-SD Certification? and then come back here for the detailed breakdown. For a broader preparation plan that wraps around these domains, the ITS-SD Study Guide 2026 pairs well with this article.
Domain 1: Core Programming Concepts
Domain 1 is the foundation. It tests whether you understand how programs actually behave, independent of any specific framework. It has four subtopics.
1.1 Storage, Memory, Data Types, and Garbage Collection
This subtopic covers how values are stored and managed at runtime.
- Distinguish value types from reference types and know how each is stored.
- Understand how data types constrain what you can do with a value, including conversions and precision concerns.
- Explain what garbage collection does, why it exists, and what it means for object lifetime.
1.2 Algorithms, Flowcharts, Decisions, Loops, and Recursion
Here the exam checks your ability to reason about program flow.
- Read and interpret flowcharts, and translate between a flowchart and code logic.
- Trace decision structures and loops to predict output, including off-by-one behavior.
- Recognize when recursion applies, identify the base case, and spot infinite recursion.
1.3 Structured Exception Handling, Testing, and Debugging
Reliability skills show up in this subtopic.
- Understand try/catch/finally flow and which handler runs for a given exception.
- Know the purpose of different testing approaches at the code level.
- Use debugging concepts such as breakpoints and stepping to locate defects.
1.4 Functional Patterns, Events/Delegates/Promises, Asynchrony, and Immutability
This is the most conceptually modern subtopic in Domain 1.
- Understand functional patterns and why immutability reduces certain classes of bugs.
- Differentiate events, delegates, and promises as ways to respond to things that happen later.
- Explain asynchronous execution and why it keeps applications responsive.
Candidates frequently find the code-tracing questions in 1.2 and the asynchrony concepts in 1.4 the most demanding parts of this domain. If you want a realistic sense of the challenge, see How Hard Is the ITS-SD Exam?
Domain 2: Software Development Principles
Domain 2 is the widest domain, with five subtopics that stretch from process to security. It rewards candidates who think like working developers rather than only coders.
2.1 SDLC, Agile Roles, and Testing Types
Expect questions about the stages of the software development life cycle and how Agile teams are organized. You should be able to match roles to their responsibilities and distinguish testing types by what they verify, such as individual units versus integrated behavior versus user acceptance.
2.2 Specifications, Prototypes, Components, and Generative-AI Research
This subtopic covers turning requirements into something buildable. Know the purpose of specifications and prototypes, how reusable components fit into a design, and how generative AI can be used as a research aid. The framing is practical: understand what such tools can help with and why their output still needs verification.
2.3 Data Structures, Searching/Sorting, and Performance
Here you compare structures such as arrays, lists, stacks, queues, and dictionaries by how they store and retrieve data. Pair that with an understanding of searching and sorting approaches and how choices affect performance as data grows.
2.4 Version Control and Collaboration
Know what version control provides: history, branching, merging, and conflict resolution. Questions focus on why teams use these practices and how collaboration workflows prevent people from overwriting each other's work.
2.5 Cryptography and Injection/CSRF/iframe Risks
The security subtopic names specific threats: injection attacks, cross-site request forgery, and risks associated with iframes. You should understand how each attack works at a conceptual level, what mitigation applies, and the basic role cryptography plays in protecting data.
Domain 3: Object-Oriented Programming
Domain 3 is the smallest by subtopic count, with three subtopics, but it is dense. Because the objectives are unweighted, do not assume it counts less.
3.1 Classes, Members, Access, Instantiation, and Composition
The vocabulary of object-oriented design starts here.
- Define a class and distinguish fields, properties, methods, and constructors.
- Apply access modifiers to control visibility and understand why encapsulation matters.
- Differentiate instantiation from definition, and recognize composition as a "has-a" relationship.
3.2 Inheritance and Generic/Abstract Classes
This subtopic tests relationships between types.
- Explain inheritance as an "is-a" relationship and trace how members are inherited.
- Understand abstract classes and why they cannot be instantiated directly.
- Recognize generic classes as a way to write type-flexible code while retaining type safety.
3.3 Overriding, Interfaces, and Overloading
Polymorphism lives in this subtopic.
- Distinguish overriding (replacing inherited behavior) from overloading (same name, different parameters).
- Understand an interface as a contract that implementing classes must satisfy.
- Predict which method executes when a base-type reference points to a derived object.
A common trap is confusing composition with inheritance, or overriding with overloading. Build a short comparison for each pair and test yourself on scenarios rather than definitions.
Domain 4: Web Applications
Domain 4 shifts from language fundamentals to how applications run across a network. It has four subtopics.
4.1 Client/Server Web Technologies, HTTP, Browser Tools, State, and Lifecycle
You need a working model of the request/response cycle: what the client sends, what the server returns, and how HTTP methods and status codes communicate intent and outcome. Browser developer tools appear here as a diagnostic skill. State and lifecycle questions probe how a stateless protocol is made to feel stateful, and what happens to a page or request from start to finish.
4.2 Hosting and Deployment
This subtopic covers getting an application onto a server where users can reach it. Understand the concepts of hosting environments and the deployment process, including why environments are separated and what changes between development and production.
4.3 Web Services and Formats/Protocols
Web services let applications talk to one another. Know the common data formats used to exchange information and the protocols that carry those messages, and be able to explain when a service-style architecture is appropriate.
4.4 MVC/MVVM/SPA Patterns
Architectural patterns organize code so that presentation, logic, and data stay separate. Distinguish Model-View-Controller from Model-View-ViewModel, and understand what makes a single-page application different from a traditional multi-page site.
| Pattern | Core Idea | What to Be Able to Explain |
|---|---|---|
| MVC | Controller mediates between model and view | Which component handles user input and which renders output |
| MVVM | ViewModel exposes data and commands to the view | How data binding reduces direct view-to-model code |
| SPA | One page loads once and updates dynamically | How it differs from full page reloads on each navigation |
Domain 5: Databases
Domain 5 has five subtopics and ties together design, query, and application-level data access. The objective document's ANSI SQL expectations live here.
5.1 Relational Design, Normalization, Keys, and Relationships
Good schema design underpins everything else in this domain.
- Identify primary and foreign keys and explain what each enforces.
- Describe one-to-one, one-to-many, and many-to-many relationships.
- Understand why normalization reduces redundancy and what anomalies it prevents.
5.2 ANSI SQL and Stored Procedures
Hands-on query reading and writing is central.
- Read and write SELECT, INSERT, UPDATE, and DELETE statements.
- Understand joins, filtering, grouping, and ordering at a working level.
- Explain what a stored procedure is and why teams use them.
5.3 Transactions and Isolation
Data integrity under concurrent use.
- Explain a transaction as an all-or-nothing unit of work.
- Understand commit and rollback behavior.
- Describe isolation levels conceptually and the read problems they prevent.
5.4 Entity Framework, Pools, and LINQ
Where code meets data.
- Understand what an object-relational mapper does and why developers use one.
- Recognize connection pooling as a performance and resource technique.
- Read LINQ queries and relate them to the underlying data operations.
5.5 Document and Key-Value Databases
Non-relational alternatives.
- Contrast document and key-value stores with relational databases.
- Know the kinds of workloads that suit each model.
- Understand the tradeoffs in structure, flexibility, and querying.
Where the Domains Overlap
The five domains are listed separately, but real exam scenarios often cross boundaries. Recognizing these connections helps you answer scenario questions that do not announce which domain they belong to.
| Connection | Domains Involved | Why It Matters |
|---|---|---|
| Injection and SQL queries | 2.5 and 5.2 | Security risks are exploited through database access, so safe query construction is a shared concern. |
| Async behavior and web requests | 1.4 and 4.1 | Promises and asynchrony explain why web calls do not block the interface. |
| Abstraction and architecture patterns | 3.3 and 4.4 | Interfaces and separation of concerns underpin MVC and MVVM. |
| Data structures and database design | 2.3 and 5.1 | Choosing how to organize data applies at both the in-memory and persistent level. |
| Exceptions and transactions | 1.3 and 5.3 | Rolling back on failure combines error handling with data integrity. |
Key Takeaway
When you finish a subtopic, ask which other domain it touches. Writing one linking note per pair, such as exceptions and rollback, converts isolated facts into the connected understanding scenario questions demand.
Sequencing Your Preparation by Domain
Because the domains build on one another, order matters more than raw hours. The sequence below follows the dependencies in the objective document: fundamentals first, then object-oriented design, then the applied web and data domains that rely on them. Adjust the pacing to your background and your test date; ITS-SD Exam Dates 2026 covers scheduling.
Domain 1: Core Programming Concepts
- Trace loops, decisions, and recursion by hand before running any code.
- Write small programs that demonstrate exceptions and value versus reference behavior.
- Explain events, delegates, promises, and asynchrony in your own words.
Domain 2: Software Development Principles
- Map SDLC stages and Agile roles to a sample project.
- Practice basic version control workflows including a deliberate merge conflict.
- Study injection, CSRF, and iframe risks with their mitigations side by side.
Domain 3: Object-Oriented Programming
- Build a small class hierarchy using inheritance, an abstract class, and an interface.
- Contrast overriding with overloading using concrete examples.
- Rework one design using composition instead of inheritance.
Domain 4: Web Applications
- Inspect real requests in browser tools and note methods, headers, and status codes.
- Compare MVC, MVVM, and SPA structures.
- Review hosting, deployment, and web service formats.
Domain 5: Databases
- Design a normalized schema and write ANSI SQL against it.
- Walk through a transaction with a deliberate failure and rollback.
- Read LINQ queries and compare relational with document and key-value models.
After the first pass, spend remaining time on mixed practice so you stop knowing which domain a question comes from. The ITS-SD practice tests are useful for exactly this. For a condensed refresher before test day, the ITS-SD Cheat Sheet pulls the key facts onto one page.
What the Objective Document Does Not Tell You
It is worth being clear about the limits of the official objectives. The Pearson objective document defines scope. It does not establish several details candidates often ask about:
- The current exam fee.
- The number of items on the exam.
- The time allowed.
- The passing threshold.
- A published pass rate.
- Renewal terms.
The document's 2025 copyright also does not establish an exam-version year, so do not assume the objectives belong to a particular release. Treat the objective list as your authoritative scope, and confirm logistics through the official registration channel at the time you schedule. For what is and is not publicly known, see ITS-SD Certification Cost, ITS-SD Passing Score, and ITS-SD Pass Rate.
If you are weighing whether the credential fits your goals, the ITS-SD Requirements article covers eligibility and prerequisites, and ITS-SD Jobs discusses how the skills map to roles. The programming, web, and database topics map closely to entry-level software developer work, which is why the exam is aimed at early-career developers and students building a foundation.
Frequently Asked Questions
The official Software Development objectives list five domains: Core Programming Concepts, Software Development Principles, Object-Oriented Programming, Web Applications, and Databases. Each domain is divided into numbered subtopics that define the specific skills tested.
No. Pearson's published objectives for Software Development are unweighted, meaning no percentage is assigned to each domain. Because of this, prepare for all five domains rather than concentrating on one.
The objective document includes C# and ANSI SQL expectations and references prerequisite technologies. These provide context for the depth of knowledge assumed and are not separate domains. Expect to read and reason about code and SQL statements within the five domains.
Domain 2, Software Development Principles, and Domain 5, Databases, each have five subtopics. Domain 3, Object-Oriented Programming, has the fewest with three. Since the objectives are unweighted, subtopic count should not be read as a measure of exam emphasis.
The objective document does not establish these details, so confirm them through the official Pearson registration process when you schedule. This guide deliberately avoids stating figures that the source does not support.