Provisioning, DevOps and Cloud Operations

Introduction

Cloud computing changes infrastructure from a collection of manually configured machines into programmable, observable and continuously operated services. A cloud engineer may create resources through a web console, a command-line interface (CLI), a software development kit (SDK), or infrastructure as code (IaC). These mechanisms are complementary: consoles are useful for exploration, CLIs support repeatable administration, SDKs enable application-driven automation, and IaC expresses the desired environment in version-controlled files.

Provisioning, however, is only the beginning. Cloud systems must also be delivered through reliable CI/CD pipelines, configured consistently, monitored continuously and operated through disciplined incident-response processes. This chapter examines these activities as one operational system rather than as isolated tools.

Learning Objectives

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

1. Compare cloud consoles, CLIs, SDKs and IaC as provisioning mechanisms.
2. Explain declarative and imperative infrastructure management.
3. Describe CI/CD pipelines and deployment strategies.
4. Explain configuration management, secrets management and drift control.
5. Distinguish logs, metrics, traces and events in an observability system.
6. Apply service-level indicators, objectives and error budgets.
7. Describe incident response, post-incident learning and operational automation.
8. Evaluate the governance, security and cost implications of cloud operations.

1. Provisioning Cloud Resources

Provisioning is the process of creating and preparing computing resources such as virtual networks, subnets, identity policies, databases, containers, storage and compute instances. In a traditional data centre, provisioning may involve purchasing equipment and manually configuring operating systems. In the cloud, resources can be created on demand through authenticated APIs.

A provisioning request normally contains four elements:

• Resource type: for example, a virtual machine, object-storage bucket or managed database.
• Configuration: size, region, network placement, encryption and availability settings.
• Identity and authorization: the principal permitted to create or modify the resource.
• Lifecycle policy: how the resource is tagged, backed up, updated and eventually removed.

Provisioning should be reproducible. If two environments are intended to be equivalent, their differences should be explicit, such as a development environment using smaller instances. Reproducibility reduces configuration drift and makes disaster recovery more credible.

Provisioning Interfaces

A management console is a graphical interface provided by a cloud platform. It is valuable for learning, inspecting resources, troubleshooting and performing occasional administrative tasks. Its weaknesses are that actions can be difficult to audit precisely, easy to perform inconsistently and hard to reproduce.

A command-line interface sends commands to cloud APIs. CLI commands can be placed in shell scripts and used in automation. They are efficient for experienced operators, but scripts require careful handling of credentials, quoting, error codes and idempotence.

An SDK is a programming library that exposes cloud services to languages such as Python, Java, Go or JavaScript. SDKs are appropriate when an application must create resources dynamically or when operational logic requires conditionals, retries and integration with databases or approval systems. SDK programs must handle authentication, pagination, rate limits, timeouts and partial failure.

Infrastructure as code describes infrastructure in machine-readable files maintained like source code. A tool then calculates and applies the required changes. IaC supports code review, version history, testing and repeatable environments.

Imperative and Declarative Provisioning

Imperative provisioning specifies how to perform actions: create a network, then create a subnet, then attach a route. Declarative provisioning specifies what state is required: a network with a particular address range, a subnet and a route. The provisioning engine determines the operations needed to reach that state.

Declarative tools generally improve repeatability, but they do not eliminate design responsibility. A declaration may still contain insecure network rules, excessive permissions or an expensive resource type. IaC should therefore undergo peer review, automated policy checks and testing.

An important property is idempotence. An operation is idempotent when applying it repeatedly produces the same intended result as applying it once. For example, “ensure a storage bucket has versioning enabled” is more safely repeatable than “create another bucket.” Idempotence is essential when automation retries after a timeout because the operator cannot immediately determine whether the first request succeeded.

IaC Workflow

A mature IaC workflow commonly contains these stages:

