RANGER CompTIA Security+ (SY0-701) · chapter 11 of 27
Month 6: Blueprints in the clouds
In this chapter Objectives 3.1
Objective 3.1
Cloud and code-defined infrastructure
The responsibility matrix
In the cloud, security is shared. The responsibility matrix (shared responsibility model) lists who secures each layer. The provider always secures the physical data center and the virtualization layer. The more you rent as a service, the more the provider takes on. In every model, you still own your data, your user accounts and who gets access.
Layer IaaS PaaS SaaS Data & access You You You Application You You Prov OS & runtime You Prov Prov Virtualization Prov Prov Prov Physical / DC Prov Prov Prov
Exam tip Trap: "SaaS means the provider handles security." Not your data, accounts or sharing settings. A misconfigured permission is the customer's fault in every model.
Hybrid considerations and third-party vendors
A hybrid cloud mixes on-premises systems with public cloud (or several clouds). Hybrid considerations: two sets of tools and policies to keep in sync, one identity and logging story across both, encrypted links between them, and data that crosses boundaries (and maybe borders). Third-party vendors (the provider, integrators, marketplace add-ons) bring their own risk, so you vet them, write it into contracts and keep monitoring them.
Exam tip Exam tip: hybrid = more complexity. Look for answers about consistent policies, central identity and visibility across both environments.
Infrastructure as code (IaC)
Infrastructure as code describes servers, networks and firewall rules in machine-readable template files that a tool deploys automatically. Security wins: every build is identical (no configuration drift), changes are reviewed and versioned like software, and a broken environment can be rebuilt in minutes. Risks: one mistake in a template is copied everywhere, secrets hard-coded in templates leak, and the code repository becomes a high-value target.
Exam tip Memory trick: IaC = "copy-paste perfection". Great for consistency, terrible if the original is wrong.
Serverless and microservices
Serverless (function as a service): you upload code and the provider runs, scales and patches the servers you never see. You still secure the code, each function's permissions and the events or APIs that trigger it. Microservices split an app into small independent services that talk over APIs. A failure or compromise in one service is easier to contain, and each part scales alone. The cost: many more APIs and service-to-service connections to authenticate and monitor.
Exam tip Trap: serverless does not mean "no security work". The OS is the provider's problem; code, permissions and triggers are yours.
Objective 3.1
Network and platform architectures
Physical isolation, logical segmentation, SDN
Physical isolation uses separate hardware with no shared links. The extreme is air-gapped: no network connection to anything else, so data moves only by removable media (which becomes the main risk). Logical segmentation separates traffic on shared hardware with VLANs, subnets and ACLs. Software-defined networking (SDN) splits the network into a data plane (forwards packets), a control plane (decides where traffic goes) and a management plane (configure and monitor), all run from software. Protect the controller: it runs everything.
Exam tip Exam tip: "no network connection at all" = air gap. "Same switch, different VLANs" = logical segmentation.
On-premises, centralized or decentralized
On-premises: you own and run everything, so you get full control and full responsibility (power, patching, physical security, staff, cost). Centralized designs manage everything from one place (one directory, one log server): consistent policy and easy visibility, but a single point of failure and a juicy target. Decentralized designs spread control across sites or owners (each store runs its own systems): more resilient to one failure, harder to keep consistent and to monitor.
Virtualization and containerization
Virtualization: a hypervisor runs many virtual machines, each with its own full guest OS. Risks: VM escape (breaking out to the host or other VMs), VM sprawl (forgotten, unpatched VMs) and resource reuse. Containerization: containers package an app with its libraries and share the host OS kernel. They are light and fast, but isolation is weaker than with VMs, and images can carry vulnerabilities. Use small, scanned images from trusted registries.
Exam tip Memory trick: a VM brings its own OS (own house); a container shares the kernel (apartment in one building).
IoT, ICS/SCADA, RTOS and embedded systems
These are hard to patch and often run for years, so isolate them.
- IoT: smart devices (cameras, thermostats, scanners). Weak defaults, rare updates. Segment them.
- ICS/SCADA: industrial control systems run physical processes (conveyors, HVAC, power). SCADA supervises them across sites. Availability and safety come first.
- RTOS: a real-time OS must respond within strict, predictable time limits (brakes, robot arms). Heavy security agents can break timing.
- Embedded systems: a computer built into a device for one job. Updates usually need vendor firmware.
Exam tip Exam tip: for ICS, IoT and embedded devices that cannot be patched, the answer is usually segmentation or isolation as a compensating control.
High availability
High availability (HA) means a system stays up nearly all the time, often measured in "nines". 99.999% ("five nines") allows about 5.26 minutes of downtime a year. HA is built with redundancy: extra servers, power feeds, network links and failover between them. It always costs more, so you buy it for the systems where downtime hurts most.
Considerations: the trade-off checklist
Ask these about any architecture:
- Availability: is it up when needed? Resilience: does it keep working when parts fail?
- Cost: purchase plus running costs. Responsiveness: how fast it answers users.
- Scalability: can it grow or shrink with demand? Ease of deployment: how fast can we roll it out?
- Risk transference: does it move some risk to a provider or insurer? Ease of recovery: how fast back after failure?
- Patch availability: does the vendor still ship fixes? Inability to patch: the device cannot be updated at all.
- Power: electricity and cooling needs. Compute: processing capacity available.
Exam tip Trap: moving to the cloud transfers some risk, but never the accountability for your data.
Check yourself 1Kibble & Co. moves its online shop to a SaaS platform. An attacker logs in with a store admin's reused password and exports all customer orders. Under the responsibility matrix, who owned this control?
- The SaaS provider, because it runs the application
- Kibble & Co., which manages its own accounts
- The data center operator that hosts the SaaS servers
- Nobody, because SaaS has no customer responsibilities
Show the answer
Answer: B. Kibble & Co., which manages its own accounts
In every cloud model the customer is responsible for its data, user accounts and access. The provider runs the application, but cannot stop a valid login with a reused password.
Check yourself 2The web team wants each part of the shop (cart, search, payments) to run as a separate service with its own API so a bug in search cannot take down payments. Which architecture is this?
- Monolithic application
- Air-gapped network
- Microservices
- Embedded system
Show the answer
Answer: C. Microservices
Splitting an app into small independent services that talk over APIs is a microservices architecture. It contains failures but adds APIs to secure.
CompTIA, A+, Network+, Security+ and Linux+ are trademarks of CompTIA, Inc. Ranger Gamez is not affiliated with or endorsed by CompTIA. The practice questions are written to the published exam objectives; they are not real exam questions.