Cloud-Native Applications, Microservices and Serverless

Introduction and Context

Cloud computing has evolved from the remote provision of virtual machines into an application-delivery model in which software is designed for elasticity, automation, distributed operation and continuous change. Cloud-native engineering refers not merely to hosting an application in a public cloud. It involves designing applications to exploit cloud characteristics such as on-demand resources, programmable infrastructure, managed services, horizontal scaling, automation and geographically distributed operation.

This chapter examines the principal architectural styles and engineering practices associated with cloud-native systems: twelve-factor applications, microservices, event-driven architecture, containers, Kubernetes and serverless computing. These technologies are related but not interchangeable. A container is a packaging and isolation mechanism; Kubernetes is an orchestration platform; microservices are an approach to decomposing software; serverless is a resource and operational model; and event-driven architecture is a way of coordinating components through events. A well-designed system selects among these approaches according to business boundaries, workload characteristics, reliability requirements and organizational capability.

Cloud-native architecture also introduces costs. Distributed systems create network failure, latency, partial availability, data-consistency problems, observability requirements and operational complexity. Consequently, decomposition should not be treated as an automatic improvement over a modular monolith. The central design question is not whether an organization should use microservices or serverless, but which architectural boundaries and operating models produce acceptable business value and risk.

Learning Objectives

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

1. Explain the principles of twelve-factor application design.

2. Evaluate when a monolith, modular monolith or microservices architecture is appropriate.

3. Design service boundaries, APIs, data ownership and communication patterns.

4. Describe containers, Kubernetes objects and the Kubernetes control model.

5. Design event-driven and serverless workflows with suitable reliability controls.

6. Assess state management, scalability, observability, security and operational complexity.

7. Apply architectural reasoning to a realistic cloud-native case.

8. Critically evaluate the limitations, governance issues and emerging directions of cloud-native computing.

1. The Cloud-Native Design Model

A cloud-native application is usually characterized by the following properties:

• It is composed of independently deployable components or well-structured modules.
• It treats infrastructure as programmable and replaceable.
• It uses automated build, test, deployment and recovery processes.
• It is designed for horizontal scaling rather than depending exclusively on larger servers.
• It externalizes configuration and separates it from application code.
• It exposes operational signals such as logs, metrics and traces.
• It assumes that failures, restarts and network delays can occur.
• It uses managed platform capabilities where doing so reduces undifferentiated operational work.

These properties are design tendencies, not rigid compliance rules. For example, a stateful database may be essential even though stateless application instances are easier to scale. Similarly, a critical service may require a carefully controlled release rather than unrestricted deployment frequency.

A useful architectural distinction is between functional decomposition and deployment decomposition. Functional decomposition divides a system according to business responsibilities. Deployment decomposition divides it into independently operated units. A system can be functionally modular while remaining one deployable application. This is the modular monolith. Microservices require an additional decision: which modules deserve independent deployment, scaling and ownership.

2. Twelve-Factor Applications

The twelve-factor methodology provides a set of practices for building services that are portable, automatable and suitable for cloud platforms. It is not a formal standard, and some modern systems extend or reinterpret its principles, but it remains a useful diagnostic framework.

2.1 Codebase

A service should have one version-controlled codebase, with many deployments derived from that codebase. Different environments should not be maintained as unrelated source trees. Branches, configuration and deployment policies may differ, but the application artifact should be reproducible from version-controlled inputs.

2.2 Dependencies

Dependencies should be declared explicitly and isolated from the host environment. Package manifests, lock files and reproducible builds reduce the risk that a deployment depends on an unrecorded library or system package.

2.3 Configuration

Environment-specific configuration, including database endpoints, feature flags and credentials, should be separated from code. Configuration must not be embedded in source files or container images. Secrets require stronger controls than ordinary configuration: encryption at rest, restricted access, rotation and auditability.

2.4 Backing Services