1. Define resources in source-controlled files.
2. Validate syntax and run static security or policy checks.
3. Generate a plan showing proposed additions, changes and deletions.
4. Review and approve the plan.
5. Apply the approved change through an authenticated pipeline.
6. Verify health, cost, security and expected outputs.
7. Record the change and monitor for unintended effects.

State management deserves special attention. Some IaC tools maintain a state file mapping configuration objects to real cloud resources. State should be protected against unauthorized access, corruption and concurrent modification. A remote state store should normally provide encryption, access control, versioning and locking. State must not be treated as harmless text because it may contain identifiers or sensitive attributes.

2. DevOps and the Software Delivery Pipeline

DevOps is an organizational and technical approach that integrates software development, operations, security and business objectives. It emphasizes shared responsibility, small changes, automation, feedback and continuous improvement. DevOps is not simply the purchase of a pipeline product.

Continuous Integration and Continuous Delivery

Continuous integration (CI) means that developers frequently merge changes into a shared repository and automatically build and test them. CI detects integration problems early. A typical CI sequence includes source checkout, dependency resolution, static analysis, unit tests, packaging and artifact publication.

Continuous delivery means that validated software is kept in a deployable state and can be released through a controlled process. Continuous deployment goes further: changes that pass the required controls are released automatically to production.

A pipeline should promote the same immutable artifact through environments. Rebuilding separately for testing and production can create differences, undermining confidence that the tested artifact is the deployed artifact.

A practical pipeline includes:

• source-control trigger;
• dependency and license checks;
• unit, integration and security tests;
• artifact creation and signing;
• infrastructure validation;
• deployment to a temporary or staging environment;
• smoke and acceptance tests;
• approval or automated promotion;
• production deployment and post-deployment verification.

Pipeline credentials should be short-lived and scoped to the required environment. Secrets should be retrieved from a secrets manager rather than committed to source control or printed in logs.

Deployment Strategies

A rolling deployment replaces instances or containers gradually. It reduces the capacity removed at one time but can temporarily run multiple software versions.

A blue-green deployment maintains two environments. Traffic is directed to the active environment, while the new version is deployed and tested in the inactive environment. Switching traffic can be rapid, although two environments may increase cost and database compatibility remains a challenge.

A canary deployment sends a small proportion of traffic to the new version and compares its behavior with the existing version. It limits exposure, but requires reliable metrics and a safe mechanism for increasing or reversing traffic.

A feature flag separates code deployment from feature activation. It can support gradual release and rapid disablement, but old flags create operational and maintenance debt.

Rollback is not always safe. A code rollback may be incompatible with a database migration that has already changed schemas or data. Backward-compatible, expand-and-contract migrations are often safer: first add compatible structures, then migrate usage, and only later remove obsolete structures.

3. Configuration and Secrets Management

Configuration includes values that vary by environment or operation, such as database endpoints, feature settings, timeouts and resource limits. Configuration should be externalized from application binaries so that the same artifact can operate in different environments.

Configuration management seeks consistency across hosts and services. It may use image building, startup scripts, agents or orchestration manifests. Immutable infrastructure creates a new image rather than modifying a running server in place. This improves repeatability, while mutable systems can be useful where rapid local changes or specialized legacy software makes replacement difficult.

A configuration hierarchy should be explicit. For example, organization-wide defaults may be overridden by environment settings and then by service-specific settings. Uncontrolled precedence creates difficult-to-diagnose behavior.

Secrets include passwords, private keys, access tokens and encryption keys. Good practice includes:

• storing secrets in a managed secrets or key-management service;
• granting access through workload identity rather than shared credentials;
• rotating credentials periodically and after suspected exposure;
• limiting visibility and lifetime;
• preventing secrets from appearing in source, images, tickets and logs;
• auditing access and failed retrieval attempts.

Configuration drift occurs when actual resources differ from the declared or approved state. Drift can arise from console edits, emergency fixes, provider changes or incomplete automation. Detection may be scheduled or event-driven. A detected difference should be classified as intentional, temporary or unauthorized before it is automatically overwritten.

