Infrastructure, Network, Endpoint, and Workload Security

Introduction

Cloud security is not a single product or configuration setting. It is a coordinated practice for protecting infrastructure, communications, computing resources, data, applications, and operational processes. In a cloud environment, resources are created through software, exposed through programmable interfaces, and frequently changed through automation. These characteristics provide flexibility and scalability, but they also increase the consequences of weak identity controls, excessive network exposure, unpatched software, insecure images, and inadequate monitoring.

This chapter examines security controls for virtual networks, compute instances, storage, endpoints, containers, Kubernetes environments, and serverless workloads. The central principle is defence in depth: no individual control should be expected to prevent every failure. Segmentation reduces the reach of a compromise; firewalls regulate communication; hardened configurations reduce attack surface; vulnerability management identifies weaknesses; and runtime protection detects or blocks suspicious behaviour after deployment.

Cloud security also follows a shared-responsibility model. The cloud provider normally secures the physical facilities, hardware, and core platform services, while the customer remains responsible for appropriate configuration, identities, operating systems, applications, data, and workloads. The precise boundary differs between infrastructure, platform, and software services, so security responsibilities must be documented rather than assumed.

Learning Objectives

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

1. Explain the security responsibilities associated with cloud infrastructure and workloads.
2. Design basic segmentation using virtual networks, subnets, routes, and security controls.
3. Apply firewall and security-group principles to control traffic.
4. Describe hardening practices for compute instances, storage, and endpoints.
5. Explain vulnerability-management processes and prioritise remediation.
6. Distinguish the security requirements of virtual machines, containers, Kubernetes, and serverless workloads.
7. Recommend runtime-protection, monitoring, and incident-response controls.
8. Analyse a practical cloud-security scenario and justify a layered solution.

1. The Cloud Attack Surface

The attack surface is the set of assets, interfaces, configurations, software components, identities, and communication paths that could be exploited. In cloud computing it commonly includes:

• virtual machines, operating systems, agents, and installed software;
• virtual networks, routes, load balancers, firewalls, and public IP addresses;
• object stores, databases, file systems, snapshots, and backups;
• container images, registries, orchestration platforms, and deployment pipelines;
• serverless functions, event sources, dependencies, and execution roles;
• administrative consoles, application programming interfaces (APIs), and infrastructure-as-code repositories;
• laptops, mobile devices, privileged workstations, and developer endpoints.

A useful risk model links an asset, a threat, a vulnerability, and an impact. A publicly reachable administration service is an exposure; a weak password or unpatched service is a vulnerability; an attacker exploiting it is a threat event; and data loss or service interruption is the impact. Controls should therefore address both the probability of compromise and the consequences if compromise occurs.

Security design begins with an inventory. An organisation cannot reliably protect resources that it cannot identify. Inventory should include ownership, business purpose, environment, data classification, network location, software version, and lifecycle status. Tags, labels, configuration databases, and automated discovery can support this process, but ownership and review responsibilities must remain clear.

2. Virtual Network Security

2.1 Virtual networks and segmentation

A virtual network is a logically isolated environment in which cloud resources communicate through defined address ranges, routes, and policies. It may contain subnets for public-facing, application, management, and data services. Segmentation limits the paths available to an attacker and helps enforce different trust requirements.

A common three-tier design is:

• Presentation tier: load balancers or web servers that receive approved external traffic.
• Application tier: internal services that process requests but do not require direct Internet access.
• Data tier: databases and storage services that accept traffic only from approved application components.

Segmentation is not equivalent to security. Two resources in separate subnets may still communicate if routing and firewall rules permit it. Conversely, network separation may be bypassed through compromised identities, exposed management interfaces, shared credentials, or insecure application channels. Segmentation must therefore be combined with identity, encryption, monitoring, and secure configuration.

A practical segmentation policy should answer four questions:

