Secure Software Design (D487) Exam Topics and Questions

Architecture and design is where security decisions get locked in earliest and cost the most to reverse. This topic tests whether you understand how structural choices, made before a single line of code is written, shape what the finished system can and cannot protect. Expect to reason about trade-offs between quality attributes, the relationship between requirements and architectural decisions, and how design documentation communicates intent to everyone who builds on top of it. Gaps here ripple through every topic that follows.

The exam treats architecture as a decision-making discipline, not a drawing exercise. You need to know why a given structural choice was made, what it trades away, and how it constrains later design. Quality attributes such as modifiability, availability, and security are not independent: satisfying one often strains another, and the exam will put you in situations where you have to weigh them. Understand how architectural drivers emerge from stakeholder concerns, and how views and viewpoints let different audiences reason about the same system without talking past each other. The connection between requirements, constraints, and architectural style is the core of this topic.

How Software Architecture and Design is tested

Items in this area reward your ability to connect a stated requirement or quality concern to an appropriate architectural decision. The trap is treating architecture as a purely technical exercise: items are written around stakeholder concerns, conflicting quality attributes, and the consequences of deferring a decision. Candidates who memorise definitions without understanding trade-offs tend to pick options that satisfy one quality attribute while silently breaking another.

Expect scenarios where you must identify which architectural decision is responsible for a system's weakness, or choose the design approach that best satisfies a given set of constraints. Items reward recognising that architectural decisions have downstream effects on testability, security, and maintainability. The most common place candidates lose marks is failing to account for all the stated constraints in a scenario, picking a solution that works in isolation but conflicts with something the question has already told them about the system.

Where the previous topic focuses on how architectural decisions are made, this one tests whether you can distinguish the major structural patterns and know when each is appropriate. Layered, event-driven, microservices, service-oriented, pipe-and-filter, and similar styles each carry specific security and reliability implications. The exam is not interested in whether you can define them: it wants to know whether you can match a style to a problem, or identify why a chosen style creates a particular vulnerability or operational constraint.

How Software Architecture Types is tested

Items here typically present a system description and ask you to identify the architecture style in use, evaluate its suitability, or explain a consequence of that style. The reward goes to candidates who understand the operational and security characteristics of each type, not just its structural diagram.

The most common trap is confusing styles that share surface features. Microservices and service-oriented architecture look similar on paper but carry different assumptions about service granularity, data ownership, and failure isolation. Event-driven architectures introduce asynchronous complexity that changes how you reason about data integrity. Items will probe whether you know what a style implies for attack surface, fault containment, and scalability, not just how it looks in a box-and-arrow diagram. Candidates lose marks by selecting a style that solves the functional requirement while ignoring the non-functional constraints the scenario specifies.

Design patterns sit one level below architecture: they solve recurring structural problems within a system rather than shaping the whole. This topic tests whether you can select the right pattern for a given problem and understand the security implications of how it is implemented. Knowing a pattern's name is not enough. The exam will put you in a scenario with a specific constraint or threat and expect you to reason about which pattern addresses it and what that pattern introduces in return.

How Design Pattern Selection and Implementation is tested

Items reward selecting a pattern based on the problem's actual constraints, not on familiarity. A scenario might describe a system where object creation needs to be controlled to prevent unauthorised instantiation, or where behaviour needs to change at runtime without altering the class hierarchy. The correct move is to identify what structural problem is really being described, then match it to the appropriate pattern.

The trap is pattern-matching on surface keywords rather than on the underlying problem. Candidates who have memorised pattern definitions without understanding their intent will pick the pattern whose name sounds closest to the scenario's vocabulary. Items also test implementation consequences: using a Singleton in a multi-threaded context, for example, introduces race conditions that a candidate who only knows the pattern's intent will miss. Marks are lost when candidates ignore the second half of the question, selecting the right pattern but failing to account for what its implementation requires in the stated environment.

Scale changes the rules. Decisions that work cleanly for a single-server system break down when the system spans multiple nodes, geographic regions, or millions of concurrent users. This topic tests your ability to reason about distribution, data consistency, fault tolerance, and the security challenges that emerge when components are separated by networks. The exam expects you to move past single-system thinking and evaluate design choices in terms of what happens when load spikes, nodes fail, or network partitions occur.

How Large Scale Software System Design is tested

Items in this area present scenarios involving distributed components, high availability requirements, or data that must remain consistent across replicas. They reward candidates who understand that at scale, failures are not edge cases: they are design inputs. You need to reason about replication strategies, load balancing, caching, and the consistency-availability trade-off that CAP theorem describes.

The trap is applying single-system intuitions to distributed problems. Candidates lose marks by selecting designs that assume synchronous communication is always available, or that a single authoritative data store is always the right choice. Security at scale also behaves differently: attack surfaces multiply with each additional service endpoint, and authentication schemes that work for a monolith become bottlenecks or weak points in a distributed system. Items will probe whether you understand how scale amplifies both operational risk and security exposure, not just how to add more servers.

Building a system correctly is only part of the job. This topic shifts attention to keeping it running, observable, and under control once it is deployed. Expect questions on monitoring, configuration management, deployment pipelines, and the operational practices that keep a system's security posture intact over time. The connection to earlier topics is direct: architectural decisions made in topics 1 through 4 determine how easy or difficult management becomes, and the exam will test whether you can trace that relationship.

How Software System Management is tested

Items here reward understanding that management is a security concern, not just an operational one. Configuration drift, unmanaged secrets, missing audit logs, and poorly designed deployment pipelines all create vulnerabilities that attackers exploit. Scenarios will describe a system in operation and ask you to identify what management practice is absent or flawed, or to choose the approach that preserves security properties during updates and configuration changes.

The trap is treating management as purely administrative. Candidates who think of this topic as IT operations rather than secure software practice tend to overlook the security implications of the choices presented. Items will also test your understanding of how observability, the ability to infer internal state from external outputs, differs from simple logging. Marks are lost when candidates select monitoring or configuration approaches that would work operationally but create gaps in auditability or expose sensitive system information through poorly scoped access to management interfaces.

Reliability and security are often treated as separate concerns, but this topic tests whether you understand how deeply they interact. A system that fails unpredictably is a system that becomes vulnerable: availability attacks exploit reliability weaknesses, and security controls that degrade under load are no controls at all. This final topic draws on every area covered before it, asking you to evaluate designs for both their ability to withstand failure and their ability to resist attack, simultaneously.

How Reliable and Secure Software Systems is tested

Items reward candidates who can evaluate a design holistically, identifying where a reliability weakness creates a security exposure and vice versa. Fault tolerance mechanisms, redundancy strategies, graceful degradation, and secure failure modes are all fair game. The exam will present systems that look secure until a failure scenario is introduced, or that look reliable until a threat model is applied.

The trap is evaluating reliability and security in isolation. Candidates who treat them as independent checklists will miss scenarios where a redundancy mechanism introduces a new attack surface, or where a security control becomes a single point of failure. Items also test secure failure behaviour: a system that exposes sensitive data or drops security controls when it encounters an error is failing on both dimensions at once. Marks are lost when candidates select designs that handle the primary scenario correctly but ignore the failure path, which is precisely where this topic's items are designed to probe.