Databases, message brokers, object stores, caches and external APIs should be treated as attached resources. An application should interact with them through stable interfaces so that a service can change from one compatible resource to another without extensive code modification. This principle does not imply that every database can be replaced without migration planning.

2.5 Build, Release and Run

Build, release and run should be separate stages. The build produces an immutable artifact; the release combines that artifact with configuration; and the run stage executes it. This separation supports traceability, rollback and promotion of the same artifact across environments.

2.6 Processes

Application processes should be stateless where practical. Persistent state belongs in durable backing services rather than in local process memory or ephemeral disk. Statelessness allows instances to be replaced and scaled independently. It does not mean that the overall system has no state; it means that state is managed explicitly.

2.7 Port Binding

Services should expose themselves through a port rather than relying on injection into a particular web server. This improves portability across containers, virtual machines and platform services.

2.8 Concurrency

Scaling should be modeled as adding process instances or workers appropriate to the workload. Web traffic, background jobs and scheduled tasks may use distinct process types. This is a conceptual guide; modern orchestrators may scale deployments, jobs or functions according to more sophisticated policies.

2.9 Disposability

Processes should start quickly and shut down gracefully. Graceful termination includes completing or safely abandoning work, acknowledging shutdown signals and preventing corruption. Fast startup is particularly important for autoscaling and serverless execution.

2.10 Development and Production Parity

Development, testing and production should be similar in tools, dependencies and operational assumptions. Complete identity is rarely economical, but substantial differences increase deployment risk.

2.11 Logs

Logs should be treated as event streams rather than files that require manual management inside an instance. A platform can collect, index, retain and analyze them centrally. Logs need structured fields such as timestamp, severity, request identifier and service name.

2.12 Administrative Processes

Migrations, data repairs and administrative jobs should run as controlled, versioned processes rather than as undocumented manual actions on production hosts.

The twelve-factor model is strongest when combined with modern practices not explicit in the original formulation: supply-chain security, infrastructure as code, policy as code, service-level objectives, distributed tracing and privacy-by-design.

3. Decomposition: Monoliths, Modular Monoliths and Microservices

A monolith is deployed as one unit. The term does not necessarily imply poor internal structure. A well-designed monolith can provide simple transactions, low-latency calls, straightforward testing and centralized observability. Its weaknesses may emerge when teams need independent release schedules, selective scaling or stronger fault isolation.

A modular monolith has explicit internal modules, controlled dependencies and separate domain ownership but remains one deployment. It is often an effective intermediate architecture because it preserves operational simplicity while preparing for future extraction.

A microservices architecture consists of relatively small, independently deployable services organized around business capabilities. Each service typically owns its data and exposes a contract through an API or event interface. Microservices are therefore an organizational and operational choice as much as a programming technique.

3.1 Boundary Design

Good boundaries commonly reflect bounded contexts from domain-driven design. A bounded context is a linguistic and model boundary within which terms and business rules have consistent meanings. For example, “customer” in marketing may differ from “account holder” in billing. Splitting services by technical layers—such as a user-interface service, business-logic service and database service—often creates distributed layers rather than independent business capabilities.

Useful boundary questions include:

• Does the proposed component have a coherent business responsibility?
• Can one team own its code, data and operational health?
• Does it change for different reasons from neighboring components?
• Does it require independent scaling or availability characteristics?
• Can its interface be expressed without exposing internal data structures?
• What transactions genuinely need atomicity?

A service that cannot be changed, tested or operated independently may be a distributed module rather than a useful microservice.

3.2 Communication Patterns

Synchronous HTTP or gRPC calls provide immediate responses and straightforward request-response semantics. Their disadvantages include temporal coupling, cascading latency and failure propagation. Timeouts, bounded retries, circuit breakers and bulkheads are essential safeguards; retries must be limited and used only when operations are idempotent or otherwise safe to repeat.

Asynchronous messaging reduces temporal coupling. A producer publishes a message or event, and a consumer processes it later. This supports buffering and independent availability, but introduces duplicate delivery, ordering questions, delayed consistency and more difficult debugging.

