10. Cloud-Native Infrastructure and Platform Engineering

Introduction and Context

Modern APIs and microservices are not operated effectively by deploying application binaries onto manually configured servers. Their value depends on an infrastructure environment that can provision resources consistently, release software safely, observe runtime behaviour, and recover from failure. Cloud-native infrastructure addresses this requirement through containers, orchestration platforms, declarative configuration, automated delivery, and elastic computing services.

Cloud-native does not simply mean “running in the cloud.” It describes an approach to building and operating systems that treats infrastructure as programmable, services as independently deployable units, and operational processes as automated and observable. Kubernetes, infrastructure as code, ingress controllers, service meshes, serverless platforms, and internal developer platforms are important components of this approach, but none is automatically appropriate for every organization.

For a full-stack developer, the subject matters because API design decisions increasingly interact with deployment topology. A service’s network policy, health checks, scaling behaviour, configuration model, data locality, and failure modes must be understood alongside its source code. For architects and engineering leaders, the central question is not whether a particular tool is fashionable, but whether the selected platform reduces cognitive load, improves reliability, and produces acceptable cost and portability outcomes.

Learning Objectives

After studying this chapter, the learner should be able to:

1. Explain the principles and operating model of cloud-native infrastructure.

2. Package and run services using containers and Kubernetes.

3. Distinguish the roles of ingress, service discovery, load balancing, and service meshes.

4. Apply infrastructure-as-code practices to repeatable environment management.

5. Explain the purpose and trade-offs of internal developer platforms.

6. Evaluate serverless, multi-cloud, and edge architectures using technical, economic, and organizational criteria.

7. Identify operational, security, governance, and reliability risks in cloud-native systems.

8. Recommend a suitable platform strategy for a realistic API-based organization.

From Application Deployment to Platform Engineering

Traditional deployment often places the principal burden on an operations team. Developers provide an artifact, while specialists create servers, install dependencies, configure networks, and arrange monitoring. This model can work at modest scale, but manual variation makes environments difficult to reproduce and creates delays between code completion and production operation.

Cloud-native practice separates application intent from infrastructure implementation. A team describes the desired state—for example, three replicas of an API, a private database connection, a health endpoint, and a rule allowing public HTTPS traffic—and automation works to make the environment conform to that description. The infrastructure becomes versioned, reviewable, testable, and recoverable.

Platform engineering develops this idea organizationally. A platform team provides reusable “golden paths” through which product teams can create services, obtain environments, configure observability, and release software without learning every underlying infrastructure detail. The platform is not merely a collection of tools. It is a product for internal users, with documented interfaces, service-level expectations, feedback mechanisms, and a deliberate balance between standardization and team autonomy.

A useful distinction is between the platform and the workload. The platform supplies scheduling, networking, identity, secrets integration, logging, metrics, deployment workflows, and policy enforcement. The workload is the business service running on that platform. A mature design keeps these concerns sufficiently separate while ensuring that the platform exposes capabilities in a way developers can use correctly.

Containers as the Packaging Boundary

A container packages an application together with its runtime dependencies in an isolated process environment. It shares the host operating system kernel, unlike a virtual machine, which normally includes a complete guest operating system. Containers therefore tend to start quickly and use resources efficiently, although they do not eliminate the need for operating-system security and runtime isolation.

A container image is an immutable artifact composed of filesystem layers and metadata. A Dockerfile or equivalent build description specifies how the image is created. Good images use a minimal trusted base, install only required dependencies, run as a non-root user, exclude credentials, and separate build-time tools from runtime components through multi-stage builds. Images should be scanned for vulnerabilities and identified by immutable digests rather than relying only on mutable tags such as `latest`.

Containerization does not make an application cloud-native by itself. A stateful service that stores data only inside a writable container filesystem remains fragile because the container may be replaced. Persistent state should normally be placed in a managed database, durable volume, or another explicitly designed storage system. Similarly, an application should externalize configuration, expose health information, handle termination signals, and write logs to standard output or a supported logging interface.

The operational contract of a containerized API commonly includes:

• a predictable startup command;
• environment-based or secret-based configuration;
• a readiness indication showing whether it can receive traffic;
• a liveness indication showing whether it is functioning sufficiently to remain running;
• graceful shutdown within an allowed termination period;
• resource requests and limits; and
• structured logs and telemetry.

