Cloud Computing and DevOps Engineering

01Purpose and scope

• This manual supports the course Cloud Computing and DevOps Engineering. It describes how practitioners design, provision, deliver and operate software on cloud platforms, and how development and operations work is shared across a team. It is written as a reference for the everyday decisions engineers make, not as a replacement for provider documentation, internal runbooks or formal training.
• The scope covers infrastructure provisioned as code, container and virtual machine workloads, managed database and messaging services, continuous integration and continuous delivery pipelines, observability, and the controls that keep a production system safe to change. It touches the roles of developers, platform engineers, site reliability engineers, security staff, auditors, product owners and finance staff, because each of them shapes how cloud and DevOps work is done.
• The scope excludes detailed certification exam content, application architecture for specific business domains, and vendor specific feature walkthroughs. Where a concept depends on a particular provider, the manual describes the general pattern and expects the reader to confirm the exact service behavior in current provider documentation.

02Core principles

• Most of the discipline rests on a few principles. The first is that environments should be described in files that can be versioned, reviewed and rebuilt. When infrastructure is defined as code, a change becomes a diff that a colleague can read, and a failed environment can be recreated rather than repaired by hand. Manual console changes are not forbidden in every case, but they should be rare, recorded and reconciled back into code soon after.
• The second principle is small, frequent change. Smaller releases are easier to test, easier to roll back and easier to explain when something goes wrong. Teams that batch changes into quarterly releases usually discover that the batch is too large to reason about, so they add approvals and freezes that slow everything down further.
• The third principle is shared responsibility. Cloud providers publish shared responsibility models that split security and operational duties between the provider and the customer. The split changes with the service model. With infrastructure as a service the customer manages most of the operating system and above, while with a managed database the provider handles more of the patching but the customer still owns access configuration, data classification and backup policy. Engineers should check the model for each service they use instead of assuming a single division of labor.
• Two more principles shape daily choices: least privilege for identities and services, and observability built in from the start. Every service account should receive only the permissions it needs, and every workload should emit logs, metrics and traces that let someone answer what changed and what it affected.
• Trade-offs are unavoidable. Managed services reduce operational toil but tie the system to a provider's APIs and limits. Heavy automation speeds delivery but concentrates risk in the pipeline itself. Strong guardrails protect production but can frustrate teams if they block legitimate work without a clear route to exception. The right balance depends on the size of the team, the sensitivity of the data and the cost of an outage.

03Planning and preparation

• Before building anything, establish an inventory of workloads, their owners, their dependencies and their data. A simple table listing each application, its environment needs, its data classification, its recovery time expectation and its business owner is often enough to start. Gaps in this inventory become the source of surprise outages later, usually when someone discovers that a batch job depends on a database nobody documented.
• Account and subscription structure is one of the earliest decisions and one of the hardest to change later. Many organizations separate production, non-production and shared services into distinct accounts or subscriptions so that blast radius, billing and access policy can be managed per boundary. The exact hierarchy, naming and tagging rules should be written down as an architecture decision record so new projects follow the same pattern.
• Region selection depends on data residency rules, latency to users, service availability in the region and cost. Residency requirements in particular vary by jurisdiction and by contract, so the choice should be confirmed with legal or compliance staff rather than made from a default. The manual cannot tell you which rule applies to your data. Consult your organization's counsel and the current text of the applicable law.
• Plan the environment strategy early. Decide how many environments exist, how code moves between them, how test data is created and removed, and who may deploy to each one. Plan the cost model too. Estimate monthly spend for each workload, set budgets and alerts, and agree on tagging so costs can be attributed to a team. Without tags, cost reviews become arguments about whose resources these are.
• Choose tooling with the team that will operate it. Source control, pipeline runner, infrastructure as code tool, secrets store, artifact registry and monitoring platform all need owners and support paths. A tool that only one person understands is a liability even if it is technically excellent.

04Recommended workflow

1. 1
   : Define the change in a ticket or issue that states the purpose, the affected services, the expected user impact and the rollback approach. Link the issue to the code change so reviewers and auditors can trace the reason for each modification.