1. Which sources may communicate with a resource?
2. Which destination, port, and protocol are required?
3. Is the communication initiated internally or externally?
4. How will the rule be reviewed, monitored, and removed when no longer necessary?

2.2 Routing and egress control

Routes determine where packets are sent, while firewall rules determine whether traffic is allowed. Security teams should review both. A private subnet with a route to an Internet gateway may become effectively public if resources have public addresses or if translation services allow uncontrolled outbound access.

Egress control restricts outbound communication. It can prevent malware from contacting command-and-control infrastructure, reduce data exfiltration opportunities, and enforce the use of approved update repositories and APIs. Egress policies may allow only required destinations, such as a package repository, logging service, identity endpoint, or database. Excessively broad outbound access is operationally convenient but weakens containment.

Network Address Translation can allow private resources to initiate outbound connections without accepting unsolicited inbound connections. It is useful but not a complete security boundary. Compromised resources can still make harmful outbound requests, and application-layer controls remain necessary.

2.3 Firewalls and security groups

Cloud platforms commonly provide several layers of traffic control:

A stateful firewall remembers an allowed connection and permits legitimate response traffic automatically. A stateless filter evaluates each packet independently, so return traffic generally requires a corresponding rule. Administrators must understand the provider’s exact behaviour rather than relying on product names.

Firewall rules should follow least privilege. A rule permitting TCP port 22 from 0.0.0.0/0 exposes SSH to the entire IPv4 Internet and should normally be replaced by private administration paths, a bastion service, a virtual private network, or an identity-aware access mechanism. Rules should specify source, destination, protocol, port, action, purpose, owner, and expiry or review date.

“Deny by default” is a strong baseline, but it must be implemented carefully. A default deny policy can interrupt essential services if dependency mapping is incomplete. Changes should be tested in a non-production environment, monitored in log-only mode where available, and introduced through controlled change management.

2.4 Encryption in transit

Network segmentation controls reachability; encryption protects the content of permitted communication. Transport Layer Security (TLS) should protect web traffic, administrative sessions, APIs, and service-to-service communication where confidentiality or integrity is required. Certificates require ownership, renewal, revocation, and secure private-key storage.

Internal traffic should not automatically be considered trusted. A compromised workload may be able to observe or misuse internal services. Mutual TLS, service identities, signed requests, and authorisation at the application layer provide stronger assurance than network location alone.

3. Compute and Storage Security

3.1 Compute-instance hardening

A compute instance is a virtual machine or equivalent host allocated from a cloud provider. Hardening reduces unnecessary functionality and makes exploitation more difficult. A baseline should include:

• use of approved, minimal operating-system images;
• removal or disabling of unnecessary packages, services, users, and ports;
• secure authentication, including strong keys, multifactor administration, and no shared accounts;
• restricted administrative access through private paths or controlled management services;
• timely operating-system and application patching;
• host-based firewall configuration;
• time synchronisation for reliable event correlation;
• encryption of attached volumes and protection of backup keys;
• endpoint detection, anti-malware, integrity monitoring, and centralised logging where appropriate;
• secure configuration of agents, metadata services, and startup scripts;
• immutable or reproducible deployment rather than uncontrolled manual modification.

Hardening should be expressed as a repeatable baseline. Examples include disabling password-based SSH, restricting root or administrator use, enforcing screen locks on administrative workstations, and requiring approved cryptographic protocols. A baseline without measurement is only an intention; compliance tools and configuration assessments should identify drift.

3.2 Metadata services and instance identity

Cloud instances often access temporary credentials through a metadata service. These credentials allow applications to call cloud APIs. If an attacker can trick a vulnerable application into requesting metadata, the attacker may obtain the instance role’s permissions. Organisations should use the provider’s hardened metadata protocol, restrict access to metadata endpoints, avoid long-lived credentials, and assign narrowly scoped roles.

The principle of least privilege applies to both human and machine identities. An application that reads one storage bucket should not receive administrator permissions. Roles should be separated by workload and environment, and unused permissions should be removed.

