Security Architecture Modeling practice questions

NIST SP 800-30

Why it fails: NIST Special Publication 800-30 focuses on conducting risk assessments to identify vulnerabilities and threats within an organisation's IT infrastructure, making it tempting when evaluating overall system exposure. However, it fails in this architectural design scenario because it provides a methodology for risk management rather than a concrete technical framework for cloud computing reference architectures. It would be the correct choice if the objective were to determine organisational risk levels and threat probabilities for an existing operational system rather than blueprinting cloud security controls.

NIST SP 800-53

Why it fails: While NIST Special Publication 800-53 provides a comprehensive catalogue of security and privacy controls for federal information systems, it focuses on general compliance and baseline hardening rather than architectural topology. It is often considered because security professionals frequently rely on its exhaustive control catalog for system authorisation. It would be the correct choice if the primary requirement were selecting and auditing specific administrative, technical, and physical safeguards for an existing information system rather than designing a foundational cloud reference architecture.

NIST SP 800-160

Why it fails: NIST SP 800-160 addresses systems engineering design principles for trustworthy secure systems rather than cloud-specific architectures. It is tempting because its title mentions system security engineering, making it seem applicable to any comprehensive design task. It would be the correct choice if the scenario asked to establish a rigorous, lifecycle-based engineering methodology for developing bespoke hardware and software products from scratch, rather than defining structural security patterns for multi-tenant cloud environments.

Load Balancing

Why it fails: This is for availability, not isolation.

VPN

Why it fails: This is for secure transport, not network isolation.

Microsegmentation

Why it fails: Microsegmentation isolates workloads at the host level, but DMZ is the broader structural pattern.

Clause 10

Why it fails: This covers improvement.

Clause 4

Why it fails: This covers context of the organization.

Clause 8

Why it fails: This covers operation.

Gap Analysis

Why it fails: Gap analysis functions as a component within the Architecture Definition Document rather than its primary deliverable. It is tempting because it represents a critical analytical phase during the TOGAF Architecture Development Method, specifically when identifying differences between baseline and target architectures. Practitioners often associate this document with the transition planning process, yet it serves as a supporting technique to identify missing requirements rather than acting as the overarching repository for the complete architectural vision and definition.

Security Policy

Why it fails: Security policies function as governance instruments defining organisational rules and compliance mandates rather than capturing the structural baseline or target state of an enterprise architecture. While they provide the essential constraints that architects must integrate into their designs, they exist as external regulatory frameworks rather than the descriptive architectural artifacts produced during the Architecture Development Method. They become the correct choice when defining the security posture or compliance requirements that a proposed architectural design must satisfy to remain within organisational risk appetite.

Risk Register

Why it fails: The Risk Register tracks identified threats and mitigation strategies throughout the architecture development cycle, whereas the Architecture Definition Document functions as the primary repository for the baseline and target architecture models. While practitioners frequently maintain a Risk Register alongside the Architecture Definition Document to manage project constraints, it serves as a supporting governance artefact rather than a structural component of the architectural design itself. It becomes the primary deliverable only when the specific objective is to document project-level risk exposure and mitigation status.

Network perimeter defense

Why it fails: Trike prioritises risk management by balancing security requirements with business objectives, rather than focusing on infrastructure-level hardening. Network perimeter defence addresses ingress and egress traffic control, which is the primary concern for firewall-centric methodologies or boundary protection assessments. While perimeter security remains a vital component of a defence-in-depth strategy, Trike specifically evaluates the risk exposure of assets based on their value to the organisation, rendering a purely technical focus on network boundaries insufficient for this specific threat modelling framework.

Code vulnerability discovery

Why it fails: Trike prioritises risk management and the alignment of security requirements with business assets rather than performing static analysis of source code. This option is tempting because developers often conflate threat modelling with automated security testing; however, code vulnerability discovery relies on tools like SAST to identify syntax-level flaws. While such scanning is essential during the development lifecycle to ensure secure implementation, it operates at the granular implementation layer, whereas Trike functions at the architectural level to define risk-based security objectives.

