Infrastructure, Network, Endpoint and Cloud Security

Introduction and Context

Information security is no longer confined to a protected corporate data centre. Contemporary organisations operate across campus networks, branch offices, mobile endpoints, industrial systems, software-defined infrastructure, public clouds, private clouds and third-party platforms. Users and workloads may connect from anywhere, while applications depend on distributed identities, APIs, containers and automated deployment pipelines. This expanded environment improves agility but increases the number of assets, trust relationships and potential attack paths.

Infrastructure security is the discipline of protecting the computing, communication, storage and service foundations on which information systems depend. It includes network architecture, operating-system security, endpoint protection, virtualisation, containers, cloud services and hybrid integration. Its objectives are commonly expressed through confidentiality, integrity and availability (CIA), supplemented by authenticity, accountability, resilience and privacy.

A secure infrastructure is not created by installing a single product. It is engineered through layered controls: asset visibility, secure architecture, identity-based access, hardening, segmentation, vulnerability management, monitoring, incident response and recovery. Security must also be proportionate to risk. Excessive restrictions can impair business operations, while insufficient controls expose the organisation to unacceptable loss.

Learning Objectives

By the end of this chapter, the reader should be able to:

1. Explain the security properties and attack surfaces of networks, operating systems, endpoints, virtual machines, containers and cloud services.

2. Design segmentation and access-control arrangements based on trust, business function and risk.

3. Apply practical hardening, patching, configuration-management and endpoint-detection principles.

4. Distinguish virtualisation security from container and orchestration security.

5. Analyse cloud and hybrid environments using the shared-responsibility model.

6. Design monitoring, logging, incident-response and recovery controls for infrastructure.

7. Evaluate technical, managerial, ethical and regulatory implications of infrastructure-security decisions.

1. Infrastructure Security as a Systems Problem

1.1 Assets, threats and attack surfaces

An asset is anything of value to the organisation, including data, identities, compute resources, network services, configurations, cryptographic keys and operational capability. An attack surface comprises the reachable interfaces through which an adversary might obtain access or influence behaviour. Examples include exposed ports, administrative consoles, remote-access services, wireless networks, APIs, identity providers, software dependencies and management interfaces.

Threats may be deliberate, such as ransomware, credential theft, exploitation of a vulnerability or denial-of-service, or accidental, such as misconfiguration, lost devices or unsafe changes. A vulnerability is a weakness that can be exploited; risk arises when a threat can exploit a vulnerability and produce a consequence. A useful qualitative relationship is:

Risk is assessed from likelihood and impact.

This is a conceptual relationship rather than a universal numerical law. Organisations may use ordinal scales, quantitative loss models or hybrid methods. The important practice is to document assumptions, distinguish inherent risk from residual risk, and reassess risk after controls are applied.

1.2 Defence in depth and zero trust

Defence in depth places multiple, partially independent controls around assets. For example, a database may be protected by network segmentation, encrypted connections, strong authentication, least-privilege authorisation, database hardening, activity monitoring and tested backups. Layering reduces dependence on any single control, but it does not justify poorly configured or redundant controls.

The zero-trust approach rejects implicit trust based solely on network location. Access decisions should be based on verified identity, device or workload posture, requested resource, context and policy. Zero trust does not mean that trust is impossible; it means that trust is explicit, continuously evaluated and limited to the necessary transaction. Network segmentation remains valuable in a zero-trust architecture, but a network segment alone is not treated as proof of trust.

1.3 Management and data planes

A management plane administers systems through interfaces such as hypervisor consoles, cloud control planes, directory services, routers and endpoint-management platforms. A data plane carries application or user traffic. Compromise of the management plane can enable broad control over the data plane; therefore, administrative interfaces require stronger protection, including dedicated access paths, phishing-resistant multifactor authentication, privileged-access management, approval workflows and detailed logging.

2. Secure Network Architecture

2.1 Segmentation and trust boundaries

Segmentation divides a network into zones with controlled communication between them. Typical zones include user networks, server networks, public-facing services, management networks, backup networks, guest wireless networks and operational-technology environments. A demilitarised zone (DMZ) may host services that must be reachable from the internet while limiting direct access to internal systems.

Segmentation can be implemented with VLANs, routing policies, firewalls, software-defined networking, security groups, host firewalls or application-layer gateways. Effective segmentation requires an explicit policy describing which source identities may communicate with which destination services, using which protocols and for what business purpose. “Internal” should not be treated as a sufficient security classification.