4. Observability: Logs, Metrics, Traces and Events

Monitoring asks whether selected conditions are within expected limits. Observability asks whether internal system states can be inferred from the outputs the system produces. It is especially important in distributed systems, where a user request may cross gateways, services, queues, databases and external APIs.

Logs

A log is a time-ordered record of an event. Structured logs, commonly encoded as JSON, are easier to search than unstructured text. Useful fields include timestamp, severity, service, environment, request or trace identifier, operation, outcome and error classification. Logs should be designed for diagnosis rather than generated indiscriminately.

Sensitive data must be excluded or masked. Retention should reflect legal, security and operational requirements. Excessive logging increases storage cost and may expose personal information.

Metrics

A metric is a numerical measurement collected over time. Common types include:

• counter: a value that generally increases, such as completed requests;
• gauge: a current value, such as queue depth;
• histogram: a distribution of observations, such as request latency;
• summary: a statistical summary, depending on the monitoring system.

Averages can hide tail behavior. If users experience the 95th or 99th percentile latency, the mean may provide a misleadingly optimistic view. Metric labels should be controlled because unbounded high-cardinality labels, such as unique user IDs, can cause cost and performance problems.

Traces

A distributed trace follows one transaction across services. A trace contains spans, with each span representing an operation and its duration. Context propagation allows a downstream service to associate its span with the original request. Traces are particularly useful for locating latency and identifying dependency failures.

Logs, metrics and traces are strongest when correlated. A metric alert can link to a trace sample, and a trace can link to service logs using a common trace identifier.

Service-Level Indicators and Objectives

A service-level indicator (SLI) is a measured aspect of service behavior, such as successful request proportion or latency. A service-level objective (SLO) is a target for an SLI over a stated period. A service-level agreement (SLA) is usually an external commitment that may include remedies; it should not be confused with an internal SLO.

For an availability SLI, if N_s is the number of successful valid requests and N_t is the total number of valid requests during a measurement period, then:

The quantities must use the same population and time window. If 99,500 of 100,000 valid requests succeed, availability is 0.995, or 99.5%.

An SLO of 99.9% implies an error budget of:

For a 30-day period with 43,200 minutes, a 99.9% SLO permits approximately 43.2 minutes of unavailability, assuming the SLO is measured by time and the period is exactly 30 days. A request-based SLO may produce a different budget because it counts failed requests rather than unavailable minutes.

Error budgets connect reliability to delivery decisions. If a service consumes its budget rapidly, the team may pause risky releases and prioritize reliability work. This is a governance mechanism, not permission to intentionally cause failures.

5. Cloud Operations and Incident Response

Operations includes routine maintenance, capacity management, backup verification, patching, access review, cost control and recovery testing. Operational readiness should be assessed before production release.

An incident is an event that threatens or degrades service quality, security, data integrity or regulatory compliance. Incident response should be planned before an emergency. A basic lifecycle is:

1. Detection: an alert, user report or security signal identifies a possible problem.
2. Triage: responders establish impact, scope, severity and immediate risks.
3. Containment: the team limits damage, perhaps by disabling a feature or isolating a workload.
4. Mitigation: service is restored through rollback, failover, scaling or another temporary measure.
5. Eradication and recovery: the underlying cause is addressed and normal operation verified.
6. Communication: stakeholders receive accurate, timely updates.
7. Learning: a blameless review identifies technical and organizational improvements.

Incident roles should be clear. An incident commander coordinates decisions; technical leads investigate and implement changes; a communications lead manages stakeholder updates; and a scribe records the timeline. In small teams one person may hold several roles, but responsibilities should still be explicit.

Alerts should be actionable. An alert that requires no response is usually a notification or dashboard signal, not an alert. Alert fatigue occurs when excessive or low-quality alerts cause responders to ignore important signals. Each alert should identify the condition, impact, urgency and a first diagnostic action.