Attack simulation

Why it fails: Trike focuses on risk-based threat modelling using a requirements model and CRUD matrix to enumerate threats against assets, not on simulating attacks. Attack simulation describes penetration testing or adversary emulation, so it misidentifies Trike's actual analytical purpose.

Shared Responsibility Model

Why it fails: Documenting the Shared Responsibility Model is essential because compliance frameworks such as ISO/IEC 27001 and PCI-DSS mandate strict demarcation of security controls between cloud service providers and tenants. Satisfying the compliance constraint in the stem requires explicitly mapping out boundary definitions—such as differentiating infrastructure-level patching managed by the vendor from application-level identity provisioning managed by the customer—thereby proving due diligence during regulatory audits.

Cloud vendor pricing

Why it fails: While commercial models and cost tiers dictate procurement budgets, they have no bearing on regulatory audits, data residency controls, or statutory obligations. Financial schedules are typically tracked for procurement forecasting, departmental accounting, and resource optimisation, making them essential when planning cloud expenditure or evaluating total cost of ownership rather than satisfying data governance frameworks.

Employee names

Why it fails: Listing individual employee names fails to satisfy compliance requirements because regulatory frameworks mandate the documentation of abstract technical controls, data flows, and system configurations rather than personnel rosters. This option appears tempting because personnel records are vital for internal human resources tracking, security clearance validation, and assigning administrative accountability. Such information becomes the correct focus when auditing access control lists, ensuring segregation of duties, or verifying background screening compliance during operational reviews, but it does not map the system architecture components required for technical compliance auditing.

Requirements Management

Why it fails: Requirements Management acts as a continuous process facilitating the evolution of the architecture rather than performing the structural integration of security controls. While it governs the lifecycle of requirements, it lacks the specific architectural design and implementation focus required to embed security frameworks into the enterprise. It becomes the correct choice when the objective is to manage the traceability and prioritisation of stakeholder needs throughout the ADM cycle, ensuring that evolving business demands remain aligned with the overarching strategic vision of the organisation.

Preliminary Phase

Why it fails: Important, but A and E are primary for integration.

Implementation Governance

Why it fails: Implementation Governance occurs too late in the TOGAF Architecture Development Method cycle to establish foundational security architecture, focusing instead on ensuring deployed solutions conform to previously approved enterprise blueprints. This phase appears tempting because security controls must ultimately be enforced and governed throughout operational rollout. It would represent the correct choice in a scenario addressing compliance monitoring, change management, or post-implementation oversight of deployed IT systems rather than the initial integration of security requirements during enterprise architecture design.

Conceptual Layer

Why it fails: Fails this scenario because the conceptual layer addresses the contextual 'Why' from the business stakeholder viewpoint rather than the operational 'What' required to define security services. It is tempting because it occupies the highest tier of the framework and deals directly with overarching business strategies, making it the correct choice when mapping high-level drivers, operational risks, and business values before translating them into architectural requirements.

Physical Layer

Why it fails: Mapping the 'What' perspective requires defining operational business processes rather than infrastructure components, rendering the physical layer incorrect because it implements tangible hardware and spatial controls rather than abstract business requirements. This choice is tempting because it addresses tangible asset protection, and it would be the correct answer if the question asked which layer specifies the physical devices, server locations, and environmental mechanisms required to safeguard operational hardware.

Logical Layer

Why it fails: This layer fails because it defines abstract information systems and data architectures rather than addressing the contextual business requirements. It would be tempting because practitioners often conflate business-level operations with conceptual data structures, but it actually represents the 'What' from an ICT architectural perspective. This layer becomes the correct choice when mapping abstract operational concepts into platform-agnostic software components and data models, sitting between the conceptual view and the physical infrastructure implementation.

To reduce software defects

Why it fails: Reducing software defects is the objective of the Capability Maturity Model Integration (CMMI) within software engineering lifecycles, where it focuses on process improvement to minimise bugs. However, in Enterprise Security Architecture, the primary goal shifts to assessing the maturity and consistency of security processes across the entire organisation. While CMMI is tempting because it shares a name with process-based frameworks, it fails here because it prioritises development output quality rather than the holistic governance and risk management capabilities required by security architects.