3.3 Storage security

Cloud storage includes object storage, block volumes, file systems, databases, snapshots, and backups. Security controls should address confidentiality, integrity, availability, and recoverability.

Object storage is especially vulnerable to misconfiguration. Common controls include:

• private-by-default access;
• explicit bucket or container policies;
• blocking public access unless a documented business requirement exists;
• encryption at rest using provider-managed or customer-managed keys as appropriate;
• versioning and object-lock controls for critical records;
• access logging and data-loss monitoring;
• lifecycle policies that delete or archive data according to retention requirements;
• separate accounts or projects for production and backup copies;
• tested restoration procedures.

Encryption at rest is valuable, but it does not compensate for an identity that is authorised to read the data. Key management must include separation of duties, rotation policies, access logging, backup, and recovery procedures. Data classification should guide the choice of controls. Public information, internal business data, personal information, and regulated records do not have identical requirements.

3.4 Backup and recovery security

Backups are security assets and targets. An attacker who gains administrative access may attempt to delete or encrypt backups before launching a destructive attack. Important controls include immutable or write-once copies, separate administrative credentials, cross-account or cross-region storage, encryption, retention locks, and periodic restoration tests.

Recovery objectives should be explicit. The recovery point objective (RPO) is the maximum acceptable amount of data loss measured in time. The recovery time objective (RTO) is the target time for restoring service. RPO and RTO are business requirements that influence replication frequency, architecture, cost, and operational procedures; they are not merely technical settings.

4. Endpoint Security in Cloud Operations

Cloud infrastructure is administered through endpoints such as laptops, jump hosts, build agents, and mobile devices. An attacker may compromise a developer laptop and use its tokens or browser sessions to access cloud resources, even when the cloud network itself is well segmented.

Endpoint security should include:

• centrally managed operating-system and application updates;
• disk encryption and secure boot where supported;
• multifactor authentication and phishing-resistant credentials for privileged access;
• endpoint detection and response;
• device posture checks before access to sensitive systems;
• removal of local administrator rights unless justified;
• secure configuration of browsers, terminals, and credential stores;
• restricted use of personal devices for administrative activities;
• short-lived cloud credentials and session timeouts;
• logging of privileged actions and anomalous access.

The administrative workstation should be treated as a high-value asset. A dedicated privileged-access workstation, or an equivalent controlled environment, reduces exposure to ordinary browsing, untrusted extensions, and consumer applications. Secrets should not be stored in source code, shell history, images, or unencrypted local files.

5. Vulnerability Management

Vulnerability management is a lifecycle rather than a periodic scan. It includes discovery, assessment, prioritisation, remediation, verification, and reporting.

5.1 Discovery and assessment

Scanning may identify missing patches, insecure configurations, vulnerable libraries, exposed services, and unsupported software. Different scanning methods have different coverage:

• Network scanning observes reachable ports and services.
• Authenticated host scanning examines packages and configurations more accurately.
• Application scanning tests web and API behaviour.
• Software composition analysis identifies vulnerable open-source dependencies.
• Container-image scanning examines operating-system packages and libraries.
• Cloud-configuration assessment detects public storage, excessive permissions, and insecure network settings.
• Runtime monitoring identifies vulnerabilities and suspicious behaviour in deployed systems.

A scanner’s severity rating is not the same as business risk. A critical vulnerability on an isolated, non-production host may require a different response from a medium vulnerability on an Internet-facing payment service.

A practical prioritisation model considers exploitability, exposure, asset importance, data sensitivity, compensating controls, and available remediation. A simple qualitative matrix can classify findings as critical, high, medium, or low, but organisations should document the criteria and service-level targets for each class.

5.2 Remediation strategies

Remediation may involve patching, upgrading, replacing a component, changing configuration, restricting network access, disabling a feature, or applying a compensating control. Virtual machine environments often benefit from patched golden images and replacement of instances rather than indefinite manual patching. Containers should be rebuilt from updated base images rather than modified interactively in production.

