SY0-701 · Objective 3.1 · Security Architecture
3.1 Architecture models explained
The official objective: “Compare and contrast security implications of different architecture models.” Here is what it means, what candidates mix up, and 3 practice questions that test it.
What objective 3.1 covers
Objective 3.1 asks how the choice of architecture changes who is responsible for security and which weaknesses matter most. Questions describe an environment and ask for the main concern or the right control.
Cloud comes first, and with it the shared responsibility model. The provider always secures the physical data centres and the underlying infrastructure. What the customer secures depends on the service model. With infrastructure as a service, the customer manages the guest operating system, its patches, the applications and the data. With platform as a service, the provider also runs the operating system and runtime. With software as a service, the customer is left mainly with identities, access settings and their own data. In every model the customer configures access, which is why misconfiguration is the most common cloud problem. A responsibility matrix spells out the split for a given contract.
Hybrid environments combine on-premises systems with cloud, which adds the risk of inconsistent controls across the two. Third-party vendors add their own risk. Infrastructure as code defines environments in reviewed templates, so builds are consistent and changes are visible. Serverless shifts almost all infrastructure to the provider, leaving the customer to secure function code and its permissions. Microservices split an application into small services, which helps contain a breach if each service has its own identity and data. Network infrastructure choices include physical isolation, such as an air gap, logical segmentation, and software-defined networking.
On-premises gives full control over location and configuration, at the cost of doing everything yourself. Centralised designs are simpler to manage but can create single points of failure; decentralised ones spread risk but are harder to keep consistent. Containers share the host operating system kernel, so they start fast but give weaker isolation than virtual machines, which each run their own kernel on a hypervisor.
Specialised systems have their own constraints. IoT devices are cheap, numerous and often hard to update. Industrial control systems and SCADA run physical processes, put safety and availability first, and often can't run agents or accept frequent patches. Real-time operating systems must respond within fixed time limits. Embedded systems may never be patched at all. For these, the usual answer is to isolate them and monitor the boundary rather than change the device.
Across all of these, the exam's considerations are the same: availability, resilience, cost, responsiveness, scalability, ease of deployment and recovery, risk transference, patch availability, the ability to install security agents, power and compute limits.
What candidates mix up
- IaaS versus SaaS responsibility: in IaaS the customer patches the guest OS; in SaaS the customer never touches the OS.
- Containers versus virtual machines: containers share the host kernel; VMs have their own kernel and stronger isolation.
- Air gap versus segmentation: an air gap has no network connection at all; segmentation still connects zones through controlled points.
Practice questions for 3.1
From the CertRidge SY0-701 question bank. Try each one before opening the answer.
Question 1
Under the shared responsibility model for Infrastructure as a Service (IaaS), who is responsible for patching the guest operating system on a virtual machine?
- AThe customer
- BThe cloud provider
- CIt is fully automated and no one is responsible
- DThe internet service provider
Show answer and explanation
Answer: A) The customer
- AIn IaaS the provider secures the physical infrastructure and hypervisor; the customer manages the OS, middleware, applications, and data — including OS patching.
- BThe provider patches the hypervisor and hardware, not the customer's guest OS in IaaS.
- CAutomation can be configured, but accountability still rests with the customer in IaaS.
- DThe ISP provides connectivity and has no role in OS patching.
Question 2
A manufacturer's ICS/SCADA network contains legacy PLCs that cannot run security agents and can be patched only during scheduled plant shutdowns. Availability and safety are the top priorities. Which security approach BEST fits this OT environment?
- APlace the controllers in a segmented zone and monitor them passively through a SPAN port or tap
- BRun weekly authenticated active vulnerability scans across the controller network to find missing patches
- CInstall endpoint detection agents on each PLC and enable automatic patching during production
- DConnect the controllers directly to the corporate LAN so the IT patch management server can reach them
Show answer and explanation
Answer: A) Place the controllers in a segmented zone and monitor them passively through a SPAN port or tap
OT/ICS environments put availability and safety first and often contain legacy devices that can't take agents or frequent patches. Strong segmentation combined with passive, agentless network monitoring is the preferred control set.
- ACorrect. When OT devices cannot be patched quickly and cannot host agents, the usual approach is to isolate them through segmentation and watch traffic with agentless, passive sensors. Monitoring from a SPAN port or network tap gives visibility without affecting the controllers.
- BIncorrect. Active scanning sends probes that fragile OT devices may not handle correctly, which can disrupt physical processes. Passive discovery is preferred. Finding missing patches also helps little when patches can be applied only during shutdowns.
- CIncorrect. The scenario says the PLCs cannot run agents. Patching automatically during production would put availability and safety at risk, which is exactly what OT change control is meant to prevent.
- DIncorrect. Flattening the network exposes the controllers to threats that can pivot from the corporate network, and it still doesn't solve the problem of patching only during shutdowns. OT networks should be segmented from IT.
Question 3
A team is choosing between containers and virtual machines (VMs) for hosting workloads from different business units on the same server. Compared with VMs, which security consideration applies to containers?
- AContainers on a host share that host's operating system kernel
- BEach container runs its own full guest kernel, enlarging the attack surface
- CContainers give a stronger isolation boundary than VMs for untrusted tenants
- DContainers are patched by running OS updates inside each running instance
Show answer and explanation
Answer: A) Containers on a host share that host's operating system kernel
Containers share the host OS kernel, while VMs each run their own kernel. That makes container isolation lighter and a kernel flaw more widely impactful, so VMs (or Hyper-V isolated containers) are preferred when a strong security boundary is required.
- ACorrect. Containers run on top of the host OS kernel, while each VM runs its own complete OS including a kernel. A kernel vulnerability or container escape can therefore affect other containers, so the security boundary is weaker than with VMs.
- BIncorrect. This describes VMs. Containers hold only the user-mode portion of an OS and rely on the host's kernel.
- CIncorrect. VMs give more complete isolation and suit cases where a strong security boundary is critical. Standard containers give lighter isolation, though Hyper-V isolation mode can strengthen it.
- DIncorrect. Containers are updated by pointing the build file at a newer base image, rebuilding the image, pushing it to a registry, and redeploying it. They are not patched in place like a VM.
Other Security Architecture objectives
Also: the Security Architecture domain page (18% of the exam), all SY0-701 objectives and the SY0-701 cheat sheet.
Ready for a full SY0-701 practice exam?
Timed practice exams match the real exam's length and domain weights, every result shows your score per domain, and Review Mode re-drills the questions you missed.
Objective numbers and statements from CompTIA's published SY0-701 exam objectives. The explanations and questions are our own. Not affiliated with CompTIA.