An event records that something happened, such as `OrderPlaced`. A command requests that something happen, such as `ReserveInventory`. Confusing events with commands can produce unclear ownership and unintended coupling.

3.3 Data and Transactions

Microservices normally use database-per-service ownership. This does not require a separate physical database for every service, but it does require that other services do not bypass the owning service to manipulate its tables. Data can be shared through APIs, replicated read models or published events.

Distributed transactions are difficult because participants may fail independently. A saga coordinates a business transaction as a sequence of local transactions. If a later step fails, compensating actions attempt to undo earlier effects. Compensation is not always a true inverse: a shipped product cannot be “unshipped,” and a refund may require a separate business process.

The transactional outbox pattern addresses the problem of updating a database and publishing an event reliably. The service writes the business change and an outbox record in one local transaction. A separate publisher reads the outbox and sends the event, marking it as published. Consumers still need idempotency because publication or acknowledgment may be repeated.

3.4 API Management

An API is a product interface, not merely a network endpoint. API management commonly includes authentication, authorization, rate limiting, quotas, schema validation, versioning, traffic routing, analytics and developer documentation. A gateway can provide a unified external interface, but excessive gateway logic creates a new monolith and obscures service ownership.

Backward-compatible evolution is preferable to abrupt version changes. Additive fields, tolerant readers, explicit deprecation periods and consumer contract testing reduce coordination costs. Sensitive data should not be returned simply because it exists internally; least privilege applies to API responses as well as permissions.

4. Containers and Kubernetes

A container packages an application and its user-space dependencies while sharing the host operating system kernel. Compared with a virtual machine, a container generally has lower startup and resource overhead, but it is not a complete security boundary equivalent to a separate physical machine. Container images should be minimal, reproducible, scanned, signed where appropriate and built without embedding secrets.

A container image consists of immutable filesystem layers and metadata. A running container is an instance of that image with a writable layer and configured resources. Durable data should normally be stored outside the container’s ephemeral filesystem.

4.1 Kubernetes Architecture

Kubernetes is a declarative orchestration platform. Users specify a desired state, and controllers continually attempt to reconcile the actual state with that specification. The control plane commonly includes an API server, persistent cluster state, a scheduler and controllers. Worker nodes run workloads through a container runtime and node agents.

Important Kubernetes abstractions include:

• Pod: the smallest deployable unit, containing one or more closely coupled containers.
• Deployment: manages replicated, replaceable application pods and supports rollout strategies.
• Service: provides stable networking and load distribution to a changing set of pods.
• ConfigMap: stores non-secret configuration.
• Secret: stores sensitive values, although encryption, access control and external secret management remain important.
• StatefulSet: supports stable identity and storage patterns for selected stateful workloads.
• Job and CronJob: represent finite and scheduled work.
• Ingress or gateway resources: expose HTTP traffic through routing and policy controls.

Kubernetes improves standardization and automation, but it does not remove the need to design applications for failure. A pod restart does not repair corrupted data, an incorrectly configured readiness probe can cause an outage, and a cluster requires upgrades, capacity planning, access control and observability.

4.2 Scaling and Reliability

Horizontal scaling adds instances. A simplified capacity estimate is:

`Required instances = ceiling(peak arrival rate / sustainable capacity per instance)`

If peak arrival rate is 240 requests per second and each instance sustainably handles 80 requests per second under the defined workload and latency target, at least `ceiling(240/80) = 3` instances are required. Production designs normally add headroom for failures, uneven load and measurement uncertainty. The estimate applies only when requests are sufficiently independent and capacity is measured under representative conditions.

Autoscaling can use CPU, memory, request rate, queue depth or custom business metrics. CPU utilization alone may be a poor signal for I/O-bound services. Scaling policies must consider startup time, stabilization windows, maximum limits and downstream capacity; otherwise autoscaling can amplify overload.

