Infrastructure Considerations

Availability

Availability is the guarantee that systems and resources are accessible when users need them. It is one of the three pillars of the CIA triad and the metric by which IT infrastructure is most visibly evaluated. Organizations spend heavily on monitoring systems, redundant hardware, and failover mechanisms — specifically to maximize the percentage of time their systems are operational.

Availability is commonly expressed as a percentage of uptime over a given period. "Five nines" (99.999%) availability is a common SLA target in enterprise and cloud environments — it allows for approximately 5.26 minutes of downtime per year. Each additional nine is significantly more expensive to achieve:

The security nuance: From a security perspective, availability is not simply "keep systems running." It is "keep systems running and accessible only to authorized users." A system that is available to everyone — including attackers — is not a security success. Availability must be paired with access control. A DDoS attack that makes a system unavailable to legitimate users is an attack on availability. Excessive open access that makes a system available to attackers is a failure of access control. Both are security failures.

Resilience and MTTR

Resilience describes the system's ability to maintain availability during disruptions and recover quickly when availability is lost. No system is perfectly available — hardware fails, software crashes, and external events cause outages. The security question is not whether outages will occur, but how quickly the organization can recover.

The primary resilience metric is MTTR — Mean Time to Repair. MTTR measures the average time from when a failure is detected to when the system is restored to full operational status. Lower MTTR = better resilience. The factors that drive MTTR:

• Root cause identification: Before repair can begin, the cause of the outage must be determined — hardware failure, software bug, configuration error, or security incident. Root cause analysis takes time and is the first step in every outage response.
• Hardware replacement: If a physical component failed, replacement hardware must be sourced, installed, and configured. This may take hours or days depending on spare parts availability.
• Software patch availability: If the outage was caused by a software bug, a patch must be available and tested before deployment. If no patch exists, a workaround must be implemented.
• Redundant system readiness: If redundant systems are in place, how quickly can they take over? Are they already synchronized (active/passive HA), or must they be manually configured (cold spare)?

Cost

Every infrastructure decision ultimately comes down to cost. The exam expects understanding of the different cost components and the distinction between capital and operational expenditure:

• Initial installation cost: Hardware purchase, software licensing, labor for deployment, and any integration work. This cost varies significantly by platform — on-premises hardware requires large upfront CapEx; cloud deployment shifts costs to ongoing OpEx.
• Ongoing maintenance cost: Annual licensing, support contracts, staffing costs for operating and monitoring the system, and routine maintenance activities. These are recurring costs that must be factored into the total cost of ownership.
• Repair and replacement cost: Hardware fails and must be replaced. Software must be updated. Redundant components may each need replacement. These costs are less predictable than ongoing maintenance.
• Tax and accounting implications: Capital expenses (hardware purchases) depreciate over time and are treated differently from operational expenses (subscriptions, maintenance contracts) for accounting and tax purposes. The same infrastructure decision can have meaningfully different financial outcomes depending on how it is classified.

Cost is not just a financial constraint — it is a security variable. An organization that cannot afford adequate redundancy accepts higher MTTR. An organization that cannot afford a security tool accepts the risk that tool would have mitigated. Cost drives the security posture whether or not it is acknowledged explicitly.

Responsiveness

Responsiveness measures how quickly a system responds to a user's request — the time between a user submitting a request and receiving a complete response. It is especially important for interactive applications where users are actively waiting for responses — humans are acutely sensitive to delays above approximately 100–200 milliseconds.

Responsiveness is not a single measurement — it is a composite of every component in the request path:

• Network latency: The time for the request to travel from the user's device to the server and back.
• Application processing: The time for the application code to execute the logic for the request.
• Database performance: The time for any database queries to execute and return results.
• Caching layers: Whether a cached result can be served without full processing — dramatically reducing response time for repeated requests.

The weakest link determines overall responsiveness. An application with a fast web server but a slow database query is still slow — the end user experiences the full round-trip time including the slow component. This is why performance optimization requires end-to-end measurement rather than optimizing individual components in isolation.

Security relevance: A DDoS attack degrades responsiveness before causing full unavailability. A poorly configured security appliance (WAF, IDS/IPS) that adds latency to every request is a security control that directly impacts responsiveness. Rate limiting implemented too aggressively can make a system unresponsive for legitimate users.

Scalability and Elasticity

Scalability describes how quickly and easily a system can increase or decrease its capacity to handle changing workloads. Demand for most applications is not constant — it varies by time of day, day of week, season, and business events (end-of-quarter reporting, major product launches, retail holiday seasons). A system that can only handle peak load at all times wastes resources during off-peak periods; a system sized only for average load fails during peaks.

Elasticity is the specific characteristic of cloud-native systems that describes automatic, rapid scaling in response to demand — expanding capacity as load increases and contracting it as load decreases, sometimes multiple times per day. Elasticity is a cloud advantage: provisioning additional on-premises hardware takes days or weeks; provisioning additional cloud compute takes seconds.

Why not just build for maximum capacity always? Because capacity costs money — idle servers in a data center consume power, cooling, space, and licensing fees regardless of whether they are serving traffic. Elasticity allows an organization to pay for only the capacity it is actually using at any given moment.

