Cloud Compute and Application Architecture

Introduction

Cloud application architecture concerns the way computing resources, application components, communication mechanisms, and operational controls are assembled to deliver reliable software. The central architectural decision is not simply whether to use a virtual machine, container, Kubernetes, or a serverless function. It is how to select and combine these models according to workload characteristics, quality attributes, organisational capability, and risk.

A modern cloud platform commonly contains several computational layers. Infrastructure-as-a-Service provides virtual machines and networks; container platforms package applications consistently; Kubernetes orchestrates container workloads; Function-as-a-Service executes short-lived event-driven code; and application architectures such as microservices and APIs organise business capabilities. Service meshes add a communication and policy layer for distributed services.

These technologies solve different problems. Virtual machines provide strong isolation and broad operating-system compatibility. Containers improve packaging efficiency and deployment consistency. Kubernetes supplies declarative orchestration but introduces operational complexity. Serverless functions reduce infrastructure management but impose execution, integration, and observability constraints. Microservices enable independent evolution but increase distributed-systems complexity. A sound architect therefore evaluates trade-offs rather than treating any model as universally superior.

Learning Objectives

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

1. Explain the architectural roles of virtual machines, containers, Kubernetes, serverless functions, APIs, microservices, and service meshes.
2. Select an appropriate compute model for a given workload.
3. Design an application architecture that addresses scalability, availability, security, portability, performance, and cost.
4. Compare orchestration and deployment approaches.
5. Analyse operational trade-offs, including observability, resilience, governance, and organisational capability.
6. Apply architectural principles in a realistic cloud case.

1. Architectural Foundations

1.1 Compute as an architectural abstraction

A compute abstraction hides some physical implementation while exposing resources that applications can consume. The abstraction determines what the development and operations teams must manage.

The choice is influenced by several quality attributes:

• Performance: latency, throughput, startup time, and resource efficiency.
• Scalability: ability to handle increased demand by adding resources or increasing resource size.
• Availability: ability to provide service when components fail.
• Portability: ease of moving workloads between environments.
• Operability: ease of deployment, monitoring, troubleshooting, and recovery.
• Security: isolation, identity, vulnerability management, and policy enforcement.
• Cost efficiency: relationship between workload demand and consumed resources.

No architectural model maximises all these attributes simultaneously. For example, a highly portable container image may still depend on a proprietary database or identity service, while a managed serverless service may reduce operational work at the cost of portability.

1.2 Control plane and data plane

Cloud platforms are commonly divided into a control plane and a data plane. The control plane stores desired configuration and makes scheduling, provisioning, and policy decisions. The data plane executes workloads and carries application traffic. In Kubernetes, the API server, scheduler, and controllers belong to the control plane; worker nodes, pods, and application network traffic belong primarily to the data plane.

This distinction matters operationally. A control-plane outage may prevent new deployments or rescheduling while existing workloads continue to serve traffic. A data-plane failure directly affects application execution. Architects should therefore design independent failure domains, protect control-plane credentials, and monitor both planes.

Figure: A layered cloud application architecture. The layers are logical; a particular platform may combine or redistribute their responsibilities.

2. Virtual Machines

A virtual machine (VM) is a software-defined computer that presents virtual CPU, memory, storage, and network devices to a guest operating system. A hypervisor isolates multiple VMs on a physical host. Type 1 hypervisors run directly on hardware, whereas Type 2 hypervisors run above a host operating system and are more common in desktop development.

VMs are appropriate when an application requires a particular operating system, kernel module, legacy runtime, specialised security boundary, or strong administrative control. They also support lift-and-shift migration, in which an existing server workload is moved with minimal code modification.

A VM architecture normally includes an image, instance size, virtual network interface, storage volumes, identity permissions, and bootstrap configuration. Images should be versioned, minimised, scanned for vulnerabilities, and rebuilt rather than modified manually. Immutable infrastructure treats an instance as replaceable: a change produces a new image or configuration version instead of an undocumented in-place edit.

Strengths and limitations

VMs provide mature isolation, predictable operating-system semantics, and compatibility with traditional monitoring and backup tools. They are useful for databases requiring dedicated resources, licensed software, and workloads with long-lived processes.

Their disadvantages include slower provisioning, duplicated guest operating systems, patching obligations, and lower workload density than containers. VM scaling is also often coarser-grained. A small increase in application demand may require adding an entire instance, leaving unused capacity.