Readiness and liveness must not be confused. A service may be alive but temporarily unable to serve requests because it is waiting for a dependency. Restarting it repeatedly in that condition can make an incident worse. A readiness check should control traffic, whereas a liveness check should identify a process that requires replacement.

Kubernetes as a Declarative Control System

Kubernetes is a control plane for deploying and managing containerized workloads across a cluster. It does not simply execute a list of commands. Users submit desired-state objects, and controllers continuously compare the desired state with the observed state. If a replica fails, a controller attempts to create another; if a node becomes unavailable, the scheduler may place workloads elsewhere, subject to constraints.

A Kubernetes cluster generally contains a control plane and worker nodes. The control plane stores cluster state and exposes an API. Components such as the scheduler select nodes for new workloads, while controllers reconcile resources. Worker nodes run container workloads through a container runtime and provide networking and storage integration.

Important Kubernetes abstractions include:

Pod: The smallest deployable unit, usually containing one application container and occasionally tightly coupled sidecars.

Deployment: A controller for managing replicated, usually stateless, pods and their rolling updates.

Service: A stable virtual endpoint that selects a group of pods and supports service discovery and load distribution.

ConfigMap and Secret: Objects for supplying non-sensitive configuration and sensitive values, although secrets still require encryption, access control, and careful lifecycle management.

Namespace: A logical boundary for organizing resources and applying policies, quotas, and access controls.

StatefulSet: A controller for workloads requiring stable identities or storage relationships, though managed databases are often operationally simpler.

Job and CronJob: Resources for finite or scheduled work rather than continuously running APIs.

Kubernetes deployment strategies include rolling replacement, blue-green deployment, and canary release. A rolling update replaces instances gradually and is economical, but it requires backward-compatible API and data changes. Blue-green deployment runs two environments and switches traffic between them, increasing resource use but simplifying rollback. Canary release directs a small percentage of traffic to the new version and uses telemetry to determine whether exposure should increase.

Resource management is essential. A resource request influences scheduling, while a limit restricts maximum consumption. Incorrectly low requests can produce contention and unreliable scheduling; excessively high requests waste capacity. Autoscaling may operate at several levels: horizontal pod autoscaling changes replica count according to metrics, vertical approaches adjust resource sizing, and cluster autoscaling changes the number of worker nodes. Scaling policy must account for startup time, queue depth, dependency capacity, and cost rather than CPU alone.

Kubernetes also introduces complexity. Its flexibility creates a large operational surface involving upgrades, networking, storage, security, policy, observability, and incident response. Managed Kubernetes reduces some control-plane responsibilities but does not remove workload responsibility. Organizations should adopt it because they need its capabilities, not because every service requires a cluster.

Traffic Entry, Service Discovery, and the Service Mesh

An internal Kubernetes Service gives a stable name and virtual address to a changing set of pods. This allows clients to call a logical service rather than track individual instances. Service discovery can be implemented through cluster DNS, while load balancing distributes requests among eligible endpoints.

Ingress concerns traffic entering the cluster. An ingress resource describes routing rules, such as directing `api.example.com/orders` to an orders service and `api.example.com/users` to a users service. An ingress controller implements those rules using a reverse proxy or load balancer. Modern Kubernetes environments may also use the Gateway API, which provides more expressive and role-oriented traffic configuration.

Ingress is an important security boundary. TLS termination, request-size limits, authentication integration, rate limiting, web application firewall functions, and access logging may occur at this layer. These functions should be designed explicitly; assuming that a default controller provides adequate protection is unsafe.

A service mesh adds a dedicated communication layer, often through a proxy associated with each workload. It can provide mutual TLS, service identity, retries, timeouts, traffic splitting, circuit breaking, and uniform telemetry. This may reduce the amount of networking code in applications and make cross-service policies more consistent.

However, a mesh is not a universal solution. Proxies consume resources, introduce additional failure modes, and require specialized expertise. Automatic retries can amplify load, especially for non-idempotent operations. A timeout that is longer than the user’s request deadline can waste capacity, while a timeout that is too short can create false failures. Mesh adoption should follow a demonstrated need for consistent service-to-service controls, not precede basic observability and sound API contracts.

Infrastructure as Code and Policy Automation