To purchase better hardware

Why it fails: Purchasing hardware focuses on capital expenditure and physical infrastructure procurement rather than the systematic evaluation of process institutionalisation required by the Capability Maturity Model. While organisations often upgrade physical assets to meet performance requirements or lifecycle management goals, this activity addresses resource acquisition rather than the assessment of organisational process repeatability, standardisation, and optimisation. Consequently, hardware procurement lacks the necessary framework to measure the evolution of security governance, which remains the fundamental objective of maturity modelling within an enterprise security architecture.

To identify all existing threats

Why it fails: Identifying all existing threats falls under vulnerability assessment and threat modelling frameworks rather than the Capability Maturity Model integration, which instead focuses on evaluating and improving process optimisation. This option appears tempting because comprehensive threat identification remains a foundational component of enterprise security governance, making it a logical choice for questions concerning risk profiling, attack surface reduction, or security testing methodologies rather than developmental maturity progressions.

Risk Analysis

Why it fails: Risk Analysis belongs to Stage 6 of the PASTA framework, where vulnerabilities and threat simulations are evaluated against potential business impacts to calculate residual risk, meaning it is premature for Stage 2. This option is tempting because risk analysis is a fundamental pillar of overall threat modelling and information security governance. It would be the correct choice when attempting to quantify the likelihood and severity of identified threat scenarios against business assets during the later stages of the methodology.

Business Impact Analysis

Why it fails: Business Impact Analysis is incorrect because Stage 2 of the PASTA framework focuses on defining technical scope and application objectives rather than calculating financial losses or operational downtime. This option is tempting because it naturally sounds like a crucial early-stage governance task related to risk management. It would be the correct choice when organisations need to identify critical business functions and recovery time objectives to satisfy overarching business continuity and disaster recovery requirements, rather than mapping application architecture and decomposition boundaries for threat simulation.

Threat Analysis

Why it fails: Stage 2 of the PASTA framework focuses strictly on defining the technical scope and boundary conditions of the application, meaning threat analysis occurs much later in the process. This option is tempting because threat analysis forms the core methodology of the broader framework and must be performed during security assessments. It would be the correct answer if the question asked about Stage 4, where potential attack scenarios and threat vignettes are explicitly generated and analysed against the defined architecture.

Information Disclosure

Why it fails: Information disclosure involves the unauthorised exposure of sensitive data rather than the acquisition of elevated privileges. This option appears relevant because attackers often exfiltrate credentials to facilitate further compromise; however, it addresses the confidentiality breach resulting from a leak rather than the act of identity spoofing. It would be the correct choice if the scenario described an attacker intercepting cleartext passwords or reading private database records, such as those stored within Microsoft Entra ID, without necessarily assuming an administrative role.

Spoofing

Why it fails: Spoofing focuses on the falsification of identity, such as masquerading as a legitimate user or device to bypass authentication mechanisms. While this option appears relevant because the attacker assumes an administrative role, the scenario describes an escalation of privilege rather than a simple identity deception. Spoofing would be the correct classification if an attacker successfully impersonated a valid administrator’s credentials to gain entry to a system, such as through a forged token or a compromised Microsoft Entra ID session.

Denial of Service

Why it fails: Denial of Service fails this scenario because it involves the disruption or exhaustion of system resources rather than the unauthorized escalation of privileges. This category is tempting because attackers often compromise high-level accounts to halt operations or crash critical infrastructure; it would be the correct choice if the question described an actor flooding a login portal with authentication requests to prevent legitimate administrators from accessing the console.

Business Architecture

Why it fails: Business Architecture focuses on defining the organisational structure, processes, and governance models rather than establishing the initial project boundaries or stakeholder engagement strategies. It becomes the primary focus during Phase B, where the architect must detail the business strategy and functional requirements once the project scope has been formally authorised. While it provides essential context for the enterprise, it lacks the specific mechanisms required to initiate the Architecture Project or establish the governance framework mandated during the preliminary scoping activities of Phase A.