A practical VM design uses multiple availability zones, automated health checks, autoscaling groups, encrypted disks, least-privilege identities, centralised logging, and automated patch or replacement procedures. A VM is not secure merely because it is isolated: exposed management ports, weak credentials, vulnerable images, and excessive permissions remain significant risks.

3. Containers and Container Platforms

A container packages an application and its user-space dependencies while sharing the host operating-system kernel. An image is an immutable, layered filesystem plus metadata such as the startup command and environment expectations. A running container is an instantiation of that image.

Containers differ from VMs in the isolation boundary. A VM virtualises hardware and runs a complete guest kernel; a container isolates processes while sharing a host kernel. Consequently, containers usually start faster and consume fewer resources, but kernel compatibility and runtime security require attention.

Image and runtime practices

A professional container supply chain should:

1. Use a small, trusted base image.
2. Pin dependencies and record provenance.
3. Build reproducibly in an automated pipeline.
4. Scan images and dependencies for known vulnerabilities.
5. Run as a non-root user where possible.
6. Use read-only filesystems and drop unnecessary Linux capabilities.
7. Keep secrets outside images.
8. Sign images and verify signatures at deployment.
9. Define CPU and memory requests and limits.
10. Emit structured logs and expose health endpoints.

A container should generally be treated as ephemeral. Persistent state belongs in a managed database, object store, or explicitly designed persistent volume. Storing important data only in a writable container filesystem creates a recovery problem when the container is replaced.

Portability: image versus platform

OCI-compatible images improve portability at the packaging layer, but complete portability is broader. Applications may depend on a cloud load balancer, proprietary identity API, storage semantics, DNS behaviour, or managed database. Portability should therefore be assessed at several layers: image, orchestration manifest, platform services, data, and operational skills.

4. Kubernetes and Orchestration

Kubernetes is a declarative orchestration platform for containerised workloads. The operator describes a desired state, such as the number of replicas, container image, resource requirements, and network policy. Controllers continuously compare actual state with desired state and take corrective action.

Important Kubernetes concepts include:

• Pod: the smallest deployable unit, normally containing one application container and optionally tightly coupled sidecars.
• Deployment: manages replicated, usually stateless pods and supports controlled rollout.
• StatefulSet: provides stable identity and ordered behaviour for selected stateful workloads.
• Service: supplies stable network discovery for a group of pods.
• Ingress or gateway: exposes HTTP or other application traffic through routing rules.
• ConfigMap and Secret: provide configuration and sensitive values, subject to appropriate encryption and access controls.
• Namespace: supports logical separation and policy boundaries.
• DaemonSet: schedules a pod on selected nodes, commonly for agents.
• Job and CronJob: run finite or scheduled tasks.

Kubernetes is powerful because the same desired-state model supports scheduling, rolling updates, self-healing, service discovery, and horizontal scaling. It is not, however, a complete application architecture. It does not automatically provide correct database design, business-level resilience, secure identity, meaningful observability, or operational competence.

Scheduling and resources

Kubernetes schedules pods using resource requests, node capacity, affinity rules, taints, and tolerations. A request is used for placement; a limit constrains consumption. Incorrect values produce poor outcomes. Requests that are too low cause contention, while values that are too high reduce packing efficiency and may prevent scheduling.

Horizontal Pod Autoscaling changes replica count according to metrics such as CPU utilisation or application-specific request rate. Scaling should account for startup time, downstream capacity, queue depth, and stabilisation behaviour. If a database cannot handle additional concurrent requests, adding application replicas may worsen the incident.

Deployment strategies

A rolling deployment gradually replaces old pods with new ones. It reduces downtime but requires backward-compatible interfaces and careful readiness checks. Blue-green deployment maintains two environments and switches traffic between them, simplifying rollback at the cost of temporary duplicate capacity. Canary deployment sends a small proportion of traffic to a new version and expands exposure when health and business metrics remain acceptable.

Readiness probes determine whether a pod should receive traffic; liveness probes determine whether it should be restarted. A liveness probe that fails because a downstream database is temporarily unavailable can create a restart storm. Probes must test the condition they are intended to represent and use suitable timeouts and thresholds.

5. Serverless Functions and Event-Driven Architecture

A serverless function is a managed execution unit invoked by an event, HTTP request, schedule, or message. The provider manages servers, runtime placement, and much of the scaling. The customer supplies function code, dependencies, permissions, configuration, and event integration.