A practical design process is:

1. Identify assets, data flows, dependencies and administrative paths.

2. Classify systems by sensitivity, exposure and operational criticality.

3. Define zones and trust boundaries.

4. Permit only required flows, preferably by application identity and service rather than broad address ranges.

5. Log and review allowed and denied connections.

6. Test whether a compromised system can move laterally across boundaries.

Microsegmentation applies these principles at a finer granularity, often to individual workloads or applications. It can reduce lateral movement but increases policy complexity and operational demands. Poorly maintained rules may create outages or a false sense of security.

2.2 Network control technologies

Firewalls enforce traffic policy at boundaries. Stateful firewalls track connection state; next-generation firewalls may inspect applications, users and content. Network access control can assess device identity and posture before permitting access. Intrusion detection systems (IDS) identify suspicious activity, while intrusion prevention systems (IPS) can block selected traffic. Web application firewalls focus on HTTP-based application attacks, but they do not replace secure application development.

Secure network design also requires resilient routing, protected DNS, secure time synchronisation, encrypted management protocols and controlled remote access. Telnet, unencrypted file transfer and obsolete management protocols should be replaced with authenticated and encrypted alternatives. Network devices themselves must be hardened, backed up and monitored because their configurations are high-value security assets.

2.3 Wireless and remote access

Enterprise wireless networks should use modern enterprise authentication and strong encryption, separate guest access from internal resources, and protect management interfaces. Shared passwords are difficult to revoke and audit. Remote access should use a managed gateway or zero-trust access service, multifactor authentication, device posture checks and least-privilege authorisation. Split tunnelling, unmanaged personal devices and direct exposure of administrative services require explicit risk evaluation.

3. Operating-System and Endpoint Security

3.1 Secure configuration and hardening

Hardening reduces unnecessary functionality and limits exploitable paths. A baseline should specify approved operating-system versions, services, ports, protocols, accounts, permissions, cryptographic settings, logging and configuration values. Baselines can be informed by vendor guidance, recognised security benchmarks and organisational requirements.

Important hardening actions include:

• remove or disable unused services, packages, accounts and interfaces;
• enforce secure authentication, lockout or rate-limiting controls and multifactor authentication where appropriate;
• apply least privilege and separate administrative from ordinary accounts;
• restrict execution of unapproved software and scripts;
• enable host-based firewalls and endpoint detection;
• protect boot processes, firmware and local storage;
• configure reliable time synchronisation and security logging;
• encrypt sensitive data at rest and in transit; and
• manage configuration through version-controlled, repeatable processes.

Hardening must preserve operational requirements. Disabling a service without understanding dependencies can cause outages. Therefore, changes should be tested, documented, approved and reversible.

3.2 Patch and vulnerability management

Vulnerability management is a lifecycle rather than a one-time scan. It includes asset discovery, vulnerability identification, validation, prioritisation, remediation, verification and exception management. Prioritisation should consider exploit availability, internet exposure, asset criticality, compensating controls and the value of affected data—not merely a severity score.

A patch programme needs inventories of hardware and software, supported versions, maintenance windows, emergency procedures and service-level targets. Unsupported systems should be upgraded, isolated, replaced or subject to formally accepted risk. Scanning itself requires care: aggressive scans may disrupt fragile systems, and scanner findings require validation.

3.3 Endpoint detection and response

Endpoint security combines preventive and detective controls. Antivirus and modern endpoint detection and response (EDR) tools can identify malicious files, suspicious processes, credential theft, persistence and lateral movement. Their effectiveness depends on telemetry quality, deployment coverage, tuning, analyst capability and integration with response processes.

A mature endpoint programme records process creation, authentication events, script execution, privilege changes, removable-media use and relevant network connections, subject to privacy and legal constraints. Response actions may include network isolation, account suspension, process termination and forensic preservation. Automated containment should be carefully designed to avoid disrupting critical systems or destroying evidence.

4. Virtualisation and Container Security

4.1 Virtual machines and hypervisors

Virtualisation allows multiple guest systems to share physical resources through a hypervisor. It improves utilisation and operational flexibility, but introduces risks involving the hypervisor, virtual networks, management consoles, images and administrative privileges.

Controls include:

