CPA Exam Information Systems: System Design and Architecture
Last updated: May 2, 2026
Information Systems: System Design and Architecture questions are one of the highest-leverage areas to study for the CPA Exam. This guide breaks down the rule, the elements you need to recognize, the named traps that catch most students, and a memory aid that scales to test day. Read it once, then practice the same sub-topic adaptively in the app.
The rule
System design and architecture decisions determine how an information system's components are layered, how tightly they depend on each other, and where they run. Under the AICPA ISC blueprint, you must distinguish among architectural styles (monolithic, n-tier, service-oriented, microservices, event-driven, serverless) and deployment models (on-premises, IaaS, PaaS, SaaS, private/public/hybrid/community cloud). The right design balances scalability, availability, maintainability, security, and cost — and the auditor's job is to recognize when a chosen architecture creates control risk that management has not addressed.
Elements breakdown
Architectural Tiers
The logical separation of an application into layers, each with a distinct responsibility, so that changes in one layer ripple minimally into others.
- Presentation tier handles user interaction
- Application/logic tier processes business rules
- Data tier stores and retrieves persistent data
- Integration tier mediates external system calls
- Each tier deployable on separate infrastructure
Common examples:
- Three-tier web app: browser, application server, database server
Architectural Styles
The high-level pattern that defines how components communicate and are packaged.
- Monolithic — single deployable unit
- N-tier — physically separated layers
- Service-oriented (SOA) — coarse-grained services on enterprise bus
- Microservices — small, independently deployable services
- Event-driven — asynchronous message/event flow
- Serverless/FaaS — managed function execution
Common examples:
- Microservices: a retailer splits checkout, inventory, and shipping into independent services
Coupling and Cohesion
The degree of interdependence between components (coupling) and the focus of a single component on one job (cohesion).
- Tight coupling increases change-impact risk
- Loose coupling enables independent deployment
- High cohesion improves maintainability
- APIs and message queues reduce coupling
- Shared databases create hidden coupling
Common examples:
- Two services writing to the same table is hidden tight coupling
Deployment Models
Where the infrastructure runs and who owns operational responsibility.
- On-premises — entity owns hardware and stack
- IaaS — entity manages OS and above
- PaaS — entity manages app and data only
- SaaS — entity manages configuration and data only
- Private, public, hybrid, community cloud variants
- Shared-responsibility model defines control ownership
Common examples:
- Salesforce is SaaS; AWS EC2 is IaaS; Heroku is PaaS
Quality Attributes (Non-Functional Requirements)
The system properties that architecture must satisfy beyond core functionality.
- Scalability — handle growth in load
- Availability — uptime targets and SLAs
- Reliability — correct behavior over time
- Performance — latency and throughput targets
- Security — confidentiality, integrity, authentication
- Maintainability — ease of change
- Recoverability — RTO and RPO targets
Common examples:
- A trading platform with a 99.99% availability SLA needs redundancy across availability zones
Resilience Patterns
Design techniques that keep the system functioning when components fail.
- Redundancy across availability zones
- Load balancing to distribute traffic
- Failover to standby resources
- Circuit breakers to isolate failing dependencies
- Backups aligned to RPO targets
- Disaster recovery sites (hot, warm, cold)
Common examples:
- Active-active database replication across two regions
Common patterns and traps
The Shared-Responsibility Confusion
Cloud deployment models distribute control responsibilities between the customer and the provider differently. In IaaS the customer patches the OS; in PaaS the provider patches the OS and runtime; in SaaS the provider handles nearly everything except customer data and configuration. Candidates routinely assign a control to the wrong party — for example, holding management responsible for hypervisor patching in a public IaaS environment, or assuming the SaaS vendor is responsible for the customer's user-access reviews.
An answer choice that says management must directly patch or harden a layer that the chosen deployment model has handed off to the provider, or vice versa.
The Microservices-Means-Secure Fallacy
Microservices and serverless architectures are often pitched as inherently more secure because of their isolation. In practice they multiply the attack surface (more network calls, more secrets, more deployment pipelines) and shift complexity from the codebase into the network and identity layers. A correct answer recognizes that the security posture depends on the controls implemented around the services, not on the architectural style itself.
An answer choice claiming that adopting microservices, containers, or serverless functions automatically improves a specified control objective without any mention of supporting controls.
The Hidden-Coupling Trap
Two services that appear independent on an architecture diagram may be tightly coupled through a shared database, a shared file store, or an undocumented synchronous API call. This invalidates the supposed benefits of the design — independent deployment, fault isolation, separate change management — and creates an audit finding the diagram alone will not reveal.
A scenario describing services with their own codebases that nonetheless read or write to the same underlying table or file location, presented as if the design is sound.
The Scalability-Versus-Availability Mix-Up
Scalability (handling more load) and availability (staying up when components fail) are achieved through related but distinct techniques. Auto-scaling adds capacity but does not protect against an availability-zone outage; multi-AZ redundancy protects availability but does not by itself address load growth. Candidates pick the wrong lever for the stated quality attribute.
An answer choice that proposes horizontal auto-scaling as the response to a stated availability or disaster-recovery requirement, or proposes a hot standby as the response to a throughput problem.
The Tier-Collapse Pattern
An n-tier design that physically separates presentation, application, and data tiers offers segregation, defense-in-depth, and the ability to apply distinct controls at each tier. When teams collapse two tiers onto a single host (often for cost reasons), the security boundary disappears and any compromise of one tier exposes the next. The architecture diagram may still show three tiers even though the deployment is effectively two.
A scenario in which the database engine and the application server are co-located on the same VM, weakening the network segmentation that a three-tier diagram implies.
How it works
Picture Coastal Outfitters Co., an online retailer that started as a single PHP application running on one server in a closet. Sales tripled, the closet caught fire (literally), and the CIO migrated everything to a public cloud IaaS provider. She decomposed the monolith into microservices — checkout, catalog, inventory, fulfillment — each owning its own database. Now changes to the catalog service deploy without redeploying checkout, and a traffic spike on Black Friday auto-scales only the services under load. But the auditor notices that the inventory service still writes directly to the catalog's database table for performance reasons. That is hidden tight coupling: a schema change in catalog will silently break inventory, and the segregation suggested by the architecture diagram does not match reality. On the exam, your job is to spot mismatches like this — between the architecture as drawn and the controls as implemented.
Worked examples
Under the shared-responsibility model for an IaaS deployment, who is responsible for patching the guest operating system?
- A The cloud vendor, because the vendor owns and operates the underlying physical infrastructure.
- B Liu Industries, because the customer manages the operating system and everything above it in an IaaS arrangement. ✓ Correct
- C The cloud vendor, because operating-system patching is always a provider responsibility regardless of the service model.
- D Neither party — guest OS patching is automated by the hypervisor and requires no human action.
Why B is correct: Under the IaaS shared-responsibility model, the provider is responsible for the physical facility, hardware, and hypervisor, while the customer is responsible for the guest operating system, runtime, applications, and data. Because Liu provisioned virtual machines and installed its own OS, Liu owns OS-level patching, hardening, and configuration. This boundary shifts only as you move up the stack to PaaS (provider patches the OS) or SaaS (provider handles nearly everything except customer data and access).
Why each wrong choice fails:
- A: The vendor's responsibility in IaaS stops at the hypervisor and below; ownership of physical infrastructure does not extend upward to the guest OS. (The Shared-Responsibility Confusion)
- C: OS patching responsibility depends on the service model. It belongs to the provider only in PaaS and SaaS, not in IaaS. (The Shared-Responsibility Confusion)
- D: Hypervisors do not patch guest operating systems — guest OS patching requires deliberate action by whichever party owns that layer.
Which of the following best describes the audit-relevant risk created by this design?
- A No additional risk arises because the Inventory service is logically separate from the Order service in the source-code repository.
- B The architecture is appropriate because microservices are inherently more secure than monoliths and the database access is internal.
- C Hidden coupling between the Inventory and Order services undermines the independent-deployment and fault-isolation benefits the design is intended to provide. ✓ Correct
- D The risk is limited to performance because direct database access is faster than calling the Order service's API.
Why C is correct: Two services that share a physical table — even when their codebases are separate — are tightly coupled through the data layer. A schema change inside Order can silently break Inventory, a failure in Order's database brings Inventory down with it, and change-management controls applied to one service will not catch issues that propagate through the shared table. This is the classic hidden-coupling pattern, and the diagram alone will not reveal it.
Why each wrong choice fails:
- A: Logical separation of source code does not eliminate coupling at the data layer; the shared table creates a real dependency that the repository structure conceals. (The Hidden-Coupling Trap)
- B: Microservices are not inherently more secure; their security posture depends on the controls implemented around them, and shared data access undermines the isolation benefit entirely. (The Microservices-Means-Secure Fallacy)
- D: Performance is the least of the issues. The dominant risks are change-impact ripple, fault propagation, and broken segregation between deployment pipelines. (The Hidden-Coupling Trap)
Which of the following design changes most directly addresses the stated availability requirement?
- A Configure horizontal auto-scaling so additional application instances launch automatically when CPU utilization exceeds 70%.
- B Deploy the platform across two availability zones in an active-active configuration with a load balancer distributing traffic between them. ✓ Correct
- C Migrate the platform from virtual machines to serverless functions to eliminate the need to manage infrastructure.
- D Add a second read replica of the database in the same availability zone to offload reporting queries.
Why B is correct: Availability is the ability to keep operating when components fail. Spreading the workload across two availability zones with active-active load balancing means that the loss of one zone does not take the platform offline, which directly addresses the regional-outage scenario the CIO described. Auto-scaling, serverless, and read replicas are all useful techniques but they do not, by themselves, protect against the failure of the single zone the platform currently occupies.
Why each wrong choice fails:
- A: Auto-scaling addresses load growth, not availability. Capacity is already at 40%, so adding instances inside the same failing zone does nothing when that zone goes down. (The Scalability-Versus-Availability Mix-Up)
- C: Switching to serverless changes the operational model but does not by itself provide cross-zone redundancy; serverless workloads still need to be configured for multi-AZ availability, which is the actual control. (The Microservices-Means-Secure Fallacy)
- D: A read replica in the same availability zone fails together with the primary when that zone goes down, so it does not address the availability concern at all. (The Scalability-Versus-Availability Mix-Up)
Memory aid
"SCALE" — Style, Coupling, Availability, Layers, Environment. Walk these five in order whenever a question describes an architecture, and the control gap usually surfaces in one of them.
Key distinction
Architectural STYLE (monolith vs. microservices vs. serverless) describes how the code is packaged and how components talk; DEPLOYMENT MODEL (on-prem vs. IaaS vs. PaaS vs. SaaS) describes who is responsible for which layer of the stack. A microservices app can run on-premises; a monolith can run on SaaS-adjacent PaaS. Do not collapse the two axes.
Summary
System architecture questions test whether you can map components, dependencies, and responsibility boundaries — and identify where that mapping creates audit risk.
Practice information systems: system design and architecture adaptively
Reading the rule is the start. Working CPA Exam-format questions on this sub-topic with adaptive selection, watching your mastery score climb in real time, and seeing the items you missed return on a spaced-repetition schedule — that's where score lift actually happens. Free for seven days. No credit card required.
Start your free 7-day trialFrequently asked questions
What is information systems: system design and architecture on the CPA Exam?
System design and architecture decisions determine how an information system's components are layered, how tightly they depend on each other, and where they run. Under the AICPA ISC blueprint, you must distinguish among architectural styles (monolithic, n-tier, service-oriented, microservices, event-driven, serverless) and deployment models (on-premises, IaaS, PaaS, SaaS, private/public/hybrid/community cloud). The right design balances scalability, availability, maintainability, security, and cost — and the auditor's job is to recognize when a chosen architecture creates control risk that management has not addressed.
How do I practice information systems: system design and architecture questions?
The fastest way to improve on information systems: system design and architecture is targeted, adaptive practice — working questions that focus on your specific weak spots within this sub-topic, getting immediate feedback, and revisiting items you missed on a spaced-repetition schedule. Neureto's adaptive engine does this automatically across the CPA Exam; start a free 7-day trial to see your sub-topic mastery climb in real time.
What's the most important distinction to remember for information systems: system design and architecture?
Architectural STYLE (monolith vs. microservices vs. serverless) describes how the code is packaged and how components talk; DEPLOYMENT MODEL (on-prem vs. IaaS vs. PaaS vs. SaaS) describes who is responsible for which layer of the stack. A microservices app can run on-premises; a monolith can run on SaaS-adjacent PaaS. Do not collapse the two axes.
Is there a memory aid for information systems: system design and architecture questions?
"SCALE" — Style, Coupling, Availability, Layers, Environment. Walk these five in order whenever a question describes an architecture, and the control gap usually surfaces in one of them.
What's a common trap on information systems: system design and architecture questions?
Confusing IaaS, PaaS, and SaaS shared-responsibility boundaries
What's a common trap on information systems: system design and architecture questions?
Treating microservices as automatically more secure than monoliths
Ready to drill these patterns?
Take a free CPA Exam assessment — about 25 minutes and Neureto will route more information systems: system design and architecture questions your way until your sub-topic mastery score reflects real improvement, not luck. Free for seven days. No credit card required.
Start your free 7-day trial