Functions are effective for image transformation, notifications, scheduled automation, stream processing, lightweight APIs, and asynchronous business workflows. They encourage small units of computation and can scale rapidly when events are independent.

Important constraints include execution duration limits, memory limits, temporary local storage, concurrency controls, runtime support, and cold-start latency. A cold start occurs when the platform prepares an execution environment before handling an invocation. Provisioned or pre-warmed capacity may reduce latency but increases cost.

Event-driven designs require explicit delivery semantics. A message may be delivered more than once, so handlers should be idempotent: processing the same event repeatedly should not produce an incorrect additional effect. This may require a unique event identifier, a deduplication store, transactional state changes, or an idempotency key.

Queues and event buses decouple producers from consumers and absorb bursts. However, asynchronous processing introduces eventual consistency, ordering questions, poison messages, retry policies, and dead-letter handling. A retry without backoff and a maximum attempt limit can amplify an outage.

Serverless cost reasoning

A simplified function compute charge can be estimated as:

where C is compute cost, N is invocation count, d is billed duration, m is allocated memory expressed in the provider’s billing unit, and r is the rate per unit of duration and memory. This model is only an approximation: request charges, provisioned concurrency, data transfer, and other services may add cost. Units must match the provider’s pricing definition.

For example, if a workload makes 2,000,000 invocations, each billed for 0.2 seconds, with a normalised memory factor of 1, and the rate is $0.000016 per memory-unit-second, then:

C = 2,000,000 × 0.2 × 1 × 0.000016 = 6.40

The result excludes invocation fees and related services. The example demonstrates method, not a universal provider price.

6. Microservices, APIs, and Service Meshes

6.1 Microservices

Microservices decompose an application into independently deployable services aligned with business capabilities. Each service owns a well-defined responsibility and communicates through explicit contracts. The architectural objective is not to maximise the number of services; it is to create boundaries that permit independent change, scaling, and ownership.

A good service boundary usually reflects a coherent domain capability, minimises synchronous dependencies, and gives one team clear responsibility. Each service should own its data or at least its data model. A shared database can create hidden coupling: a schema change in one service may unexpectedly break others.

Microservices trade code-level modularity for distributed-systems complexity. Network calls fail, messages are delayed, clocks differ, partial success occurs, and debugging crosses process boundaries. Distributed transactions are difficult; patterns such as sagas, transactional outboxes, compensating actions, and event-driven integration may be appropriate, but each introduces its own complexity.

6.2 APIs

An API is a contract through which software components interact. A sound API defines resources or operations, data formats, authentication, authorisation, error semantics, timeouts, idempotency, rate limits, and versioning.

REST commonly uses HTTP resources and standard methods; gRPC uses strongly typed procedure calls and efficient binary serialisation; asynchronous APIs use queues, topics, and event schemas. The choice should follow interaction needs rather than fashion.

API gateways can centralise routing, authentication integration, throttling, request transformation, and access logging. They should not become an uncontrolled business-logic monolith. API contracts should be documented, tested for compatibility, and governed through a lifecycle that includes deprecation and consumer communication.

6.3 Service mesh

A service mesh places communication capabilities in a platform layer, commonly through sidecar or node-level proxies. It can provide mutual TLS, service discovery, traffic splitting, retries, timeouts, circuit breaking, telemetry, and policy enforcement without requiring every service team to implement these mechanisms independently.

A mesh is not automatically beneficial. It adds proxies, configuration, certificates, failure modes, resource consumption, and a new control plane. Retries are especially dangerous when applied indiscriminately: retrying a non-idempotent operation can duplicate effects, while retrying an already overloaded dependency increases load. Timeouts, retry budgets, and circuit-breaking policies must be designed from end to end.

7. Comparing Architectural Choices

A structured decision process is more reliable than selecting technology by popularity.

Step 1: Characterise the workload

Record request rate, payload size, latency objectives, execution duration, concurrency, statefulness, burstiness, data gravity, regulatory requirements, and failure tolerance. Distinguish average demand from peak demand.

Step 2: Identify the dominant constraints

A legacy operating system may favour VMs. Highly variable, event-driven demand may favour functions. Many independently deployed services may justify Kubernetes. A small team with limited platform expertise may prefer a managed container or application platform.

Step 3: Compare total operational burden