• hardening and promptly patching the hypervisor and management platform;
• isolating management traffic from guest and user traffic;
• enforcing multifactor authentication and role-based administration;
• restricting virtual-machine snapshots, clipboard sharing and device passthrough;
• scanning and signing approved images;
• protecting templates, snapshots and virtual disks as sensitive data;
• monitoring changes to virtual networks and security groups; and
• testing recovery of critical virtual machines.

A snapshot is not automatically a backup. It may depend on the original storage, preserve compromised states and lack independent recovery capability. Backups should be protected from alteration and tested through restoration exercises.

4.2 Containers and orchestration

Containers package applications and dependencies while sharing the host operating-system kernel. This generally makes them lighter than virtual machines, but it means that kernel compromise or unsafe runtime configuration can affect multiple workloads. Container security spans the image supply chain, registry, runtime, orchestration control plane, secrets and application configuration.

Good practice includes using minimal and trusted base images, pinning versions, scanning images and dependencies, removing build tools from production images, signing images, running processes as non-root, applying seccomp or equivalent restrictions, limiting Linux capabilities, using read-only filesystems where feasible, and avoiding embedded secrets.

In orchestrated environments, the control plane is especially sensitive. Role-based access control, namespace isolation, network policies, admission controls, protected API access, encrypted secrets and audit logging are essential. An image scan cannot prove that a workload is safe: it may miss runtime behaviour, misconfiguration, malicious insider activity or vulnerabilities introduced after deployment.

4.3 Infrastructure as code and supply-chain security

Infrastructure as code (IaC) expresses infrastructure configuration in reviewable files. It supports consistency, peer review, automated testing and change traceability. However, IaC can also replicate insecure settings at scale. Security checks should detect publicly exposed storage, excessive permissions, unencrypted resources, weak network rules and hard-coded credentials before deployment. State files and pipeline credentials must be protected because they may contain sensitive values.

Software and infrastructure supply chains require provenance, dependency control, signed artefacts, trusted build systems, segregation of duties and monitoring for unexpected changes. Security must be integrated into development and deployment rather than added only after production release.

5. Cloud and Hybrid Security

5.1 Service models and shared responsibility

In infrastructure as a service (IaaS), the provider commonly operates physical facilities, hardware and foundational services, while the customer configures guest operating systems, identities, networks, applications and data. In platform as a service (PaaS), the provider manages more of the operating platform, while the customer remains responsible for applications, identities, data and service configuration. In software as a service (SaaS), the provider operates most technical components, but the customer still controls users, permissions, data governance, configuration and appropriate use.

The exact boundary varies by provider and service. Shared responsibility is therefore a contract-and-architecture question, not a universal diagram. Customers must read service documentation, configure controls, assess provider assurance and identify responsibilities for logging, backup, encryption, incident notification and deletion.

5.2 Common cloud failure modes

Many cloud incidents arise from identity and configuration failures rather than defects in the provider’s physical infrastructure. Examples include publicly exposed storage, overly permissive identity policies, long-lived access keys, unmonitored administrative accounts, insecure security groups, unencrypted backups, unmanaged APIs and unapproved services.

Cloud security should include:

• central identity federation and phishing-resistant multifactor authentication;
• separate human, workload and emergency identities;
• least-privilege policies with conditions and short-lived credentials;
• organisation-wide logging and protected audit trails;
• encryption with managed key lifecycle and appropriate separation of duties;
• policy-as-code and continuous configuration assessment;
• private connectivity or controlled egress where justified;
• tested backups, cross-region or cross-account recovery and deletion procedures;
• container, serverless and API-specific controls; and
• continuous cost, inventory and exposure monitoring.

Cloud environments are elastic, so controls must operate automatically. Manual reviews alone cannot reliably govern thousands of transient resources.

5.3 Hybrid environments

Hybrid environments connect on-premises systems to one or more clouds. Their risks include inconsistent identity policies, overlapping address spaces, weak trust between environments, unmonitored data transfers and dependence on a small number of connectivity links. Architecture should define authoritative identity sources, route and firewall policy, data-residency requirements, failure behaviour and responsibility for each system.

Connectivity should be minimal and authenticated. A private circuit does not eliminate the need for encryption or access control. Organisations should model compromise in either environment and test whether an attacker can pivot across the connection.

6. Monitoring, Detection, Response and Recovery