Infrastructure as code (IaC) represents infrastructure configuration in machine-readable files managed through version control. Declarative tools such as Terraform, Pulumi, CloudFormation, or similar systems allow teams to define networks, clusters, databases, identity roles, and monitoring resources. Configuration can be reviewed through pull requests and applied through controlled pipelines.

A useful IaC workflow consists of planning, review, validation, application, and verification. The plan shows the proposed changes; automated checks identify syntax, policy, security, and cost problems; an authorized process applies the change; and post-deployment checks confirm that the environment behaves as intended. State management must be protected because it may contain resource identifiers or sensitive information and because concurrent modification can produce inconsistent results.

Modules provide reusable patterns, but excessive abstraction makes ownership and troubleshooting difficult. A module should expose meaningful organizational decisions—such as service name, region, scaling range, and data classification—while hiding repetitive implementation detail. Environments should not drift through unrecorded console changes. Emergency changes may be necessary, but they should be reconciled back into code.

Policy as code complements IaC. Rules can prohibit public storage, require encryption, enforce approved image registries, restrict privileged containers, or require cost labels. Policy is most effective when it provides a clear explanation and an approved exception process rather than simply blocking every unusual configuration.

Internal Developer Platforms and the Golden Path

An internal developer platform combines infrastructure capabilities, automation, documentation, templates, and governance into a self-service experience. A developer might select a service template, specify ownership and data classification, and receive a repository, continuous integration pipeline, deployment configuration, observability dashboard, and environment registration. The platform hides unnecessary complexity but does not hide accountability.

A golden path is a recommended route for common work. It should be opinionated enough to prevent recurring mistakes and flexible enough to support legitimate variation. Typical platform capabilities include:

• service templates and repository bootstrapping;
• automated builds, tests, security scanning, and image publication;
• deployment promotion across environments;
• secret and identity integration;
• standard logging, metrics, tracing, and alerting;
• documentation and service catalogue metadata; and
• cost, reliability, and ownership information.

Platform success should be measured by outcomes rather than the number of tools installed. Useful indicators include deployment lead time, change failure rate, recovery time, platform adoption, developer satisfaction, support demand, security-policy compliance, and infrastructure cost per workload. The platform team must treat developers as customers and use feedback to improve the product.

A central risk is creating a platform that becomes a compulsory ticket queue. Self-service requires clear interfaces, automation, reliable documentation, and sensible escalation paths. Another risk is over-standardization: forcing every workload into one runtime can prevent appropriate use of batch processing, managed databases, serverless functions, or specialized compute.

Choosing Among Kubernetes, Serverless, Multi-Cloud, and Edge

Architecture selection should begin with workload characteristics and organizational capability. Kubernetes offers control, portability across many environments, and a broad ecosystem. It also requires substantial expertise and operational investment. Serverless platforms abstract servers and often charge according to invocation or resource use. They can accelerate event-driven applications and variable workloads, but may introduce provider-specific interfaces, execution limits, startup latency, and difficult local testing.

Portability has several dimensions. Application portability concerns whether code can run elsewhere. Data portability concerns migration of databases and stored data. Operational portability concerns whether teams can reproduce deployment, observability, identity, and governance in another environment. A container image alone provides only limited portability if the application depends on proprietary databases, identity systems, queues, or platform APIs.

Multi-cloud can be justified by regulatory requirements, acquisition history, customer location, resilience strategy, or access to specialized capabilities. It can also duplicate skills, tooling, contracts, security models, and operational effort. A claim that an organization is “multi-cloud” is meaningful only when the relevant services can actually be operated across providers and the cost of doing so is acceptable.

Edge computing places processing closer to users, devices, or data sources. It can reduce latency, support intermittent connectivity, and limit data movement. Edge environments are often more constrained and physically less controlled than centralized cloud regions. Synchronization, update distribution, observability, and security require careful design. An edge architecture should define what happens when the edge is disconnected and how conflicting state is reconciled.

A practical decision framework evaluates at least the following dimensions:

1. Workload fit: request pattern, state, latency, compute, storage, and event characteristics.

2. Reliability needs: recovery objectives, fault domains, dependency behaviour, and operational maturity.

3. Portability value: likelihood of migration and the actual portability of data and platform services.

4. Economic profile: steady versus burst traffic, licensing, egress, staffing, and opportunity cost.

5. Security and regulation: data residency, identity, isolation, auditability, and sector obligations.