Include image building, patching, cluster upgrades, incident response, observability, networking, security controls, and skills. The apparent infrastructure price is not the full cost.

Step 4: Validate experimentally

Use representative load tests and failure tests. Measure p50, p95, and p99 latency where tail behaviour matters. Test startup, scaling, dependency failure, message duplication, deployment rollback, and recovery from zone loss.

8. Reliability, Security, and Observability

8.1 Reliability patterns

Reliability is designed through redundancy, controlled failure, and recovery. Stateless application instances can be distributed across zones behind a load balancer. Stateful services require replication, backup, recovery testing, and clear consistency decisions.

Useful patterns include timeouts, bounded retries with exponential backoff and jitter, circuit breakers, bulkheads, rate limiting, queue-based load levelling, health checks, and graceful degradation. A timeout should be shorter than the caller’s overall deadline and should reflect the business operation. Unlimited retries are rarely safe.

Availability targets should be connected to user impact. If availability is represented as a fraction A, then the permitted unavailability over a period of duration T is:

Here D and T use the same time unit. For a 99.9% monthly target and a 30-day month, D = (1 − 0.999) × 30 × 24 × 60 ≈ 43.2 minutes. This is an illustrative service-level objective calculation; contractual definitions may exclude approved maintenance or specific failure classes.

8.2 Security

Security controls should apply across the software supply chain and runtime. These include identity-based access, short-lived credentials, network segmentation, encryption in transit and at rest, secret management, image signing, vulnerability remediation, admission policies, audit logging, and workload isolation.

The principle of least privilege applies to service accounts, CI/CD pipelines, Kubernetes controllers, functions, and human operators. Kubernetes Secrets are not automatically equivalent to a dedicated secrets-management system; access control, encryption, rotation, and auditability must be verified.

8.3 Observability

Observability combines logs, metrics, and traces. Logs explain events, metrics show trends and saturation, and traces connect a request across services. Correlation identifiers should be propagated through synchronous and asynchronous boundaries. Useful indicators include error rate, latency, traffic, and saturation, but business measures—such as completed orders or failed payments—are equally important.

OpenTelemetry and similar instrumentation approaches can standardise telemetry collection, but instrumentation does not replace analysis. Excessive high-cardinality labels can increase cost and reduce query performance. Sensitive personal or financial data must not be placed casually in logs or traces.

9. Applied Case: Illustrative Online Retail Platform

Background

The following is a fictional illustrative case. Northstar Retail operates an online store with a product catalogue, customer accounts, checkout, payment integration, fulfilment notifications, and an administrative reporting system. Demand is moderate on ordinary days but can increase tenfold during promotional campaigns. The organisation has six software engineers and limited experience operating Kubernetes.

Problem

The existing monolithic VM-based application is difficult to scale selectively. A slow reporting query affects checkout performance, deployments require maintenance windows, and promotional traffic causes resource exhaustion. The company wants faster releases without compromising payment integrity.

Analysis

The catalogue and product search are read-heavy and can be scaled horizontally. Checkout is latency-sensitive and integrates with an external payment provider. Notifications are naturally asynchronous. Reporting is computationally variable and should not compete with transactional traffic. The small team makes a self-managed Kubernetes cluster a significant operational risk.

Approach and solution

The proposed architecture uses a managed container platform for the core web and checkout services, with a managed relational database for transactional data and a cache for carefully selected catalogue data. An API gateway provides authentication integration, routing, throttling, and request observability. The application is initially a modular monolith with clear domain boundaries rather than an immediate collection of many microservices.

Order events are published after a successful transaction through a transactional-outbox mechanism. A serverless consumer sends notifications and updates a search index. The reporting workload reads from a separate analytical store or scheduled export rather than executing uncontrolled queries against the checkout database. A small VM remains for a vendor package that requires a specialised operating system.

Deployments use automated tests, image scanning, gradual rollout, readiness checks, and rollback. Payment operations carry idempotency keys so that client retries do not create duplicate charges. Secrets are stored in a managed secrets service, and service identities have narrowly scoped permissions.

Outcome

The architecture scales web capacity independently, isolates reporting from checkout, and reduces the team’s platform-management burden. It does not eliminate complexity: the outbox, event delivery, data synchronisation, and external payment failure modes require monitoring and reconciliation. The design deliberately uses several compute models because the workload contains different operational and performance requirements.

Learning points