Security monitoring converts technical events into decisions. Relevant sources include identity providers, firewalls, DNS, endpoint agents, cloud audit logs, operating systems, databases, hypervisors, containers and security tools. Logs should have reliable timestamps, sufficient context, protected storage, controlled access and a retention period justified by operational, legal and privacy requirements.

A security information and event management (SIEM) platform can aggregate and correlate events, while security orchestration, automation and response (SOAR) tools can execute approved actions. Neither tool substitutes for detection engineering and skilled analysis. Excessive low-value alerts produce fatigue; insufficient telemetry creates blind spots.

Detection should focus on meaningful behaviours, such as impossible travel combined with suspicious authentication, creation of privileged identities, unusual data transfer, disabling of security tools, unexpected administrative access or a workload communicating with an unauthorised management service. Detection rules require testing against normal behaviour and adversarial scenarios.

Incident response should define preparation, identification, containment, eradication, recovery and lessons learned. Infrastructure-specific playbooks should address ransomware, cloud credential compromise, exposed storage, malicious container images, hypervisor compromise and denial-of-service. Evidence preservation, legal consultation and communication responsibilities should be established before an incident.

Recovery depends on resilient backups, documented dependencies, alternative communication channels and tested restoration. The recovery point objective (RPO) identifies the maximum tolerable amount of data loss, expressed as time; the recovery time objective (RTO) identifies the target time to restore a service. These are business requirements, not merely technical settings. A low RPO may require frequent replication, while a low RTO may require redundant infrastructure; both increase cost and complexity.

7. Governance, Ethics and Regulatory Considerations

Infrastructure security decisions affect employees, customers, suppliers and the public. Endpoint monitoring can collect personal information; network inspection may reveal sensitive communications; cloud telemetry may cross jurisdictions. Monitoring should have a defined purpose, legal basis where required, proportionality, access restrictions, retention limits and transparency appropriate to the context.

Governance should assign accountable owners for assets, identities, configurations, vulnerabilities, logs, backups and third-party services. Policies should address acceptable use, privileged access, remote administration, encryption, exception approval and security testing. Independent assurance may involve internal audit, penetration testing, cloud configuration reviews and supplier assessments.

Regulatory obligations vary by sector and jurisdiction, but commonly concern protection of personal data, breach notification, retention, critical infrastructure resilience, access logging and third-party risk. Compliance is not equivalent to security: a compliant control can be poorly implemented, and a useful control may not map directly to a specific requirement. Organisations should map controls to applicable laws, contracts and recognised frameworks while maintaining a risk-based view.

8. Applied Case: Securing a Hybrid University Research Platform

Background

The following is an illustrative case. A university operates a research platform containing sensitive participant data and computational workloads. Researchers use campus networks, personal laptops and a public cloud. The environment includes legacy virtual machines, a Kubernetes cluster, shared storage and a VPN. A single directory account is used by several automated jobs.

Problem

An assessment finds publicly reachable administration ports, inconsistent operating-system patches, excessive cloud permissions, long-lived access keys and limited central logging. The university cannot reliably determine which workloads have accessed participant data. Researchers require rapid provisioning, so security controls that depend entirely on manual approval would be bypassed.

Analysis

The highest risks are compromise of privileged identities, lateral movement from an endpoint to research storage, exposure of cloud data and inability to investigate an incident. The shared automation account prevents attribution and makes credential rotation difficult. The VPN provides network reachability but does not establish that a device is trustworthy.

Approach and solution

The university first inventories assets and data flows, classifies participant data as highly sensitive and maps business owners. It separates researcher workstations, general services, sensitive storage, management systems, backup services and guest access into distinct zones. Firewall and host policies permit only documented application flows.

Administrative access is moved to a dedicated management path using federated identity, phishing-resistant multifactor authentication and privileged-access workflows. The shared automation account is replaced by individual workload identities with short-lived credentials and narrowly scoped permissions. Public administrative ports are removed; remote administration is available only through controlled access services.

Standard virtual-machine and container images are created, signed and scanned. Kubernetes namespaces, network policies, admission controls and audit logging are enabled. Sensitive storage uses encryption and separate key-management permissions. Endpoint detection is deployed to managed devices, while personal devices receive limited access through application-level controls rather than unrestricted network access.

Cloud audit logs and identity events are centralised in protected storage. Alerts are created for public exposure, privilege escalation, unusual data access and disabling of controls. Backups are isolated from production credentials, and restoration is tested. Researchers receive self-service templates that automatically apply approved network, identity and logging policies.