6. Organizational capability: skills, on-call capacity, platform ownership, and supplier management.

The best architecture is therefore contextual. A managed serverless API may be preferable for a small team with irregular traffic, while Kubernetes may be justified for a large organization operating many long-lived services with sophisticated scheduling and networking requirements.

Applied Case: Northstar Retail Platform

Background

Northstar Retail is an illustrative mid-sized retailer whose monolithic online store has been divided into catalog, pricing, basket, order, and notification APIs. Traffic increases sharply during promotional events. The engineering group has 45 developers, a small operations team, and limited Kubernetes experience. The company operates in two geographic markets and must retain transaction records according to local regulatory requirements.

Situation and Problem

Deployments are currently performed manually to virtual machines. A release may work in staging but fail in production because of configuration differences. During promotional events, operators provision capacity in advance, yet the notification service remains idle most of the time. The organization is considering a self-managed Kubernetes cluster, a fully serverless approach, or deployment to two cloud providers for resilience.

Analysis

The principal problems are not merely lack of compute. They include configuration drift, weak release repeatability, limited observability, and an absence of clear service ownership. A two-provider strategy would increase resilience only if Northstar could maintain replicated data, identity, monitoring, deployment, and incident response in both environments. Its current operations team is not prepared for that burden.

The workload is mixed. Catalog and pricing APIs have predictable baseline traffic and benefit from caching. Notifications are event-driven and bursty. Orders require strong data integrity and careful transactional design. The business needs geographic placement of some data but does not require every service to run in every location.

Approach and Strategy

Northstar adopts a managed container platform rather than operating Kubernetes control planes itself. It creates a small internal platform with a standard service template containing:

• a multi-stage container build;
• non-root execution and image scanning;
• readiness and liveness endpoints;
• standardized resource requests;
• automated deployment through a versioned pipeline;
• centralized logs, metrics, and traces; and
• ownership, data classification, and rollback metadata.

Ingress provides public HTTPS routing, while internal services use stable service discovery. A service mesh is postponed because the initial problems can be addressed with explicit timeouts, retries limited to safe operations, and application-level telemetry. Notifications move to a serverless event consumer because their traffic is irregular. Orders remain on a managed relational database with carefully designed backups and recovery procedures. Data is deployed according to regulatory requirements rather than duplicated indiscriminately.

Infrastructure is defined in code, with separate state and access controls for each environment. Policy checks prevent public database exposure and require encryption. The platform team measures deployment frequency, failed changes, recovery time, and platform adoption.

Outcome

The organization gains repeatable environments and safer deployment without assuming the full operational burden of a self-managed cluster. Burst capacity is handled more efficiently for notifications, while transactional workloads retain a platform suited to their consistency requirements. Northstar does not claim complete multi-cloud portability; instead, it documents which components are portable and which depend on provider-managed services.

Learning Points

The case demonstrates that platform engineering begins with operational problems and user needs, not product selection. Managed services can be strategically appropriate even when portability is valued. A staged approach—standard containers, IaC, observability, and reliable delivery before advanced mesh or multi-cloud adoption—reduces risk and creates evidence for later decisions.

Reliability, Security, and Governance Concerns

Cloud-native systems distribute failure across networks, nodes, regions, dependencies, and control planes. Reliability requires explicit service-level objectives, useful alerts, capacity assumptions, dependency timeouts, graceful degradation, backups, and tested recovery procedures. A retry without a deadline is a resource leak; a circuit breaker without a fallback may merely change the visible error. Chaos exercises and game days can test assumptions, but they should be controlled and tied to meaningful hypotheses.

Security begins with identity and least privilege. Workloads should receive only the permissions they require, and short-lived credentials are preferable to embedded keys. Images, dependencies, build pipelines, registries, cluster APIs, and admission controls all belong in the software supply-chain threat model. Secrets should not be stored in source repositories or exposed through logs. Network policies can reduce unnecessary communication, but they must be maintained as service relationships change.

Governance includes data classification, retention, residency, audit trails, change approval, cost accountability, and third-party risk. Automated controls should be combined with human judgment for exceptions and high-impact systems. Teams should know who owns each service, who receives alerts, what recovery objective applies, and which decisions are delegated to the platform.