1. Architectural boundaries should follow business and operational needs, not technology trends.
2. A modular monolith may be a better starting point than premature microservices.
3. Asynchronous processing improves isolation but requires idempotency and failure handling.
4. Managed platforms can be strategically preferable when internal platform skills are limited.
5. Hybrid compute is often rational when workloads have different constraints.

10. Governance, Ethics, and Contemporary Developments

Cloud architectures create governance responsibilities. Data residency and retention rules may constrain region selection and logging. Payment and health data may require specific controls and audit evidence. Software bills of materials, signed artifacts, provenance records, and vulnerability response are increasingly important for supply-chain assurance.

Architects should consider energy consumption and unnecessary overprovisioning. Autoscaling reduces idle capacity but may increase churn and downstream load. Efficient images, right-sized resources, workload scheduling, and carbon-aware regional choices can contribute to responsible computing, subject to availability and regulatory constraints.

AI-assisted coding and operations can accelerate image creation, configuration generation, anomaly detection, and incident analysis. However, generated infrastructure definitions may contain insecure permissions, unsupported settings, or hidden dependencies. Human review, testing, provenance, and approval controls remain necessary. AI services also introduce data-governance questions concerning prompts, training use, confidentiality, and model availability.

Emerging architectural directions include eBPF-based networking and security, workload identity, confidential computing, WebAssembly components, platform engineering, and increasingly sophisticated managed container services. These developments may reduce or relocate operational burdens; they do not remove the need for clear contracts, failure analysis, and governance.

Best-Practice Checklist

• Select compute according to workload, not organisational fashion.
• Prefer managed control planes when operating the platform is not a strategic capability.
• Keep containers immutable, minimal, signed, scanned, and non-root where feasible.
• Treat Kubernetes as a platform requiring expertise, upgrades, policy, and observability.
• Design APIs with explicit contracts, versioning, timeouts, authentication, and idempotency.
• Use asynchronous messaging for suitable decoupling, with retries and dead-letter handling.
• Make state ownership and consistency decisions explicit.
• Test autoscaling, zone failure, dependency failure, rollback, and recovery.
• Apply least privilege and protect the software supply chain.
• Measure user and business outcomes, not only infrastructure metrics.

Chapter Summary

Cloud compute and application architecture is the disciplined selection and composition of execution models and communication patterns. Virtual machines provide control and compatibility; containers provide efficient packaging; Kubernetes supplies declarative orchestration; serverless functions suit event-driven and variable workloads; microservices organise independently deployable capabilities; APIs define interaction contracts; and service meshes provide platform-level communication policy and telemetry.

Each choice has trade-offs in portability, performance, scalability, security, cost, and operational complexity. Effective design begins with workload characterisation and quality attributes, then evaluates total operational burden and validates assumptions through testing. Reliability requires timeouts, bounded retries, redundancy, idempotency, observability, and recovery practice. Security requires identity, least privilege, supply-chain controls, and careful data governance. The strongest architecture is often hybrid and evolutionary: it uses different models where they provide genuine value and avoids complexity that the organisation cannot responsibly operate.

Key Terms

Virtual machine: A software-defined computer with virtualised CPU, memory, storage, and networking.

Hypervisor: Software that creates and manages virtual machines.

Container: An isolated process packaged with its user-space dependencies while sharing a host kernel.

Container image: An immutable package containing application files, dependencies, metadata, and startup instructions.

Orchestration: Automated scheduling, deployment, scaling, networking, and recovery of workloads.

Kubernetes: A declarative platform for orchestrating containerised workloads.

Pod: Kubernetes’ smallest deployable unit, containing one or more closely coupled containers.

Serverless function: Provider-managed code executed in response to an event or request.

Cold start: Latency caused by preparing a new function execution environment.

Microservice: An independently deployable service aligned with a focused business capability.

API: A defined contract through which software components interact.

Idempotency: A property whereby repeating an operation produces the same intended result as performing it once.

Service mesh: A communication layer that supplies traffic, security, and observability functions for services.

Control plane: Components that manage desired state, scheduling, provisioning, and policy.

Data plane: Components that execute workloads and carry application traffic.

Readiness probe: A health test determining whether a workload should receive traffic.

Canary deployment: A release strategy that exposes a new version to a limited traffic segment first.

Observability: The ability to understand system behaviour through logs, metrics, traces, and related signals.