Runbooks provide tested procedures for common situations, such as restoring a database backup, rotating a credential or draining an unhealthy node. Automation can execute safe, well-understood steps, but high-impact actions should include authorization, guardrails and an emergency stop.

6. Reliability, Capacity and Cost Operations

Cloud elasticity does not remove the need for capacity planning. Teams must understand workload patterns, scaling limits, quotas, startup time and dependency capacity. Autoscaling based only on CPU may fail when the true constraint is queue depth, database connections or external API limits.

Reliability also depends on failure domains. Resources should be distributed across suitable zones or regions when the business requirement justifies the added complexity and cost. Backups are not sufficient unless restoration is periodically tested. Recovery planning commonly distinguishes:

• Recovery point objective (RPO): the maximum acceptable amount of data loss measured in time.
• Recovery time objective (RTO): the target maximum time to restore service.

Cloud operations also includes FinOps: the shared practice of managing cloud cost through visibility, accountability and optimization. Tags or labels should identify owner, environment and cost centre. Teams should examine idle resources, storage retention, data-transfer charges, licensing and the cost of high availability. Cost optimization must not silently violate security or reliability objectives.

7. Governance, Security and Ethical Considerations

Operational automation can amplify both good and bad decisions. A faulty script with broad permissions can delete resources at large scale. Therefore, use least privilege, approvals for destructive actions, protected branches, policy-as-code and tested recovery procedures.

Audit trails should record who or what made a change, when it occurred, what was changed and whether it succeeded. Logs may themselves contain personal or confidential information, so access, retention and deletion must follow organizational policy and applicable law.

Data residency, cross-border transfer, retention and breach notification requirements may affect architecture. Automated decisions about scaling, access or user treatment should be explainable enough for responsible oversight. AI-assisted operational tools can summarize alerts, suggest probable causes or generate configuration, but their output must be reviewed. An AI system should not receive unrestricted production credentials or be allowed to execute destructive actions without controlled authorization.

8. Applied Case: An Online Learning Platform

The following is an illustrative case.

Background

A university operates an online learning platform with a web application, an API, a relational database, object storage for videos and a message queue for email notifications. Releases are performed manually from an engineer’s laptop. The platform experiences peak demand before assignment deadlines.

Problem

The team reports inconsistent environments, slow releases and prolonged diagnosis when students experience failed submissions. A console-created security rule is not represented in the deployment documentation. Logs are plain text, and there is no clear availability target.

Analysis

The platform has three related weaknesses. First, provisioning is not reproducible. Second, delivery lacks automated verification and rollback. Third, operational signals cannot connect a failed submission to the responsible service or database transaction.

The team defines an SLO of 99.9% successful submission requests during the academic term. They select successful valid submissions as the numerator and all valid submission attempts as the denominator. They also define latency objectives for the 95th percentile and establish an error budget. This makes reliability measurable and gives release decisions a shared basis.

Approach and Solution

The network, compute services, database configuration and monitoring resources are expressed in IaC and stored in a protected repository. A pipeline validates the files, performs policy checks, generates a plan and requires review for production changes. Environments use parameterized configuration, while secrets are retrieved through workload identity from a managed secrets service.

The application is packaged once and promoted through testing and production. Integration tests submit assignments to a temporary environment. Production releases use a canary strategy. The pipeline checks error rate, submission latency and queue depth before increasing traffic.

The application emits structured logs with request and trace identifiers. Metrics measure request outcomes, queue age, database connections and saturation. Distributed tracing follows a submission from the gateway through the API, database and notification queue. Dashboards show both technical indicators and the SLO.

A runbook describes database failover, queue backlog response, credential rotation and rollback. An incident commander is appointed for major events. After a failure, a blameless review records contributing conditions, including inadequate validation and unclear ownership, rather than blaming an individual.

Outcome

The organization gains repeatable environments, faster and safer releases, shorter diagnostic time and clearer trade-offs between feature delivery and reliability work. Cost tags also identify that video storage retention is excessive, allowing an approved lifecycle policy to reduce cost without removing required course material.