Common mistakes include adopting Kubernetes for a small workload with no operational justification, treating containers as security boundaries, using mutable image tags, placing state in ephemeral storage, configuring unlimited retries, exposing administrative endpoints through ingress, ignoring egress costs, and assuming that a cloud provider’s availability guarantees eliminate application responsibility.

Current Developments

Platform engineering is increasingly associated with software catalogues, self-service infrastructure APIs, policy automation, and developer portals. Kubernetes remains influential, but the broader trend is toward selecting the simplest platform that can provide reliable delivery and governance. WebAssembly-based runtimes, managed container services, event-driven architectures, confidential computing, and more capable edge platforms are expanding the set of deployment options.

Artificial intelligence is also entering platform operations. Machine-learning techniques can assist with anomaly detection, capacity forecasting, incident correlation, and automated remediation. These systems should remain subject to access controls, human review for consequential actions, transparent evidence, and safeguards against feedback loops. Automation that restarts or scales services without understanding business impact can conceal symptoms or amplify an incident.

Best-Practice Principles

A sound cloud-native operating model generally follows these principles:

1. Treat infrastructure and platform configuration as versioned, reviewable code.

2. Build small, secure, immutable images and identify them by digest.

3. Make service health, ownership, dependencies, and recovery expectations explicit.

4. Prefer managed capabilities when they reduce undifferentiated operational work.

5. Use Kubernetes, meshes, multi-cloud, or edge deployment only for demonstrated requirements.

6. Automate security, policy, testing, deployment, and rollback where practical.

7. Design for failure, but validate resilience through realistic testing.

8. Measure developer experience and operational outcomes, not tool adoption alone.

9. Preserve portability deliberately by documenting provider dependencies and migration costs.

10. Give teams autonomy within clear security, reliability, cost, and governance boundaries.

Chapter Summary

Cloud-native infrastructure makes services deployable, observable, scalable, and recoverable through automation and declarative control. Containers provide a consistent packaging boundary, while Kubernetes manages desired state, scheduling, service discovery, updates, and scaling. Ingress governs external traffic, and service meshes can standardize internal communication policies when their complexity is justified. Infrastructure as code and policy as code make environments repeatable and governable. Internal developer platforms package these capabilities into self-service golden paths for product teams.

Serverless, multi-cloud, and edge approaches offer valuable alternatives but involve trade-offs in portability, cost, latency, complexity, data management, and organizational capability. Effective platform engineering is therefore a decision discipline rather than a tool-accumulation exercise. The most appropriate architecture aligns workload needs, reliability and security requirements, economic realities, and the organization’s ability to operate the resulting system.

Key Terms

Container: An isolated process environment packaging an application and its runtime dependencies.

Container image: An immutable layered artifact from which containers are created.

Kubernetes: A platform that orchestrates containerized workloads through declarative desired-state management.

Pod: Kubernetes’ smallest deployable unit, usually containing one application container.

Deployment: A Kubernetes controller that manages replicated pods and application updates.

Service: A stable Kubernetes endpoint for discovering and routing traffic to pods.

Ingress: A set of rules and mechanisms for directing external traffic into services.

Service mesh: A communication layer that provides service-to-service security, traffic control, and telemetry.

Infrastructure as code: The practice of defining and managing infrastructure through versioned machine-readable configuration.

Policy as code: Automated representation and enforcement of organizational or security rules.

Platform engineering: The design and operation of internal platforms that provide reusable self-service capabilities to development teams.

Golden path: A supported, opinionated route for performing a common development or deployment task.

Serverless: A computing model in which infrastructure management is abstracted and execution is commonly metered by use.

Multi-cloud: The use of services or deployments across more than one cloud provider.

Edge computing: Processing performed near users, devices, or data sources rather than exclusively in centralized regions.

Readiness probe: A health mechanism indicating whether a workload should receive traffic.

Liveness probe: A health mechanism indicating whether a workload should be restarted or replaced.

Infrastructure drift: Divergence between the declared configuration and the actual deployed environment.

Service-level objective: A target level of reliability or performance for a service.

Review Questions

Short Answer Questions

1. Why is a container image alone insufficient to guarantee application portability?

2. Distinguish between a Kubernetes readiness probe and a liveness probe.

3. What problem does infrastructure as code address?

4. State two capabilities commonly provided by a service mesh.

5. Define a golden path in an internal developer platform.

Long Answer Questions