After remediation, verification is essential. A ticket marked “fixed” is not evidence that the weakness has disappeared. Rescanning, configuration validation, version checks, and targeted testing provide stronger assurance. Exceptions should have a business owner, justification, risk acceptance, compensating controls, and expiry date.

6. Container Security

Containers package an application and its dependencies while sharing the host operating-system kernel. They are not equivalent to virtual machines: a container escape may expose the host or other workloads. Container security therefore covers the image, registry, build process, runtime, host, and orchestration platform.

6.1 Secure image construction

A secure container image should:

• use a trusted and minimal base image;
• pin or otherwise control dependency versions;
• remove build tools and secrets from the final image;
• run as a non-root user where possible;
• define a read-only or minimally writable file system;
• include vulnerability and malware scanning in the build pipeline;
• be signed and verified before deployment;
• be rebuilt regularly as vulnerabilities and base-image updates emerge.

A .dockerignore file or equivalent build control prevents unnecessary files from entering the build context. Secrets must be supplied through an approved secret-management mechanism, not embedded in image layers or environment files committed to source control.

6.2 Registry and runtime controls

Container registries should require authentication, enforce retention policies, log downloads and pushes, and restrict who may publish production images. Admission controls can reject images that are unsigned, critically vulnerable, run as root, use prohibited capabilities, or originate from unapproved registries.

At runtime, controls should restrict Linux capabilities, privileged mode, host-network access, host-file-system mounts, and inter-container communication. Resource limits reduce the risk that one workload consumes all available CPU or memory. Runtime detection should monitor process execution, unexpected network connections, file changes, and attempts to access sensitive host or metadata resources.

7. Kubernetes Security

Kubernetes introduces a control plane, worker nodes, workloads, service accounts, network policies, admission mechanisms, and configuration objects. Its flexibility creates a broad security domain.

Important Kubernetes controls include:

1. Control-plane protection: restrict API-server access, enable strong authentication, protect audit logs, and keep the platform supported and patched.
2. Role-Based Access Control (RBAC): assign the minimum permissions required to users, groups, and service accounts. Avoid broad cluster-administrator privileges.
3. Service-account security: use separate accounts for workloads, disable unnecessary token mounting, and use short-lived or projected credentials where supported.
4. Network policies: define which namespaces, pods, and ports may communicate. Without effective policies, many clusters allow broad internal connectivity.
5. Pod security: prohibit privileged containers, host namespaces, unsafe volume mounts, and unnecessary Linux capabilities.
6. Secrets management: encrypt secrets at rest, restrict access, avoid exposing them in logs, and consider an external secrets manager.
7. Node security: harden operating systems, isolate workloads appropriately, patch nodes, and protect the container runtime.
8. Admission control: enforce organisational policies before workloads are accepted.
9. Observability: collect API audit events, workload logs, network telemetry, and runtime alerts.

Kubernetes namespaces provide organisation and policy scope, but they are not automatically complete isolation boundaries. Strong isolation requirements may require separate clusters, accounts, nodes, or even cloud projects.

8. Serverless Workload Security

Serverless functions and managed event-driven services remove much infrastructure administration but do not remove security responsibility. The main concerns are identity, event validation, dependency security, data protection, and execution behaviour.

Each function should have a dedicated execution role with only the permissions it requires. Input from events, queues, webhooks, and storage notifications must be validated because event sources may be spoofed, replayed, malformed, or unexpectedly large. Functions should use secure dependency management, short execution timeouts, memory limits, concurrency controls, and protected environment variables.

Serverless applications can suffer from excessive permissions, insecure dependency libraries, injection vulnerabilities, sensitive data in logs, and uncontrolled invocation costs. Monitoring should record invocations, errors, latency, permission failures, unusual geographic sources, and sudden changes in concurrency. A function that can write to a database should not automatically be able to read the entire database or modify identity policies.