Immutable infrastructure: An approach in which changed infrastructure is replaced rather than manually modified in place.

Review Questions

Short Answer Questions

1. What is the principal difference between a virtual machine and a container isolation boundary?
2. Define the roles of the Kubernetes control plane and data plane.
3. Why should a serverless function handler usually be idempotent?
4. What purpose does an API gateway commonly serve?
5. State two risks associated with indiscriminate retries in a service mesh.

Long Answer Questions

1. Compare VMs, containers managed by Kubernetes, and serverless functions in terms of portability, performance, scalability, and operational responsibility.
2. Explain how Kubernetes deployments, resource requests, limits, and health probes contribute to reliable application operation.
3. Discuss the benefits and costs of decomposing a modular monolith into microservices.
4. Explain how APIs, asynchronous messaging, and service meshes contribute to a distributed application architecture.
5. Describe a security and observability strategy for a containerised cloud application.

Analytical / Application Questions

1. A business has a legacy application requiring a specialised kernel module, a bursty image-processing workload, and a continuously running customer API. Select an appropriate compute model for each workload and justify the choices.
2. A Kubernetes application scales from 10 to 50 replicas, but database latency and error rates increase sharply. Analyse possible causes and propose a safer scaling and resilience strategy.
3. Design a high-level architecture for an online payment workflow that remains safe when clients retry requests, messages are delivered more than once, and the payment provider becomes temporarily unavailable.

Multiple Choice Questions with Answers

Question 1

Which characteristic most strongly favours a virtual machine over a container?

A. The workload requires a specialised operating system or kernel module.

B. The workload consists of short event-driven tasks.

C. The workload needs rapid image-based deployment.

D. The workload is stateless and horizontally scalable.

Correct Answer: A. The workload requires a specialised operating system or kernel module.

Question 2

In Kubernetes, what is the primary purpose of a readiness probe?

A. To determine whether a pod should receive traffic

B. To select the cheapest node for a pod

C. To encrypt all container filesystems

D. To create a new container image

Correct Answer: A. To determine whether a pod should receive traffic

Question 3

Why are idempotency controls important in event-driven systems?

A. Events may be delivered more than once.

B. They guarantee zero network latency.

C. They eliminate the need for access control.

D. They prevent all forms of data inconsistency.

Correct Answer: A. Events may be delivered more than once.

Question 4

Which deployment strategy initially exposes a new version to only a small proportion of traffic?

A. Rolling deployment

B. Canary deployment

C. Lift-and-shift deployment

D. Immutable-image deployment

Correct Answer: B. Canary deployment

Question 5

What is a principal operational disadvantage of Kubernetes?

A. It cannot run containerised applications.

B. It requires platform expertise, upgrades, policies, and observability.

C. It prevents horizontal scaling.

D. It does not support declarative configuration.

Correct Answer: B. It requires platform expertise, upgrades, policies, and observability.

Question 6

A service has a 99.9% availability target over a 30-day month. Approximately how much unavailability does this represent?

A. 4.32 minutes

B. 43.2 minutes

C. 432 minutes

D. 1,440 minutes

Correct Answer: B. 43.2 minutes

Question 7

Which statement best describes a service mesh?

A. A database replication mechanism

B. A communication layer that can provide traffic policy, mutual TLS, and telemetry

C. A replacement for all application business logic

D. A virtual machine image format

Correct Answer: B. A communication layer that can provide traffic policy, mutual TLS, and telemetry

Question 8

What is a major benefit of asynchronous queues in cloud applications?

A. They eliminate the need for consumers.

B. They can decouple producers and consumers and absorb bursts.

C. They guarantee messages are never duplicated.

D. They make every operation strongly consistent.

Correct Answer: B. They can decouple producers and consumers and absorb bursts.

Question 9

Which practice improves container supply-chain security?

A. Embedding production secrets in the image

B. Running every process as root

C. Signing and scanning images before deployment

D. Modifying running containers manually

Correct Answer: C. Signing and scanning images before deployment

Question 10

Why might a small engineering team choose a managed container platform instead of self-managed Kubernetes?

A. Managed platforms always provide unlimited compute.

B. The team may lack the capacity to operate Kubernetes control planes and upgrades.

C. Kubernetes cannot support production applications.

D. Managed platforms remove the need for application monitoring.

Correct Answer: B. The team may lack the capacity to operate Kubernetes control planes and upgrades.