Readiness indicates whether a workload should receive traffic. Liveness indicates whether it should be restarted. These probes must reflect meaningful health conditions. A readiness failure should not necessarily restart the process, and a liveness check should not depend on a fragile downstream service in a way that causes cascading restarts.

5. Event-Driven Architecture

Event-driven systems use events to communicate state changes asynchronously. A broker may provide durable storage, consumer groups, partitioning, replay and delivery semantics. At-least-once delivery is common: a message is delivered one or more times, so consumers must be idempotent. Exactly-once claims are usually limited to a defined boundary and processing model; end-to-end business effects still require careful design.

Ordering is generally guaranteed only within a defined scope, such as a partition or entity key. If all events for an order must be ordered, the order identifier may be used as the partition key, but this can create a hot partition for highly active entities. Retention and replay support recovery and new projections, but event schemas must remain interpretable over time.

A robust consumer commonly performs the following sequence:

1. Receive an event.

2. Validate its schema and authorization context.

3. Check an idempotency key or processed-event record.

4. Apply the local transaction.

5. Record completion atomically where possible.

6. Acknowledge the message only after the required durable work succeeds.

Dead-letter queues isolate messages that repeatedly fail. They require operational ownership: monitoring, diagnosis, redrive policy and retention limits. Poison messages should not be retried indefinitely.

6. Serverless Computing and Workflow Design

Serverless computing abstracts much of server provisioning and commonly charges according to invocation, execution duration or consumed resources. Function-as-a-service platforms execute short-lived functions, while managed serverless services also include databases, queues, object stores and workflow engines.

Serverless functions are effective for event transformations, APIs with variable demand, scheduled tasks, file processing and integration logic. They are less suitable when workloads require long-lived processes, specialized operating-system access, stable high utilization or extremely predictable low latency without provisioned capacity.

Important concerns include cold-start latency, execution limits, concurrency controls, dependency size, transient local storage, observability and vendor-specific interfaces. Stateless functions should persist business state in managed stores. A function may be retried after a timeout even if its side effect succeeded, so idempotency is fundamental.

A serverless workflow engine can coordinate steps such as validation, payment authorization, inventory reservation and notification. The workflow should distinguish retryable failures from business failures, use compensating actions where required, record correlation identifiers and define timeout behavior. For long-running business processes, durable workflow state is preferable to relying on a chain of function invocations.

Serverless does not mean “no operations.” The provider operates servers, but the application team still manages identity, permissions, schemas, costs, error handling, observability, quotas and deployment safety. Cost is often modeled approximately as:

`Total compute cost = invocation cost + execution-resource cost + related service costs`

The exact pricing formula varies by provider, memory allocation, execution duration, request volume, region and free tier. Therefore, architectural comparison should use measured workload assumptions rather than the label serverless alone.

7. State, Scalability and Operational Complexity

State management is a central design issue. Session state may be stored in signed tokens, a distributed cache or a durable database. Caches improve performance but introduce invalidation, staleness and eviction problems. Object storage is appropriate for large immutable artifacts, not for low-latency transactional updates. Relational databases provide strong transactional capabilities; distributed and specialized databases may offer scale or access patterns that justify different consistency models.

Consistency should be selected deliberately. Strong consistency simplifies certain business invariants but may reduce availability or increase latency across regions. Eventual consistency improves decoupling and scalability but requires user-interface explanations, reconciliation and carefully designed invariants. “Eventually consistent” is not a complete design; the acceptable delay and behavior during divergence must be specified.

Operational complexity grows with the number of independently deployed components, data stores, queues, environments and communication paths. Useful indicators include deployment frequency, lead time for changes, change failure rate, mean time to restore, alert volume, dependency count and on-call burden. A service decomposition that increases the number of deployables without improving ownership or delivery outcomes may be counterproductive.

Observability combines:

• Metrics: numerical measurements such as request rate, latency and error rate.
• Logs: detailed event records.
• Traces: causal paths across distributed components.