Transition Planning

Why it fails: Transition Planning focuses on the migration strategy and the sequencing of work packages during Phase E and F, rather than the initial scoping or stakeholder identification required in Phase A. It appears relevant because candidates often associate the creation of an architecture roadmap with the broader project lifecycle. However, this phase is specifically utilised to manage the transition from the baseline to the target architecture, whereas Phase A establishes the foundational project parameters and governance structure necessary to initiate the development cycle.

Architecture Requirements Repository

Why it fails: The Architecture Requirements Repository serves as a central store for architectural outputs and governance records rather than acting as a mechanism for stakeholder engagement or scoping activities. While it is essential for managing the lifecycle of architectural artefacts and ensuring traceability across the ADM cycle, it lacks the functional processes required to define project boundaries or identify relevant stakeholders during Phase A. This repository is the correct choice when an architect needs to retrieve historical requirements or archive finalised documentation for future reuse.

Storing source code

Why it fails: The Architecture Repository functions as a knowledge base for architectural assets, standards, and governance models rather than a version control system for software development. Storing source code falls under the remit of a Software Configuration Management (SCM) tool, such as Git or Subversion, which manages build artifacts and code branches. While developers frequently use repositories to track application logic, the TOGAF Architecture Repository focuses on high-level enterprise blueprints, reference architectures, and compliance requirements, which are distinct from the functional codebases managed by SCM platforms.

Logging security events

Why it fails: Logging security events falls under the remit of a Security Information and Event Management (SIEM) system or centralised log management platform, not the Architecture Repository. Candidates often conflate these because both involve data storage within an enterprise environment. However, the Architecture Repository is strictly a knowledge base for architectural assets, standards, and governance artefacts. If the question required a mechanism for auditing access or monitoring threat vectors, a solution like Microsoft Entra ID logs would be the relevant technical component.

Defining business requirements

Why it fails: Business requirements are captured during the Preliminary Phase and Phase A of the Architecture Development Method, rather than being defined within the Architecture Repository. This option is tempting because the Repository serves as a central library for storing architectural assets, standards, and governance models that inform the development of requirements. It functions as a knowledge base for reusable components and historical artefacts, providing the necessary context to ensure that business requirements align with established enterprise standards and existing architectural patterns.

To manage incidents

Why it fails: Incident management focuses on the reactive mitigation of active threats, whereas a Security Reference Architecture provides a static, structural blueprint for enterprise-wide security design. This option fails because it addresses operational response rather than the foundational standardisation of security controls. It remains a tempting distractor because incident response plans often rely on the architectural visibility defined within an SRA to identify affected assets. Organisations would utilise incident management platforms, such as a SIEM or SOAR, when an active security breach requires immediate containment and remediation.

To configure firewalls

Why it fails: Configuring firewalls involves defining packet-filtering rules and access control lists to manage network traffic at layer 3 and 4 boundaries, which is an operational implementation task rather than the establishment of an overarching design blueprint. Firewalls would be the correct focus if the scenario specifically addressed perimeter defence deployment or boundary enforcement rather than the development of an enterprise-wide structural model for security integration.

To identify vulnerabilities

Why it fails: Identifying vulnerabilities focuses on discovering security flaws through testing methodologies like penetration testing or code review, which addresses tactical weaknesses rather than structural design. This option is tempting because architects must account for vulnerabilities when designing systems, making it the correct goal for assessment tools like vulnerability scanners or threat modeling exercises that evaluate existing implementations against known exploits, whereas a Security Reference Architecture establishes a structural blueprint and baseline controls before implementation occurs.

Hardened build server

Why it fails: Hardening a build server protects the integrity of the build environment against local tampering or lateral movement, but it does not validate the authorisation of the deployment process itself. While this control is essential for ensuring that build tools remain free from malware or unauthorised configuration changes, it fails to verify the identity and permissions of the actor initiating the release. Implementing robust access controls, such as multi-factor authentication via Microsoft Entra ID, provides the necessary governance to prevent unauthorised deployments.