The security implication of scaling: Security monitoring must scale with the infrastructure. An organization may have SIEM rules, intrusion detection, and endpoint monitoring configured for its baseline infrastructure. When that infrastructure scales out — ten additional web servers are provisioned to handle peak traffic — those ten new servers must also be covered by security monitoring. A scaling event that is not reflected in the security monitoring creates blind spots: new attack surfaces that are not watched.

Normal state: 4 web servers → monitored by SIEM (4 endpoints)
Peak load event: auto-scaling adds 12 web servers → 16 web servers total

Correct behavior: monitoring configuration auto-scales with infrastructure
  → All 16 servers send logs to SIEM; all 16 covered by IDS

Incorrect behavior: monitoring stays at baseline
  → 12 new servers not reporting to SIEM
  → Attacker compromises one of the new servers during the event
  → No logs, no alerts — attacker operates undetected on an "invisible" server

Ease of Deployment

Modern applications are not monolithic single-component systems. A typical application deployment includes multiple interconnected components, each of which must be provisioned, configured, and integrated:

• Web server (handles HTTP/HTTPS requests)
• Application server (executes business logic)
• Database server (stores persistent data)
• Caching server (improves performance by storing frequently accessed results)
• Load balancer (distributes traffic across multiple server instances)
• Firewall / WAF (controls and filters network traffic)
• Monitoring and logging agents (feeds security and operational visibility)

The complexity of deploying all these components in the correct order, with the correct configuration, and integrated correctly with each other creates significant risk of error. Each missed dependency — a firewall rule not created, a logging agent not installed, a database credential not rotated — creates an operational or security gap.

Orchestration and automation address this complexity by defining the entire deployment as code that can be executed automatically and repeatably. Infrastructure as Code tools (Terraform, CloudFormation, Ansible) describe every component — its configuration, its dependencies, its security settings — in version-controlled templates. Deploying the entire application stack becomes a single command that provisions all components in the correct order with the correct configuration every time.

Security benefits of orchestrated deployment: consistent configurations (no manual steps that might be forgotten), version-controlled security settings (changes reviewed before deployment), repeatable deployments (the same configuration deploys in development, staging, and production), and automated security tool integration (monitoring agents, firewall rules, and certificates deployed as part of every new instance).

Risk Transference — Cybersecurity Insurance

Risk transference is the strategy of shifting the financial consequences of a risk to a third party — accepting that the risk event may occur, but ensuring that the financial impact is partially or fully absorbed by someone else. The primary mechanism in IT security is cybersecurity insurance.

Cybersecurity insurance is a policy that covers financial losses resulting from security incidents. It does not prevent incidents — but it limits the financial damage when they occur. Coverage typically includes:

• Business interruption losses: Revenue lost while systems are offline due to an attack. If a ransomware attack takes down an e-commerce platform for 48 hours, the policy covers lost sales during that period.
• Recovery costs: Costs of incident response, forensic investigation, system restoration, and data recovery following a breach or attack.
• Ransom payments: Some policies explicitly cover ransomware ransom payments (though this is evolving as insurers and regulators debate whether covering ransoms funds future attacks).
• Legal costs: If a data breach results in customer lawsuits or regulatory investigations, insurance covers legal defense costs and settlements.
• Notification costs: Data breach notification to affected individuals and regulators is legally required in most jurisdictions — and expensive. Insurance covers these costs.

Cybersecurity insurance has grown significantly with the rise of ransomware as a primary threat vector. Insurers now typically require organizations to demonstrate minimum security controls before issuing a policy (MFA, EDR, backup systems, patch management) — these requirements effectively drive security baseline adoption among insured organizations.

Ease of Recovery

When something goes wrong — and it will — the speed of recovery directly determines the financial and operational impact of the incident. Time spent offline is money lost. The ease with which a system can be restored to full operational status is an infrastructure design criterion that must be considered during the engineering phase, not improvised during a crisis.

The classic example illustrates the point directly:

Scenario: A workstation is confirmed infected with malware.
Best practice: wipe and rebuild the system from scratch.

Recovery Option A — Reload from original installation media:
  1. Boot from OS installation media
  2. Install OS (~30 minutes)
  3. Apply all Windows Updates since media creation (~20 minutes)
  4. Install corporate applications one by one (~20 minutes)
  5. Restore user data from backup (~20 minutes)
  Total: ~90 minutes per workstation

Recovery Option B — Deploy from corporate image:
  1. Boot from network PXE or USB image
  2. Image deploys pre-configured, pre-patched, pre-loaded baseline (~10 minutes)
  3. Restore user data from backup (~5 minutes)
  Total: ~15 minutes per workstation

For 50 affected workstations:
  Option A: 50 × 90 min = 75 hours of technician time
  Option B: 50 × 15 min = 12.5 hours of technician time
  Difference: 62.5 hours saved — a significant operational cost reduction

The corporate image approach requires investment upfront: building and maintaining the standard image, testing it against the production environment, and keeping it current with patches. But this upfront investment pays back substantially during any recovery scenario. Organizations should design recovery procedures for every critical system before those systems fail — not during the incident when stress and time pressure increase the likelihood of errors.