9. Runtime Protection and Detection

Preventive controls are necessary but cannot guarantee prevention. Runtime protection detects deviations from expected behaviour and can support containment. Examples include host-based intrusion detection, endpoint detection and response, container runtime sensors, cloud workload protection platforms, file-integrity monitoring, network detection, and cloud audit analysis.

Detection engineering should begin with meaningful behaviours rather than an indiscriminate collection of alerts. Examples include:

• a workload accessing a metadata endpoint unexpectedly;
• a service account creating new privileged identities;
• a container launching a shell when its normal function never does so;
• a database exporting an unusual volume of records;
• a production workload communicating with an unapproved external domain;
• a new public storage policy being created.

Alerts require owners, severity definitions, response procedures, and testing. Excessive false positives lead to alert fatigue, while weak telemetry creates blind spots. Logs should be time-synchronised, protected from alteration, retained according to legal and operational requirements, and made available to incident responders.

10. Illustrative Case: Securing an Online Learning Platform

Background

A fictional college operates an online learning platform in the cloud. The system contains a public web interface, application services, a relational database, object storage for assignments, a Kubernetes-based grading service, and serverless functions that send notifications. Developers administer the environment from ordinary laptops.

Problem

A security review identifies three weaknesses: the database is reachable from a broad internal network range, several container images contain outdated libraries, and an object-storage policy permits public access to some assignment files. Administrative access uses long-lived credentials, and backup restoration has never been tested.

Analysis

The weaknesses interact. If an attacker compromises a web component, broad network access may permit database probing. A vulnerable image may provide a second entry point. Public object access creates direct data exposure even without a workload compromise. Long-lived credentials increase the potential duration and impact of endpoint theft. Untested backups create uncertainty about recovery.

Approach and solution

The college implements the following layered design:

1. Public traffic terminates at a load balancer protected by a web application firewall.
2. Web, application, grading, and database services are placed in separate network segments.
3. The database accepts connections only from approved application identities and ports.
4. Egress rules restrict workloads to required APIs, repositories, and logging services.
5. Object storage becomes private by default, with time-limited authorised links for legitimate downloads.
6. Container images are rebuilt from approved minimal bases, scanned in the pipeline, signed, and admitted only when policy requirements are met.
7. Kubernetes service accounts receive narrowly scoped permissions, and network policies restrict namespace communication.
8. Serverless notification functions receive only the permission to publish approved messages.
9. Administrators use multifactor authentication, short-lived roles, managed devices, and a controlled access path.
10. Backups are isolated, immutable, encrypted, and restored during a scheduled exercise.
11. Central logging and runtime detection monitor identity changes, unusual data access, image execution, and public-policy changes.

Outcome

The revised design reduces unnecessary reachability, limits the permissions available to compromised components, prevents unauthorised public storage access, and improves the college’s ability to detect and recover from incidents. It does not eliminate risk: vulnerabilities may still appear, legitimate credentials may be misused, and application defects require separate testing. The college therefore combines technical controls with ownership, review, training, and incident exercises.

Learning points

The case demonstrates that cloud security is a system of mutually reinforcing controls. Network segmentation alone would not fix public storage. Image scanning alone would not protect stolen credentials. Recovery testing alone would not prevent data exposure. Effective security aligns architecture, identity, configuration, software supply chain, monitoring, and governance.

11. Governance, Ethics, and Compliance

Infrastructure and workload security often processes personal, educational, financial, health, or commercially sensitive information. Security controls must therefore support privacy, lawful processing, retention limits, and accountable access. Logging should be proportionate and protected because logs may themselves contain personal data or confidential content.

Organisations should maintain clear ownership for cloud accounts, networks, images, clusters, functions, and data stores. Policy-as-code can enforce baseline requirements consistently, but automated enforcement should include exception processes and human review for high-impact decisions. Security teams should avoid collecting unnecessary telemetry, using intrusive monitoring without justification, or treating all users as inherently malicious.