A practical service-level objective might specify that 99.9% of valid requests complete within a latency threshold during a measurement window. The corresponding error budget is the permitted unreliability: for a 30-day month, 0.1% of time corresponds to approximately 43.2 minutes, using 30 days × 24 hours × 60 minutes × 0.001. This calculation concerns an availability-style time budget; request-based objectives require a request-count denominator instead. SLOs should guide engineering priorities rather than become a substitute for user-centered reliability analysis.

8. Security, Governance and Ethics

Cloud-native security must operate at multiple layers. Identity-based access should replace broad network trust. Services should receive only the permissions they need, credentials should be short-lived where possible, and administrative actions should be auditable. Network policies, encryption in transit and at rest, image scanning, dependency scanning and signed artifacts help reduce attack surface.

The software supply chain is a major concern because a compromised dependency or build process can affect many deployments. Build systems should be isolated, artifacts should be traceable to source and build inputs, and critical production deployments should require policy checks and separation of duties.

Data governance includes classification, retention, residency, deletion and lawful processing. Distributed replication can unintentionally move personal data across jurisdictions. Logs and traces may contain identifiers or financial information; observability systems therefore require access controls and retention policies.

AI-assisted coding and operations can increase productivity but introduce risks of insecure generated code, license uncertainty, hallucinated configuration and exposure of proprietary data to external services. AI-generated infrastructure must undergo the same testing, review, security assessment and change control as human-authored infrastructure. Automated remediation should be constrained by permissions, rollback mechanisms and human oversight for high-impact actions.

9. Applied Case: Illustrative Online Retail Platform

Background

Consider an illustrative retailer whose single application handles browsing, checkout, inventory, payments, shipping and notifications. Traffic is seasonal, releases are coordinated by one team, and checkout failures affect revenue.

Problem

The application has grown difficult to change. A small inventory modification requires a full release, batch jobs compete with customer requests, and a database lock during reporting occasionally delays checkout. Management proposes rewriting the entire system as twenty microservices.

Analysis

A complete rewrite would introduce substantial migration and operational risk. Domain analysis identifies several distinct capabilities: catalog, inventory, order management, payment integration, shipping and notification. However, the organization has limited platform expertise and only two product teams. Twenty services would create excessive coordination and on-call burden.

Approach and Solution

The retailer first creates a modular monolith with explicit domain modules and contract tests. It separates reporting workloads through read replicas or an analytical pipeline. Inventory and order modules are then extracted because they require independent scaling and have clear ownership. The order module uses a relational database as its source of truth and publishes an `OrderPlaced` event through a transactional outbox.

An inventory consumer reserves stock idempotently. Payment authorization is modeled as a saga step with explicit timeout and compensation behavior. Notifications are asynchronous and can be delayed without blocking checkout. The public API is placed behind an API gateway with authentication, rate limits and versioning. Containers package each deployable unit, while Kubernetes manages replicated stateless services. A managed queue and object store are used rather than operated in the cluster.

The retailer uses metrics for checkout success, latency, queue depth and inventory reservation failures; traces connect requests across services. Deployment uses canary releases and automatic rollback based on service-level indicators. Secrets are stored in a managed secret system, and personal data in logs is minimized.

Outcome

The organization obtains independent scaling for high-value paths without converting every module into a service. Reporting no longer competes directly with checkout, and asynchronous notifications reduce user-facing latency. Operational work increases because the system now includes a queue, multiple deployables and distributed tracing, but the increase is bounded by selective extraction.

Learning Points

1. Decomposition should follow business and operational needs, not fashion.

2. A modular monolith can be a strategic architecture rather than a failure.

3. Events require idempotency, schema governance and monitoring.

4. A saga manages a distributed business process but does not recreate a global transaction.

5. Platform automation and observability are prerequisites for safe microservices.

10. Contemporary Directions and Best Practices

Platform engineering teams increasingly provide internal platforms that offer secure templates, deployment pipelines, observability and policy controls. The goal is a paved path: developers retain autonomy while common reliability and security practices are built into delivery workflows.