Automated scanning

Why it fails: Automated scanning identifies vulnerabilities like insecure dependencies or hardcoded secrets within the source code but lacks the capability to verify the authorisation of the deployment process itself. Security teams rely on this control to enforce secure coding standards during the build phase, making it a vital component of DevSecOps. However, it cannot prevent an unauthorised actor from triggering a deployment if they possess the necessary credentials, whereas robust identity-based access controls, such as those managed via Microsoft Entra ID, are required to restrict deployment permissions.

Encryption at rest

Why it fails: Encryption at rest protects the confidentiality of stored data, such as source code repositories or build artifacts, against physical theft or unauthorised disk access. While it prevents data leakage from compromised storage media, it does not validate the identity of users or the integrity of the deployment process. This control is essential for regulatory compliance and protecting sensitive intellectual property, but it fails to provide the authentication or authorisation mechanisms required to prevent an unauthorised actor from triggering a pipeline deployment.

Network diagram

Why it fails: Network diagrams focus on physical or logical connectivity between infrastructure nodes, such as routers and subnets, rather than the application-level data flows required for threat modelling. While they effectively map network topology and firewall boundaries to identify potential perimeter exposure, they fail to capture the granular service-to-service communication paths or API call chains essential for identifying application-specific vulnerabilities. They serve as a foundational reference for infrastructure security audits but lack the semantic detail necessary to visualise how data traverses individual application components.

Gantt chart

Why it fails: Gantt charts track project schedules and task dependencies over a timeline, failing to map the logical or physical network connections required for threat modelling. While they effectively visualise project milestones and resource allocation during the planning phase of a development lifecycle, they lack the architectural primitives—such as data trust boundaries or communication protocols—necessary to identify potential attack vectors between cloud-native microservices. Consequently, they provide no insight into the data flow paths essential for conducting a structured security analysis of an application's infrastructure.

Entity Relationship Diagram

Why it fails: Entity Relationship Diagrams focus exclusively on the static structure of data schemas and the cardinality of relationships between database tables. While they effectively map how information is stored within a persistent backend, they lack the dynamic capability to represent the movement of packets or service-to-service communication paths across a cloud-native architecture. Developers often select this tool when designing database normalisation or mapping application state, but it fails to capture the transient network interactions necessary for identifying potential attack vectors during a threat modelling exercise.

Defense in depth

Why it fails: Defense in depth relies on layering multiple distinct security controls—such as firewalls, intrusion detection systems, and host hardening—so that if one layer fails, subsequent barriers still protect the environment. This approach is tempting because enterprise security strategies universally mandate layered mitigations to protect legacy networks against varied attack vectors. It would be the correct choice when evaluating a holistic perimeter defense strategy that combines physical, network, and application controls. However, it fails here because software-defined perimeters specifically enforce dynamic, identity-based access control and micro-segmentation rather than the aggregation of multiple sequential security layers.

Perimeter security

Why it fails: Software-defined perimeters explicitly eliminate implicit trust based on network location by hiding infrastructure and enforcing identity-based access per session, rendering static network barriers obsolete. This choice remains tempting because traditional perimeter security relies on firewalls, VPNs, and virtual local area networks to establish a trusted internal corporate zone. Such a model would be the correct choice when protecting legacy, monolithic applications deployed within a traditional, static enterprise data centre that lack native micro-segmentation capabilities and require wholesale network isolation from the public internet.

Fail-safe defaults

Why it fails: Fail-safe defaults dictates that a system should default to a secure state—such as denying access—upon failure, which is tempting because software-defined perimeters also heavily restrict unauthenticated traffic by default. However, this principle governs error handling and access revocation states rather than the core architectural enforcement of an SDP. Fail-safe defaults would be the correct choice when evaluating mechanisms that ensure resources revert to a closed or locked state during a system crash, power loss, or software exception, whereas an SDP primarily enforces zero trust network access through dynamic, identity-based controller-gateway associations.

System-centric