Regulatory obligations vary by jurisdiction and sector. Relevant requirements may address access control, breach notification, encryption, auditability, data residency, records retention, and supplier assurance. Compliance does not guarantee security; it provides a set of obligations and evidence requirements that must be integrated with risk management.

12. Contemporary Developments and Best Practices

Cloud security is increasingly automated. Infrastructure-as-code scanning, continuous configuration assessment, software bills of materials, signed artifacts, workload identity, confidential-computing options, and cloud-native detection platforms can improve assurance. Artificial intelligence may assist with alert triage, anomaly detection, code review, and vulnerability prioritisation, but AI outputs require validation. Attackers can also use AI to generate convincing phishing, discover weaknesses, or automate reconnaissance.

A practical baseline for diploma-level practitioners is:

• inventory every resource and assign an owner;
• make networks and storage private by default;
• use least privilege for people, services, functions, and containers;
• separate production, development, and testing environments;
• patch and rebuild from trusted baselines;
• scan dependencies, images, hosts, and cloud configurations;
• protect endpoints used for administration;
• encrypt sensitive data in transit and at rest;
• centralise and protect logs;
• test detection, backup restoration, and incident-response procedures;
• review firewall rules, permissions, exceptions, and public exposure regularly.

Security is a continuous process. New resources, dependencies, vulnerabilities, identities, and threats appear throughout the lifecycle. The most mature organisations treat secure configuration, monitoring, and recovery as normal operational activities rather than emergency projects.

Chapter Summary

Cloud infrastructure and workload security requires layered protection across virtual networks, compute instances, storage, administrative endpoints, containers, Kubernetes, and serverless services. Segmentation limits communication paths, while firewalls and egress controls regulate permitted traffic. Hardening reduces attack surface, and encryption protects data moving across approved paths and stored on cloud services.

Vulnerability management involves discovery, risk-based prioritisation, remediation, verification, and controlled exceptions. Containers require secure images, trusted registries, admission policies, and runtime restrictions. Kubernetes security depends on control-plane protection, RBAC, service-account governance, network policies, pod security, secrets management, and auditability. Serverless security focuses on least-privilege execution roles, input validation, dependency management, and invocation monitoring.

No preventive control is complete by itself. Runtime detection, protected logging, tested backups, incident response, governance, and endpoint security are essential complements. Effective cloud security is therefore a continuous discipline involving architecture, automation, human judgement, and accountable ownership.

Key Terms

Attack surface: The assets, interfaces, configurations, and paths that may be attacked.

Cloud shared responsibility: The division of security duties between a cloud provider and its customer.

Defence in depth: The use of multiple independent or complementary security controls.

Egress control: Regulation of outbound network communication from workloads.

Firewall: A control that permits or denies traffic according to defined rules.

Hardening: Reducing unnecessary services, privileges, software, and insecure settings.

Infrastructure as code: Managing infrastructure through machine-readable, version-controlled definitions.

Kubernetes: An orchestration platform for deploying and managing containerised workloads.

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

Network segmentation: Dividing a network into zones with controlled communication paths.

RBAC: Role-Based Access Control, which assigns permissions through roles.

Runtime protection: Controls that detect or prevent suspicious behaviour during execution.

Security group: A cloud resource-level traffic-control mechanism, commonly stateful.

Serverless: A cloud execution model in which the provider manages much of the underlying infrastructure.

Threat: A circumstance or actor capable of causing harm.

Vulnerability: A weakness that may be exploited.

Web application firewall: A control that filters application-layer web requests.

Workload: An application, service, function, container, or virtual machine running in the cloud.

Review Questions

Short Answer Questions

1. Why is network segmentation useful even though it does not provide complete security?
2. Distinguish between ingress and egress control.
3. State three important practices for hardening a compute instance.
4. Why should container images be rebuilt instead of manually modified in production?
5. What is the purpose of least privilege for a serverless function?