Outcome

The redesigned platform reduces lateral movement, improves attribution and makes secure provisioning compatible with research speed. It does not eliminate risk: compromised researcher accounts, malicious code and provider outages remain possible. The university therefore schedules access reviews, vulnerability assessments, incident exercises and periodic reassessment of data flows.

Learning points

The case demonstrates that effective security is architectural and operational. Identity, segmentation, endpoint posture, cloud configuration, workload security and monitoring must reinforce one another. Automation can improve security when secure defaults are embedded in templates, but automation can also reproduce errors at scale. Finally, controls should be evaluated against business objectives rather than imposed without understanding how the platform is used.

9. Contemporary Developments and Critical Evaluation

Security operations increasingly use machine learning to identify anomalous authentication, process and network behaviour. Such systems can prioritise alerts, but they may generate false positives, encode biased assumptions, or be evaded by adversaries. Automated recommendations should be explainable enough for analysts to validate, and high-impact containment actions should have appropriate safeguards.

Confidential computing seeks to protect data while it is being processed through hardware-supported trusted execution environments. It may reduce exposure to privileged infrastructure operators, but it introduces hardware, attestation and workload-compatibility assumptions. Post-quantum cryptography is also becoming relevant to long-lived sensitive data and infrastructure with extended replacement cycles; migration should begin with cryptographic inventories and dependency analysis rather than indiscriminate replacement.

Other developments include software-defined perimeters, identity-aware proxies, platform engineering, policy-as-code, extended detection and response, edge computing and secure access service edge architectures. These are not automatically secure products or architectures. Their value depends on correct implementation, visibility, interoperability, governance and the organisation’s ability to operate them.

Best-Practice Design Principles

1. Maintain an accurate, continuously updated inventory of assets, identities, data flows and dependencies.

2. Make identity, not physical location, the primary basis for access decisions.

3. Segment environments and restrict east-west movement as well as internet exposure.

4. Establish secure baselines and manage changes through tested, reviewable automation.

5. Prioritise vulnerabilities using exposure, exploitability, asset criticality and business impact.

6. Protect management planes more strongly than ordinary data paths.

7. Use short-lived, attributable credentials for people and workloads.

8. Treat images, templates, IaC and pipelines as production security assets.

9. Centralise, protect and regularly test audit logging and detection.

10. Design recovery from business requirements and verify it through realistic exercises.

11. Treat cloud security as a shared responsibility requiring explicit control ownership.

12. Balance monitoring and control with privacy, proportionality, accessibility and operational continuity.

Chapter Summary

Infrastructure security protects the foundations on which information systems operate. It requires defence in depth, explicit trust boundaries and continuous risk management across networks, operating systems, endpoints, virtual machines, containers and cloud services. Segmentation reduces lateral movement, while identity-centred access prevents network location from becoming an implicit trust mechanism. Hardening, patching, least privilege and endpoint detection reduce compromise likelihood and improve response.

Virtualisation and containers introduce distinct management, image, runtime and isolation risks. Cloud security depends on understanding the precise shared-responsibility boundary, controlling identity and configuration, protecting logs and backups, and automating secure defaults. Hybrid environments require carefully governed connectivity and consistent policy. Monitoring, incident response and recovery complete the control lifecycle. Ethical, privacy, regulatory and managerial considerations are integral because infrastructure controls affect people, business continuity and public trust.

Key Terms

Asset: A resource of value, such as data, identity, system or service.

Attack surface: The set of reachable interfaces and weaknesses through which an attack may occur.

Defence in depth: Use of multiple complementary security controls.

Zero trust: An approach that requires explicit, context-aware and least-privilege access decisions.

Segmentation: Division of an environment into zones with controlled communication.

DMZ: A controlled network zone for services requiring external reachability.

Hardening: Reduction of unnecessary functionality and insecure configuration.

Endpoint detection and response: Technology and processes for detecting and responding to endpoint threats.

Hypervisor: Software or firmware that manages virtual machines and shared physical resources.

Container: An isolated application package that commonly shares the host kernel.

Orchestration: Automated management of container deployment, networking and scaling.

Infrastructure as code: Machine-readable definition and management of infrastructure.

Shared responsibility: Division of security duties between a cloud provider and customer.