Service meshes can provide traffic management, mutual TLS and telemetry, but they add control-plane and data-plane complexity. WebAssembly-based components and lightweight isolation are being explored for portability and fast execution. Managed container platforms and serverless containers reduce the amount of cluster administration. Multi-cloud portability remains difficult because data services, identity models and operational tooling are often provider-specific.

Recommended practices include:

• Begin with domain boundaries and user outcomes, not service counts.
• Prefer a modular monolith until independent deployment has clear value.
• Define ownership, APIs, data contracts and service-level objectives.
• Make retries bounded and operations idempotent.
• Externalize configuration and protect secrets.
• Use immutable, traceable artifacts and automated policy checks.
• Treat observability, backup, disaster recovery and cost monitoring as design requirements.
• Test failure modes, dependency outages, schema evolution and restoration procedures.
• Adopt managed services selectively, with exit and data-portability considerations.
• Review the total cognitive and operational load imposed on teams.

Challenges and Limitations

Cloud-native systems can increase network latency, failure modes and debugging difficulty. Distributed transactions and consistency are harder than local transactions. Kubernetes can become a complex platform requiring specialist skills. Serverless can create provider dependency, unpredictable costs and cold-start effects. Event-driven systems can produce delayed failures that are difficult to correlate. Microservices can multiply deployment pipelines, interfaces and security policies.

There is also a human limitation: architecture cannot compensate for unclear ownership, inadequate testing or unrealistic reliability expectations. The appropriate architecture is constrained by team size, regulatory obligations, domain complexity, budget, workload variability and organizational maturity. Cloud-native adoption should therefore be incremental, measured and reversible where possible.

Chapter Summary

Cloud-native application engineering combines architectural design with automation and operational discipline. The twelve-factor principles encourage reproducible builds, externalized configuration, stateless processes, explicit dependencies and disposable execution units. Microservices provide independent deployment and ownership when boundaries reflect coherent business capabilities, but a modular monolith may be more suitable when operational capacity is limited.

Containers package applications consistently, while Kubernetes reconciles declarative workload specifications and provides scheduling, networking, rollout and scaling mechanisms. Event-driven architecture reduces temporal coupling but requires idempotency, schema evolution, ordering decisions and dead-letter management. Serverless platforms reduce infrastructure administration and suit variable, event-oriented workloads, but they do not eliminate security, cost, observability or reliability responsibilities.

State, consistency, API evolution and distributed transactions must be designed explicitly. Sagas and transactional outboxes help coordinate distributed work, while service-level objectives and error budgets connect reliability to engineering decisions. Security, privacy, supply-chain integrity, governance and responsible use of AI are integral to cloud-native practice. The central principle is selective adoption: use the smallest architecture that satisfies business, scalability and operational requirements, and evolve it through evidence rather than technological fashion.

Key Terms

Twelve-factor application: A set of practices for building portable, reproducible and cloud-suitable services.

Cloud-native: An approach that designs software to exploit automation, elasticity, managed services and distributed infrastructure.

Modular monolith: A single deployable application with explicit internal modules and controlled dependencies.

Microservice: An independently deployable component organized around a business capability.

Bounded context: A domain boundary within which concepts and rules have consistent meanings.

API gateway: A managed entry point that applies routing, security, rate limiting and API policies.

Idempotency: The property that repeating an operation produces the same intended business effect.

Event: A record that a state change or business fact has occurred.

Saga: A sequence of local transactions coordinated through steps and compensating actions.

Transactional outbox: A pattern that stores a business change and an outgoing event in one local transaction.

Container: An isolated execution environment packaging an application and its user-space dependencies.

Kubernetes: A declarative platform for orchestrating containerized workloads.

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

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

Serverless: An operating model in which infrastructure provisioning and much resource management are abstracted from the application team.

Cold start: Startup latency incurred when a serverless execution environment must be initialized.

Eventual consistency: A model in which replicas may temporarily differ but converge if updates cease.