Why it fails: System-centric threat modeling prioritises the internal architecture, data flows, and structural components of an application rather than external human adversaries. It is tempting because security professionals frequently begin assessments by mapping out software boundaries and system assets to identify technical vulnerabilities. This approach would be the correct choice when conducting a comprehensive architectural review, such as a STRIDE analysis, to uncover design flaws within the application's native components. However, it fails in this scenario because it prioritises internal mechanics over threat actor profiles and malicious incentives.

Capability-centric

Why it fails: Capability-centric threat modelling evaluates specific threat actors by cataloguing their known tools, infrastructure, and technical methods to map out potential attack paths, making it tempting because it incorporates attacker profiles. However, this technique fails this scenario because it prioritises *how* an adversary executes attacks rather than *why* they attack, whereas motivation-driven threat modelling specifically requires analysing the underlying intent, strategic drivers, and goals behind the threat actor. Capability-centric modelling is the correct choice when defending against a targeted Advanced Persistent Threat campaign where specific adversary tooling must be systematically emulated.

Data-centric

Why it fails: Data-centric threat modelling focuses primarily on information assets, classification levels, and data flows rather than external adversary profiles, meaning it fails to address the attacker's motivation specified in the stem. This approach is tempting because information security inherently aims to protect sensitive assets, making it the correct choice when designing security controls specifically to safeguard high-value databases or comply with strict regulatory frameworks regarding data privacy.

API Keys

Why it fails: Relying on static keys fails to secure inter-service communication because they merely identify a client rather than cryptographically asserting a granular service-to-service authorization context, allowing any compromised microservice to impersonate another across the internal mesh. They remain tempting due to their trivial implementation footprint, making them the correct choice solely for public-facing, low-privilege developer portals where rate-limiting anonymous or low-risk traffic takes precedence over mutual authentication.

IP Whitelisting

Why it fails: Relying on network perimeter controls like IP whitelisting fails in modern microservice architectures because dynamic container orchestration platforms constantly reallocate internal IP addresses, rendering static rules obsolete. This approach is tempting for legacy perimeter defence where fixed virtual machine instances communicate across static subnets. In traditional network security deployments, restricting traffic by source IP address provides a reliable boundary check, but it lacks the cryptographic identity verification required for zero-trust inter-service communication.

Basic Auth

Why it fails: Transmitting credentials directly in HTTP headers exposes user identifiers and passwords to interception over network boundaries, failing to provide cryptographic integrity or fine-grained token scoping required for zero-trust microservice meshes. Developers often gravitate towards this scheme because its straightforward header implementation requires minimal configuration and integrates natively with legacy web servers. It remains adequate strictly for simple administrative scripts or internal legacy applications operating over isolated, encrypted management networks where token-based federation infrastructure is unavailable.

Sequence diagram

Why it fails: Sequence diagrams illustrate temporal interactions and message exchanges between objects or components over time, making them tempting when evaluating how runtime processes flow across system boundaries. However, they fail to represent static perimeter boundaries, trust levels, or geographic boundaries because they lack spatial representation. A sequence diagram would be the correct choice when attempting to model the chronological ordering of API calls or authentication handshakes during an OAuth session, rather than mapping network zones.

Class diagram

Why it fails: Class diagrams belong to the Unified Modelling Language and are used to model the static structure of software systems by defining classes, attributes, operations, and object relationships. While candidates familiar with object-oriented software design may mistakenly view these structural diagrams as a way to map out system components, they fail this scenario because they lack the spatial and trust-boundary semantics required to delineate network or security zones. A class diagram would be the correct choice when a developer needs to document the domain model and object hierarchies of an application prior to code implementation.

Activity diagram

Why it fails: Activity diagrams model behavioural workflows, sequential actions, and conditional branching rather than topological boundaries, meaning they cannot visually partition network segments, demilitarised zones, or trust tiers. They appear plausible because security professionals frequently map out operational processes and procedural handoffs between systems. Consequently, an activity diagram would be the correct choice when documenting the step-by-step logic of an authentication sequence or an incident response playbook rather than illustrating static structural perimeters.