Long Answer Questions

1. Explain how a three-tier cloud architecture can be secured using segmentation, firewall rules, identity, and encryption.
2. Describe the complete vulnerability-management lifecycle and explain why verification is necessary after remediation.
3. Compare the security requirements of virtual machines, containers, Kubernetes workloads, and serverless functions.
4. Discuss the role of endpoint security in protecting cloud administration.
5. Explain how backup design, logging, runtime detection, and incident response contribute to resilience.

Analytical / Application Questions

1. A database is reachable from every subnet in a production virtual network. Analyse the risks and propose a revised access-control design.
2. A Kubernetes workload requires access to one object-storage location but has a cluster-administrator role. Identify the security weaknesses and recommend corrective actions.
3. An organisation discovers that an employee laptop used for cloud administration is infected with malware. Develop an immediate containment and follow-up response plan that addresses credentials, endpoints, cloud resources, and evidence preservation.

Multiple Choice Questions with Answers

Question 1

Which design best supports a least-privilege network architecture for a three-tier application?

A. Allow all tiers to communicate on all ports

B. Allow only required sources, destinations, protocols, and ports between tiers

C. Place every tier on the public Internet

D. Disable logging to improve network performance

Correct Answer: B. Allow only required sources, destinations, protocols, and ports between tiers

Question 2

What is the primary purpose of egress control?

A. To regulate outbound communication from workloads

B. To encrypt data stored in object storage

C. To replace identity and access management

D. To increase the CPU capacity of a virtual machine

Correct Answer: A. To regulate outbound communication from workloads

Question 3

Which practice most directly reduces the risk of stolen, long-lived cloud credentials?

A. Using shared administrator passwords

B. Embedding credentials in container images

C. Using short-lived roles and multifactor authentication

D. Allowing unrestricted public access to management ports

Correct Answer: C. Using short-lived roles and multifactor authentication

Question 4

Why should secrets not be embedded in container image layers?

A. Image layers may retain and expose the secrets

B. Secrets make containers run faster

C. Image layers cannot contain configuration files

D. Registries automatically delete all secrets

Correct Answer: A. Image layers may retain and expose the secrets

Question 5

Which Kubernetes control limits what users and service accounts can do?

A. RBAC

B. DNS caching

C. Object versioning

D. Network Address Translation

Correct Answer: A. RBAC

Question 6

A function only needs to publish messages to one notification service. Which permission is most appropriate?

A. Full cloud administrator access

B. Read and write access to every database

C. Permission to publish only to the required notification service

D. Permission to modify identity policies

Correct Answer: C. Permission to publish only to the required notification service

Question 7

Which statement about vulnerability severity and risk is most accurate?

A. A scanner’s severity score always equals business risk

B. Business risk also depends on exposure, asset importance, and compensating controls

C. Only production software can contain vulnerabilities

D. A vulnerability requires no action if it has not yet been exploited

Correct Answer: B. Business risk also depends on exposure, asset importance, and compensating controls

Question 8

What is a major benefit of immutable backups?

A. They prevent all application vulnerabilities

B. They make unauthorised alteration or deletion more difficult

C. They remove the need for restoration tests

D. They automatically provide unlimited storage

Correct Answer: B. They make unauthorised alteration or deletion more difficult

Question 9

Which control is most closely associated with filtering malicious HTTP requests?

A. Web application firewall

B. Block storage encryption

C. Time synchronisation

D. Container resource limit

Correct Answer: A. Web application firewall

Question 10

Why is runtime monitoring needed in addition to preventive controls?

A. Preventive controls guarantee that compromise cannot occur

B. Runtime monitoring can identify suspicious behaviour after deployment

C. Runtime monitoring replaces secure configuration

D. Runtime monitoring eliminates the need for backups

Correct Answer: B. Runtime monitoring can identify suspicious behaviour after deployment