Observability: The ability to understand system behavior through metrics, logs and traces.

Service-level objective: A target for a measurable reliability or performance characteristic.

Error budget: The permitted unreliability implied by a service-level objective.

Review Questions

Short Answer Questions

1. What is the difference between a modular monolith and a microservices architecture?

2. Why should configuration and secrets be separated from application code?

3. What is the purpose of a Kubernetes readiness probe?

4. Why are idempotent consumers important in event-driven systems?

5. State two limitations of serverless functions.

Long Answer Questions

1. Explain the twelve-factor methodology and discuss how its principles support continuous delivery.

2. Compare synchronous and asynchronous communication in microservices, including their failure and consistency implications.

3. Describe Kubernetes’ declarative control model and explain the roles of Pods, Deployments and Services.

4. Explain the transactional outbox and saga patterns, including the problems each addresses and does not address.

5. Critically evaluate the claim that every large application should be rewritten as microservices.

Analytical / Application Questions

1. A service receives 500 requests per second, while one instance sustainably handles 125 requests per second. Calculate the minimum number of instances and identify two reasons production capacity may need to be higher.

2. Design an event-driven checkout workflow involving order creation, inventory reservation, payment and notification. Specify failure handling, idempotency and compensation behavior.

3. An organization has three development teams, limited Kubernetes expertise and highly variable image-processing workloads. Recommend an architecture using a combination of modular services, containers, managed services and serverless components, and justify the trade-offs.

Multiple Choice Questions with Answers

Question 1

Which twelve-factor principle requires environment-specific settings to be kept separate from application code?

A. Configuration

B. Port binding

C. Disposability

D. Concurrency

Correct Answer: A. Configuration

Question 2

What is the strongest architectural reason for extracting a module into a microservice?

A. It uses a different programming language

B. It has a coherent business capability requiring independent ownership or scaling

C. It contains more than five classes

D. It has its own user-interface page

Correct Answer: B. It has a coherent business capability requiring independent ownership or scaling

Question 3

What is the primary purpose of a transactional outbox?

A. To eliminate all distributed transactions

B. To store secrets outside a container

C. To reliably coordinate a local database change with publication of an event

D. To increase CPU capacity automatically

Correct Answer: C. To reliably coordinate a local database change with publication of an event

Question 4

Which Kubernetes object provides stable network access to a changing group of Pods?

A. Job

B. ConfigMap

C. Deployment

D. Service

Correct Answer: D. Service

Question 5

A service receives 240 requests per second and one instance handles 80 requests per second under the stated workload. What is the minimum number of instances before safety headroom?

A. 2

B. 3

C. 4

D. 5

Correct Answer: B. 3

Question 6

Why must consumers in an at-least-once messaging system commonly be idempotent?

A. Messages may be delivered more than once

B. Messages are always delivered in global order

C. Consumers cannot access databases

D. The broker prevents acknowledgments

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

Question 7

Which statement best describes a serverless cold start?

A. A database losing all stored data

B. A delay caused by initializing an execution environment

C. A Kubernetes node reaching maximum CPU

D. A message being placed in a dead-letter queue

Correct Answer: B. A delay caused by initializing an execution environment

Question 8

What does a Kubernetes readiness probe primarily determine?

A. Whether a workload should receive traffic

B. Whether an image was signed

C. Whether a secret is encrypted

D. Whether a database transaction is globally committed

Correct Answer: A. Whether a workload should receive traffic

Question 9

For a 30-day month and a 99.9% time-based availability objective, approximately how much time is in the error budget?

A. 4.32 minutes

B. 14.4 minutes

C. 43.2 minutes

D. 432 minutes

Correct Answer: C. 43.2 minutes

Question 10

Which practice best limits cascading failures in synchronous service calls?

A. Unlimited retries with no timeout

B. Bounded timeouts, controlled retries and circuit breaking

C. Sharing all database tables

D. Removing observability to reduce overhead

Correct Answer: B. Bounded timeouts, controlled retries and circuit breaking