Identity federation: Use of a trusted identity system to authenticate to another service.

Microsegmentation: Fine-grained segmentation applied to workloads or applications.

SIEM: A platform that collects and correlates security events and logs.

RPO: Maximum tolerable data loss measured in time.

RTO: Target time for restoring a service after disruption.

Least privilege: Granting only the access necessary for an authorised task.

Policy as code: Machine-enforceable security and configuration rules.

Review Questions

Short Answer Questions

1. What is the difference between a vulnerability and an attack surface?

2. Why is network location insufficient as the sole basis for trust?

3. State two important controls for securing a hypervisor management plane.

4. What responsibilities normally remain with a customer in a SaaS environment?

5. Distinguish RPO from RTO.

Long Answer Questions

1. Explain how segmentation, zero trust and least privilege complement one another in an enterprise network.

2. Discuss the security lifecycle for operating-system vulnerability management, including prioritisation and exception handling.

3. Compare the principal security concerns of virtual machines and containers.

4. Explain the shared-responsibility model across IaaS, PaaS and SaaS, noting why provider-specific documentation is essential.

5. Describe an infrastructure monitoring and incident-response architecture for a hybrid organisation.

Analytical / Application Questions

1. A company discovers that a cloud storage bucket containing sensitive data is publicly accessible and that its administrator uses a long-lived access key. Analyse the immediate risks and propose a prioritised remediation plan.

2. Design zones and permitted communication flows for an organisation containing user endpoints, public web services, application servers, databases, backup systems and a management network. Justify the trust boundaries.

3. A containerised research service must be deployed rapidly by multiple teams. Develop a secure delivery approach covering image provenance, secrets, runtime privileges, orchestration policy, monitoring and recovery.

Multiple Choice Questions with Answers

Question 1

Which principle rejects implicit trust based solely on network location?

A. Zero trust

B. Open access

C. Data minimisation

D. Single sign-on

Correct Answer: A. Zero trust

Question 2

What is the primary purpose of network segmentation?

A. To eliminate the need for authentication

B. To reduce unauthorised communication and lateral movement

C. To guarantee that malware cannot enter a network

D. To replace vulnerability management

Correct Answer: B. To reduce unauthorised communication and lateral movement

Question 3

Which item is most specifically associated with protecting a container supply chain?

A. Signing and scanning approved images

B. Increasing wireless transmission power

C. Disabling all audit logs

D. Using shared administrator passwords

Correct Answer: A. Signing and scanning approved images

Question 4

In a typical IaaS arrangement, which responsibility normally remains with the customer?

A. Operating the provider’s physical data-centre buildings

B. Maintaining the provider’s power systems

C. Configuring guest operating systems and customer identities

D. Repairing the provider’s storage hardware

Correct Answer: C. Configuring guest operating systems and customer identities

Question 5

Why is a virtual-machine snapshot not automatically a backup?

A. It can depend on original storage and may preserve a compromised state

B. It always contains no data

C. It cannot be copied to another system

D. It automatically deletes production systems

Correct Answer: A. It can depend on original storage and may preserve a compromised state

Question 6

Which control most directly limits the damage caused by a stolen workload credential?

A. A long-lived credential with broad permissions

B. A short-lived identity with narrowly scoped permissions

C. A public management interface

D. An unmonitored shared account

Correct Answer: B. A short-lived identity with narrowly scoped permissions

Question 7

What does RPO describe?

A. The target time to restore service

B. The maximum tolerable amount of data loss expressed as time

C. The number of administrators allowed

D. The duration of a vulnerability scan

Correct Answer: B. The maximum tolerable amount of data loss expressed as time

Question 8

Which activity is part of vulnerability-management verification?

A. Confirming that remediation was effective

B. Removing all system inventories

C. Disabling patch testing

D. Granting unrestricted network access

Correct Answer: A. Confirming that remediation was effective

Question 9

Why should management-plane traffic receive special protection?

A. It carries no security significance

B. Compromise can provide broad control over infrastructure

C. It is always encrypted by default

D. It cannot be monitored

Correct Answer: B. Compromise can provide broad control over infrastructure

Question 10

Which statement best describes policy as code?

A. Security rules expressed in machine-enforceable form

B. A policy stored only in printed manuals

C. A replacement for all human oversight

D. A method of disabling configuration checks

Correct Answer: A. Security rules expressed in machine-enforceable form