Learning Points

The case demonstrates that DevOps is a system of practices. IaC without review can reproduce insecure infrastructure; CI without meaningful tests can automate defective releases; and observability without defined objectives can produce dashboards without decisions. Effective cloud operations joins provisioning, delivery, measurement, governance and human responsibility.

Challenges and Limitations

Cloud automation has limitations. IaC abstractions may lag behind provider features, and provider APIs can change behavior. Declarative tools may struggle with resources modified outside their control. Distributed tracing adds instrumentation and storage cost. High availability across regions introduces data-consistency, networking and financial complexity. SLOs can be gamed if they measure only easy-to-satisfy requests, while error budgets can become contentious when business priorities conflict.

Automation also creates a false sense of safety. A pipeline can deploy rapidly, but speed without good tests and observability increases risk. The appropriate goal is not maximum automation; it is controlled automation with clear ownership, reversible changes and evidence-based decisions.

Contemporary Developments and Best Practices

Modern cloud operations increasingly use platform engineering, where internal platforms provide standardized deployment paths, identity integration, observability and approved infrastructure patterns. Policy-as-code checks compliance before deployment. GitOps extends IaC principles by treating a version-controlled repository as the source of desired state and continuously reconciling runtime systems with it.

OpenTelemetry provides a widely adopted approach to collecting and exporting telemetry across logs, metrics and traces. The precise backend may differ, but portable instrumentation reduces dependence on one monitoring product. Software supply-chain security is also increasingly important: organizations sign artifacts, generate provenance, scan dependencies and restrict build permissions.

A practical set of best practices is:

• begin with small, reviewable changes;
• use least privilege and short-lived credentials;
• keep infrastructure and application changes version controlled;
• test plans, images, configurations and recovery procedures;
• promote immutable artifacts;
• define SLIs and SLOs before selecting alerts;
• correlate logs, metrics and traces;
• make runbooks accessible and rehearse them;
• monitor cost, performance, security and reliability together;
• conduct blameless post-incident reviews;
• remove obsolete permissions, resources, feature flags and alerts.

Chapter Summary

Cloud provisioning can be performed through consoles, CLIs, SDKs and infrastructure as code. These interfaces differ in convenience, programmability and repeatability, but professional operations normally favor version-controlled, declarative and idempotent workflows. CI/CD connects source changes to automated testing, artifact management, controlled deployment and verification. Rolling, blue-green, canary and feature-flag strategies provide different balances of risk, cost and rollback capability.

Configuration management reduces environmental inconsistency, while secrets management protects credentials and supports rotation. Observability combines structured logs, metrics, distributed traces and events. SLIs and SLOs turn reliability into measurable objectives, and error budgets help balance change with operational risk. Incident response requires detection, triage, containment, mitigation, recovery, communication and learning. Runbooks and carefully governed automation reduce response time, but human accountability remains essential.

Cloud operations also includes capacity, backup, disaster recovery, security, governance and cost management. The most effective approach treats provisioning, delivery and operations as one feedback loop: changes are made reproducibly, measured continuously, reviewed responsibly and improved through evidence.

Key Terms

Provisioning: Creating and preparing cloud resources for use.

Management console: A graphical interface for administering cloud services.

CLI: A command-line interface used to issue administrative commands.

SDK: A programming library for interacting with cloud APIs.

Infrastructure as code: Machine-readable management of infrastructure configuration.

Declarative configuration: A description of the desired end state.

Idempotence: The property that repeated application produces the same intended result.

Configuration drift: Difference between approved or declared state and actual state.

Continuous integration: Frequent integration of code supported by automated build and test activities.

Continuous delivery: Keeping validated software ready for controlled release.

Continuous deployment: Automatically releasing validated changes to production.

Canary deployment: Gradually exposing a new version to a limited share of traffic.

Observability: The ability to infer internal system behavior from outputs.