Patch Availability

Software is not static. Every deployed application and operating system will receive security patches, bug fixes, and feature updates throughout its lifetime. The patching process — testing and applying updates — is one of the most fundamental security activities an IT organization performs.

Patch management principles that appear on the exam:

• First task after installation: The very first action after deploying a new system is to check for and apply all available patches. Installation media may be months old; vulnerabilities discovered since that media was created must be patched before the system is connected to production networks.
• Regular vendor update schedules: Microsoft releases patches on the second Tuesday of each month ("Patch Tuesday"). Many vendors follow similar monthly or quarterly cycles. Organizations should have a defined process for evaluating and deploying each release.
• Test before production: Patches must be tested in a non-production environment before deployment to production. A patch that breaks a critical business application is itself an availability incident. Test → validate → deploy to production is the standard workflow.
• Speed vs. thoroughness tradeoff: Patches for critical zero-day vulnerabilities should be deployed as quickly as possible — sometimes faster than the normal testing cycle allows. Emergency patching processes must be defined for high-severity vulnerabilities where the risk of delay exceeds the risk of a less thorough test.

Inability to Patch

Some systems cannot be patched through the normal patch management process. This is more common than most IT professionals expect, and it represents a category of persistent, unmitigable vulnerability that requires a different security approach.

Systems that commonly cannot be patched:

• Embedded systems: HVAC controllers, time clocks, badge access panels, building management systems. These devices run purpose-built firmware with no end-user update mechanism. The vendor may have released a firmware update, but applying it requires physical access and specialized tooling — or may not be supported at all on older hardware.
• Medical devices: FDA-regulated medical devices may require regulatory re-approval before firmware updates can be deployed. The vendor may not support updates, or the update may require a field engineer visit for each device.
• Legacy industrial equipment: Manufacturing equipment running decades-old embedded OS (Windows XP, Windows CE) that cannot be upgraded because the software controlling the machine is not compatible with newer OS versions.
• End-of-support systems: Any system whose vendor no longer provides security patches — the software will never be patched regardless of what vulnerabilities are discovered in it.

When patching is not possible, compensating controls are applied at the network boundary around the vulnerable device — not on the device itself (because that is not possible):

• Network isolation: Place the unpatched device on a dedicated VLAN with no connectivity to corporate networks or the internet. The vulnerability cannot be exploited if there is no network path to reach it.
• Firewall segmentation: A firewall between the unpatched device and the rest of the network, permitting only the specific traffic that the device requires to function and denying all else.
• Physical access control: If the device is air-gapped, physical security becomes the primary control — restrict who can physically access the device.
• Enhanced monitoring: Compensate for the inability to patch by monitoring for exploitation attempts at the network level — anomalous traffic to or from the device triggers alerts.

Power

Power is the invisible foundation of all IT infrastructure. Every device — servers, networking equipment, storage, security appliances — requires continuous, stable electrical power to operate. Power considerations for infrastructure design:

• Data center power requirements: Data centers have dramatically higher power requirements than standard office buildings. Power density (watts per square foot), redundant power feeds, and UPS capacity must all be engineered. A licensed electrician or data center power engineer should assess requirements before new equipment is deployed.
• Primary power sources: Most facilities receive power from a single utility provider. In dense urban areas, multiple independent power feeds from different substations may be available — providing redundancy against substation failures. Dual power feeds are standard in tier-3 and tier-4 data centers.
• UPS (Uninterruptible Power Supply): Battery-backed power conditioning that provides immediate power during a brief outage — preventing systems from losing power during the seconds or minutes it takes for a generator to start. UPS also protects against power quality issues (voltage sags, surges, noise) that can damage equipment.
• Generators: Diesel or natural gas generators that provide extended backup power during prolonged utility outages. A UPS bridges the gap from outage to generator start. Together, UPS + generator provide continuous power through extended utility failures.

Compute

Compute is the processing capacity that powers application execution — the CPU cycles, memory, and associated resources that perform the actual calculations and data operations of an application. Modern infrastructure offers a spectrum of compute options:

• Single processor / single server: The simplest architecture — one application runs on one server. Easier to develop, manage, and troubleshoot. Limited by the capacity of a single machine and presents a single point of failure.
• Distributed computing: Applications spread across multiple processors and multiple servers — potentially across multiple data centers or cloud regions. Dramatically increases capacity and resilience. Introduces complexity in coordination, state management, and consistent monitoring.
• Cloud compute (Compute Engine / EC2 / Azure VMs): On-demand processing capacity provisioned via API, billed by consumption. The cloud's elastic compute model allows applications to scale from one to thousands of compute instances dynamically — the defining advantage for variable workloads.

Security relevance: As compute scales across multiple instances and multiple locations, security monitoring must cover all of it. A distributed application running on 50 cloud instances must have all 50 instances sending logs to the SIEM, covered by endpoint monitoring, and subject to consistent security policy. The complexity of distributed compute directly increases the complexity of the security monitoring requirement.