2. 2
   : Write or update the infrastructure and application code in a branch. Keep configuration in version control, parameterize values that differ between environments, and keep secrets out of the repository. Reference secrets from a managed secrets store and rotate them on a defined schedule.
3. 3
   : Run automated checks locally and in the pipeline. These include formatting, linting, unit tests, static analysis of infrastructure templates, dependency and container image scanning, and a plan or preview of the infrastructure change that shows what will be created, modified or destroyed. Read the plan carefully, because deletions that appear in it are often the most consequential lines.
4. 4
   : Obtain peer review. A reviewer should check not only syntax but the blast radius, the permissions granted, the cost effect and the failure behavior. For high-impact changes, require a second reviewer from the owning service team or the platform group.
5. 5
   : Deploy to a non-production environment that resembles production in shape, if not in scale. Run integration tests, smoke tests and any load or failover tests that the change warrants. Record results alongside the change so they are easy to find later.
6. 6
   : Promote to production using a controlled method such as a canary release, blue green switch or staged rollout by region or availability zone. Watch the key indicators during the rollout, and define in advance the thresholds that will trigger a pause or rollback. Do not promote while a related incident is open unless the incident lead has agreed.
7. 7
   : Verify the outcome. Confirm that the deployed version matches the version in source control, that monitoring shows expected behavior, and that no unexpected resources or configuration drift appeared. Close the change record with the verification notes.
8. 8
   : Reconcile any emergency or manual changes made during the process. Update the code so the next deployment does not revert the fix, and document why the manual path was taken so the decision can be reviewed.

05Quality checks, risk controls and compliance

• Quality checks work best when they are automated and fail the pipeline early. Policy as code tools can enforce rules such as required tags, approved regions, encryption settings, public access restrictions and maximum instance sizes. Describe the policy in plain language first, then encode it, then test the policy against known good and known bad examples so that it does not block legitimate work by accident.
• Risk controls include separation of duties, change approval for production, automated backups with tested restores, and documented rollback steps. A backup that has never been restored is a hope rather than a control, so schedule restore tests and record the time they take. Access reviews should run on a regular cycle and remove unused accounts and stale keys.
• Security baselines help teams avoid reinventing hardening guidance. The Center for Internet Security publishes benchmarks for many cloud services and operating systems, and frameworks such as NIST SP 800-53 and ISO/IEC 27001 describe control families that auditors commonly reference. Use them as starting points and adapt them to your environment, because a benchmark applied without thought can break an application.
• Compliance obligations depend heavily on jurisdiction, industry and contract. Privacy and data protection laws, sector rules for health, payment card or financial data, and customer contract clauses can each impose requirements on logging, encryption, data location and incident reporting. The applicable rules change over time, so consult the current text of each law or standard and involve your compliance and legal staff. This manual does not replace qualified legal, security or audit judgment, and regulated workloads require approved procedures and any required authorization before changes are made.
• Evidence matters as much as the control itself. Keep pipeline logs, approval records, plan outputs and access review results in a location that is retained according to policy and protected from alteration.

06Collaboration and documentation

• DevOps work crosses team boundaries, so documentation should be written for the people who will need it under pressure. Architecture decision records explain why a choice was made, what alternatives were considered and what would cause the decision to be revisited. Runbooks describe the steps for common operations such as rotating a certificate, scaling a cluster or restoring a database, and they should be tested during calm periods rather than first used during an incident.
• Ownership should be explicit. Each service needs a named owner, a support channel, an on-call rotation and an escalation path. Shared platforms need a service catalog that tells application teams what is available, what it costs and how to request changes. When ownership is vague, incidents linger because everyone assumes someone else is responding.
• After incidents, hold blameless postmortems that focus on system conditions rather than individual error. Record a timeline, the contributing factors, what detected the problem, what slowed recovery and the follow up actions with owners and due dates. Review open actions in a regular meeting, because postmortem actions that are never completed teach the team that the process is theater.
• Communication with non-technical stakeholders needs its own attention. Finance wants cost forecasts, product owners want release schedules and risk, and auditors want evidence. Prepare short summaries for each audience and link them to the detailed records rather than sending raw logs.