1. Explain Kubernetes’ declarative control model and discuss how Deployments, Services, and autoscaling contribute to API operations.

2. Describe a complete infrastructure-as-code workflow, including planning, review, application, state management, and verification.

3. Discuss the organizational and technical responsibilities of an internal developer platform team.

4. Compare Kubernetes and serverless computing in relation to control, cost, portability, scaling, and operational skill requirements.

5. Explain the major security and reliability risks of cloud-native systems and propose appropriate controls.

Analytical / Application Questions

1. A small company has one API with highly variable traffic and no dedicated operations team. Evaluate whether Kubernetes or serverless deployment is more suitable, stating the assumptions behind your recommendation.

2. An organization wants two cloud providers solely to avoid vendor lock-in. Use the portability and organizational-capability framework to assess whether this is a sound strategy.

3. Design a platform approach for a retail API consisting of a transactional order service, a bursty notification service, and a low-latency catalog service. Justify choices concerning containers, serverless, data, ingress, observability, and governance.

22. Multiple Choice Questions with Answers

Question 1

Which statement best describes the principal role of Kubernetes?

A. It replaces all application databases with distributed storage.

B. It continuously reconciles declared workload state with observed cluster state.

C. It converts every application into a serverless function.

D. It provides only external HTTP load balancing.

Correct Answer: B. It continuously reconciles declared workload state with observed cluster state.

Question 2

A pod is running but cannot currently connect to a required dependency. Which mechanism should normally prevent it from receiving traffic without necessarily restarting it?

A. Readiness probe

B. Liveness probe

C. Container image tag

D. Cluster autoscaler

Correct Answer: A. Readiness probe

Question 3

Which practice most directly reduces the risk of deploying a compromised or unnecessarily large container?

A. Using the mutable latest tag

B. Running the container as root

C. Using minimal trusted images and vulnerability scanning

D. Storing credentials in the image

Correct Answer: C. Using minimal trusted images and vulnerability scanning

Question 4

What is a primary function of an ingress controller?

A. Scheduling pods onto worker nodes

B. Routing external traffic to internal services

C. Creating database backups

D. Compiling source code into images

Correct Answer: B. Routing external traffic to internal services

Question 5

Why might an organization postpone adopting a service mesh?

A. A service mesh cannot provide telemetry.

B. A service mesh prevents all internal communication.

C. Its operational and resource complexity may not yet be justified.

D. A service mesh works only with virtual machines.

Correct Answer: C. Its operational and resource complexity may not yet be justified.

Question 6

Which statement best characterizes infrastructure as code?

A. Infrastructure is configured manually and documented afterward.

B. Infrastructure definitions are versioned, reviewed, and applied through automation.

C. Only application source code is stored in a repository.

D. Infrastructure changes cannot be tested before deployment.

Correct Answer: B. Infrastructure definitions are versioned, reviewed, and applied through automation.

Question 7

Which scenario is most likely to favour serverless execution?

A. A continuously running workload requiring detailed node-level control

B. A bursty event consumer with irregular demand

C. A database requiring stable local disks and custom kernel modules

D. A workload that must run identically in an isolated private data centre

Correct Answer: B. A bursty event consumer with irregular demand

Question 8

Why does using two cloud providers not automatically create meaningful portability?

A. Containers cannot run in more than one cloud.

B. Portability also involves data, identity, operations, and provider-specific services.

C. Cloud providers prohibit monitoring in multi-cloud systems.

D. Multi-cloud systems cannot use infrastructure as code.

Correct Answer: B. Portability also involves data, identity, operations, and provider-specific services.

Question 9

Which characteristic is most important for a responsible internal developer platform?

A. It maximizes the number of tools developers must learn.

B. It provides self-service capabilities through documented, supported workflows.

C. It removes all accountability from product teams.

D. It requires every workload to use identical infrastructure.

Correct Answer: B. It provides self-service capabilities through documented, supported workflows.

Question 10

Northstar Retail has limited operations expertise and needs repeatable deployments. Which approach best fits the case described in the chapter?

A. Self-managed Kubernetes across two providers immediately

B. Manual virtual-machine deployment with more runbooks

C. A managed container platform with IaC, standard templates, and selective serverless use

D. A service mesh as the first remediation for configuration drift

Correct Answer: C. A managed container platform with IaC, standard templates, and selective serverless use