Metric: A numerical measurement recorded over time.

Distributed trace: A linked representation of one transaction across services.

SLI: A measured indicator of service behavior.

SLO: A target for an SLI over a defined period.

Error budget: The permitted unreliability implied by an SLO.

Incident response: The organized process of managing service or security disruption.

Runbook: A documented procedure for diagnosing or operating a system.

Review Questions

Short Answer Questions

1. What is the difference between a cloud console and infrastructure as code?
2. Why is idempotence important in provisioning automation?
3. Distinguish continuous delivery from continuous deployment.
4. What information should a useful structured log contain?
5. Define an SLO and explain its relationship to an error budget.

Long Answer Questions

1. Compare consoles, CLIs, SDKs and IaC in terms of repeatability, flexibility, auditability and suitable use cases.
2. Explain how a CI/CD pipeline can safely promote an immutable artifact to production.
3. Discuss configuration drift, secrets management and the security risks of manual changes.
4. Explain how logs, metrics and distributed traces complement one another in diagnosing a distributed application.
5. Describe the stages, roles and communication practices of an effective incident-response process.

Analytical / Application Questions

1. A service records 2,000,000 valid requests in a month, of which 1,996,000 succeed. Calculate the request-based availability and determine whether it meets a 99.9% SLO.
2. Design a deployment strategy for a payment service where failures are costly and database schema changes are frequent. Justify your choice and explain rollback constraints.
3. An organization discovers that production resources differ from its IaC repository after several emergency console changes. Propose a safe process for detecting, classifying and reconciling the drift.

Multiple Choice Questions with Answers

Question 1

Which provisioning method most directly supports version-controlled, reviewable and repeatable infrastructure?

A. Management console

B. Infrastructure as code

C. Manual server login

D. Unrecorded SDK execution

Correct Answer: B. Infrastructure as code

Question 2

What property allows an automation operation to be safely repeated without creating unintended duplicate results?

A. Opacity

B. Idempotence

C. Randomization

D. Cardinality

Correct Answer: B. Idempotence

Question 3

Which statement best describes continuous deployment?

A. Developers never merge code into a shared repository

B. Validated changes are automatically released to production

C. Only infrastructure is tested

D. Every release requires a manual rebuild on a laptop

Correct Answer: B. Validated changes are automatically released to production

Question 4

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

A. Canary deployment

B. Big-bang deployment

C. Cold backup

D. Static provisioning

Correct Answer: A. Canary deployment

Question 5

Which telemetry type is most suitable for following one request across several services?

A. Gauge

B. Distributed trace

C. Storage tag

D. Configuration file

Correct Answer: B. Distributed trace

Question 6

A service has 99,500 successful requests out of 100,000 valid requests. What is its request-based availability?

A. 0.095%

B. 0.5%

C. 99.5%

D. 100.5%

Correct Answer: C. 99.5%

Question 7

Which practice is most appropriate for storing database passwords used by cloud workloads?

A. Commit them to a public repository

B. Place them in application log messages

C. Store them in a managed secrets service

D. Embed them permanently in a container image

Correct Answer: C. Store them in a managed secrets service

Question 8

What is the primary purpose of an error budget?

A. To define the maximum number of developers on a team

B. To connect permitted unreliability with release and reliability decisions

C. To calculate object-storage capacity only

D. To replace all incident reviews

Correct Answer: B. To connect permitted unreliability with release and reliability decisions

Question 9

Which incident-response role primarily coordinates decisions and activities during a major incident?

A. Incident commander

B. Artifact publisher

C. Database schema owner only

D. End user

Correct Answer: A. Incident commander

Question 10

Why can an average latency metric be insufficient for user-experience analysis?

A. Averages cannot be stored electronically

B. It may hide slow tail behavior affecting a significant percentile of users

C. It always equals the maximum latency

D. It measures only storage capacity

Correct Answer: B. It may hide slow tail behavior affecting a significant percentile of users