07Measures and continuous improvement

• Measure delivery and operational performance with indicators that reflect outcomes rather than activity. The DORA research program popularized four widely used measures: deployment frequency, lead time for changes, change failure rate and time to restore service. They are useful as a conversation starter, but they should not be used to rank teams against each other, and they are only meaningful when each team defines its terms consistently.
• Service level objectives express reliability as a target for a user facing measure such as request success rate or latency at a given percentile. An error budget is the amount of unreliability the target allows over a period. When the budget is spent, teams typically slow feature releases and focus on stability work. Set targets with product owners, because a target that users do not notice may be too strict and one they notice may be too loose.
• Track cost measures alongside reliability. Cost per transaction, unused reserved capacity, idle resources and the share of spend that carries correct tags are practical indicators. Review them monthly with the owning teams and act on anomalies quickly.
• Continuous improvement comes from reviewing these measures and changing practice. Pick one or two bottlenecks at a time, such as a slow manual approval or a flaky test suite, run a small experiment to address it, and measure whether it helped. Keep the list of improvements visible so progress is recognized.
• Practice differs by context. A small startup with one cloud account may rely on a simple pipeline and a shared on-call group. A regulated enterprise will have more approvals, longer audit trails and stricter separation of duties. Both can practice sound DevOps, but the controls and the pace will differ, and copying another organization's model without adapting it often adds cost without adding safety.

08Common mistakes and how to prevent them

• Configuration drift is among the most common problems. Someone changes a security group in the console during an incident, and months later a rebuild silently removes the fix or reintroduces the problem. Prevent it with scheduled drift detection, a policy that flags unmanaged changes, and a habit of reconciling emergency changes into code.
• Secrets stored in source control are another frequent error. Scanning tools can detect many patterns, but the better prevention is to design applications to fetch credentials at runtime from a managed store and to rotate any credential that was ever committed, even if it was removed later.
• Missing tags and a single shared account make cost and access hard to manage. Enforce required tags through policy, split accounts by environment and function, and review the resulting structure periodically so that it still matches how teams work.
• Pipelines that deploy without a rollback path leave teams stuck when a release goes wrong. Each deployment should have a tested reverse procedure, whether that is redeploying the previous artifact, switching traffic back or restoring a database snapshot where the schema allows it. Note that some database changes cannot be reversed simply, so plan those with expand and contract steps.
• Overprovisioning wastes money and hides performance problems. Start from measured demand, use autoscaling where the workload suits it, and review instance sizes after a few weeks of real data.
• Alert fatigue reduces the value of monitoring. Alerts that page people for conditions nobody can act on train responders to ignore the pager. Tie paging alerts to user impact or to a clear required action, and send the rest to a dashboard or a ticket queue.
• Treating DevOps as a tooling purchase is a mistake that appears in many organizations. Tools support habits, and the habits are shared review, small changes, measured outcomes and clear ownership. Buying a platform without changing how teams plan and respond rarely produces the expected gains.

09Practical checklist

• Confirm the inventory of workloads, owners, data classes and recovery expectations is current before starting new work.
• Record account, region, tagging and naming decisions in architecture decision records and link them from the project.
• Keep all infrastructure and pipeline configuration in version control, with secrets referenced from a managed store.
• Require a preview of every infrastructure change and review deletions and permission changes with particular care.
• Run automated checks for policy, security baseline conformance, dependency vulnerabilities and tests before any promotion.
• Deploy progressively, define rollback triggers in advance and watch the agreed indicators during rollout.
• Test backups by restoring them on a schedule and record how long each restore took.
• Reconcile every manual change back into code within a set period and document the reason for the manual path.
• Review access rights, unused accounts and cost anomalies on a regular cycle with the owning teams.
• Confirm applicable legal and contractual obligations with compliance or legal staff before handling regulated data.

★Learning sources

• Micro Degree: Cloud Computing and DevOps Engineering
• Micro Degree: Data Analytics Applications
• Micro Degree: Azure Cloud Fundamentals
• Micro Degree: Google Cloud Platform Basics