1. Cloud Computing and DevOps FoundationsIntroduction and ContextCloud platforms and DevOps have become central to the design, delivery, and operation of contemporary digital services. Yet neither cloud computing nor DevOps is simply a product, tool, or fashionable label. Cloud computing represents a transformation in how computing resources are provisioned, accessed, measured, and governed. DevOps represents a transformation in how software is developed, tested, released, operated, and improved. Their combination enables organizations to deliver software rapidly while maintaining reliability, security, and economic discipline. For a postgraduate student, the important question is not merely what AWS, Microsoft Azure, or Google Cloud can do. The deeper question is how organizational goals, system architecture, engineering practices, operating models, and governance interact. A cloud service may provide technically impressive capabilities, but poor architecture, unclear ownership, weak security, or ineffective collaboration can still produce failure. Similarly, DevOps tools cannot compensate for a fragmented value stream or incentives that reward local optimization rather than customer outcomes. This chapter establishes the conceptual foundation for the subject. It explains the characteristics and models of cloud computing, the role of virtualization and distributed systems, the principles of DevOps and the CALMS framework, value-stream thinking, the relationship between Agile and DevOps, and the shared-responsibility model used by cloud providers. These ideas provide the vocabulary and analytical perspective required for later study of cloud architecture, infrastructure automation, containers, continuous delivery, observability, security, and platform engineering. Learning ObjectivesAfter studying this chapter, students should be able to: 1. Explain the defining characteristics of cloud computing and distinguish major service and deployment models. 2. Describe how virtualization, abstraction, and distributed systems support cloud platforms. 3. Interpret DevOps as an organizational and technical operating model rather than merely a collection of tools. 4. Apply the CALMS framework and value-stream concepts to software delivery situations. 5. Explain the relationship between Agile methods, continuous delivery, and DevOps. 6. Analyze the shared-responsibility model across infrastructure, platform, and software services. 7. Identify operational, security, financial, governance, and organizational risks in cloud and DevOps adoption. 8. Evaluate practical and managerial decisions using reliability, delivery performance, customer value, and risk as criteria. From Owned Infrastructure to Programmable ServicesTraditional information technology commonly relied on capital-intensive infrastructure owned or leased by an organization. Capacity planning was performed months before demand occurred. Servers were purchased, installed in data centers, and configured by specialized teams. If demand exceeded capacity, obtaining additional resources could take weeks. If demand was lower than expected, the organization still paid for idle equipment. Cloud computing changes this economic and operational relationship. Computing resources are made available as services that can be provisioned through portals, command-line interfaces, application programming interfaces, and infrastructure-as-code systems. The consumer can request processing, storage, networking, databases, analytics, or machine-learning capabilities without managing every physical component. Resources may be elastic, metered, and available across geographic regions. The change is not simply a migration from a company data center to a provider data center. Cloud adoption introduces new responsibilities. Teams must understand identity and access management, resource configuration, network boundaries, data residency, availability zones, service limits, cost behavior, and provider dependencies. The organization exchanges some forms of capital expenditure and physical maintenance for consumption-based cost, architectural complexity, and a continuing need for governance. What Makes Computing “Cloud”?The National Institute of Standards and Technology identifies five widely used essential characteristics of cloud computing. These characteristics provide a useful analytical definition, although commercial platforms may implement them differently. On-demand self-service means that a consumer can provision computing capabilities automatically, without requiring direct human intervention from the service provider. A development team might create a database instance through an approved workflow rather than submit a manual infrastructure request. Broad network access means that services are accessible through standard network mechanisms and can be used by varied client platforms, such as browsers, mobile applications, command-line tools, and enterprise systems. Resource pooling means that provider resources serve multiple consumers through a multitenant model. Physical and virtual resources are dynamically assigned and reassigned according to demand. Consumers generally do not know the exact physical location of resources, although compliance requirements may restrict geographic placement. Rapid elasticity means that resources can be scaled outward or inward quickly. To users, capacity may appear almost unlimited, although practical limits, quotas, cost, and service dependencies remain important. Measured service means that usage is monitored, controlled, and reported. Consumption may be measured in requests, storage capacity, CPU time, data transfer, or other units. Metering supports billing, capacity analysis, chargeback, and optimization. These characteristics distinguish cloud computing from simple hosting. A privately operated server may be remotely accessible, but it does not automatically provide elastic, pooled, self-service, and measured capabilities. Conversely, not every service labelled “cloud” delivers all characteristics equally. Critical evaluation is therefore required when assessing a provider or architecture. Service Models: Where Responsibility MovesService models describe the level at which a provider supplies computing capability and the level at which the customer retains control. The three classical models are infrastructure as a service, platform as a service, and software as a service. Modern providers also offer specialized forms such as function as a service, database as a service, and machine learning as a service. Infrastructure as a ServiceInfrastructure as a service (IaaS) provides fundamental resources such as virtual machines, block storage, virtual networks, load balancers, and firewalls. The provider manages physical facilities, hardware, and core virtualization. The customer typically manages the operating system, installed software, configurations, identities, data, and applications. IaaS offers flexibility and is useful when an organization needs operating-system control, custom networking, or migration compatibility. It also leaves substantial operational work with the customer. A virtual machine still requires patching, monitoring, backup, hardening, capacity management, and incident response. Moving a workload to IaaS does not eliminate these responsibilities. Platform as a ServicePlatform as a service (PaaS) provides a managed environment for developing and running applications. The provider may manage the operating system, runtime, patching, scaling mechanisms, and much of the underlying infrastructure. The customer focuses more directly on application code, configuration, data, and access control. PaaS can improve developer productivity and reduce undifferentiated operational work. However, it may constrain runtime choices, networking patterns, deployment methods, or portability. The relevant decision is not whether PaaS is universally better than IaaS, but whether the reduction in operational burden justifies the platform’s constraints and possible dependency. Software as a ServiceSoftware as a service (SaaS) delivers a complete application to end users, usually through a browser or an API. The provider manages nearly all technical layers, while the customer remains responsible for user administration, data governance, configuration, access policies, and appropriate use. SaaS shifts responsibility but does not remove accountability. An organization can still suffer a data breach because administrators assign excessive privileges, fail to configure retention policies, or connect the SaaS application insecurely to other systems. Serverless and Managed ServicesServerless computing allows customers to run application logic without managing persistent servers. In function-based services, code is invoked by events and the customer pays according to execution or related consumption. Serverless does not mean that servers do not exist; it means that server management is abstracted from the customer. Managed databases, queues, object storage, identity services, and analytics platforms similarly abstract infrastructure operations. They can accelerate delivery, but they require careful attention to service limits, performance characteristics, pricing, regional availability, data export, and provider-specific interfaces. Deployment Models and Architectural ChoiceA public cloud is operated by a provider and made available to multiple customers. It offers broad service variety, elastic capacity, and economies of scale. A private cloud is dedicated to one organization and may be operated internally or by a third party. It can support particular control, isolation, or regulatory requirements, but it may not achieve the same breadth or economic efficiency as a large public provider. A hybrid cloud combines private infrastructure with public cloud services. It is often used when existing systems must remain in place while selected workloads move to public services. Hybrid environments introduce integration, identity, networking, monitoring, and data-movement complexity. A multi-cloud strategy uses services from more than one public cloud provider. It may reduce concentration risk or exploit specialized capabilities, but it can increase skills requirements, operational inconsistency, and architectural complexity. Multi-cloud should be justified by a clear business, regulatory, resilience, or technical objective rather than treated as an automatic sign of maturity. Deployment models are architectural choices, not ideological positions. Decision-makers should evaluate workload sensitivity, latency, resilience, skills, total cost, portability, legal requirements, service maturity, and organizational capability. Virtualization: The Abstraction Beneath the ServiceVirtualization separates a logical computing environment from the physical hardware on which it runs. A hypervisor allocates processor, memory, storage, and networking resources to virtual machines. Each virtual machine can run an operating system and applications as though it were an independent computer. Virtualization improves utilization, isolation, provisioning speed, and workload mobility. It allows a provider to host many customers on shared physical systems while presenting logically separate environments. However, virtualization is not perfect isolation. Vulnerabilities in hypervisors, misconfigured networks, weak credentials, and side-channel risks can threaten security. Performance can also be affected by contention for shared resources. Containers provide a lighter abstraction. A container packages application code and dependencies while sharing the host operating system kernel. Container images support consistency across development, testing, and production, but containers require orchestration, image governance, runtime security, resource limits, and persistent-data strategies. Virtual machines and containers are complementary rather than mutually exclusive: containers often run inside virtual machines in public clouds. Abstraction creates both value and risk. It hides unnecessary implementation detail, allowing users to work at a higher level, but it can also hide failure modes. Cloud professionals must understand enough of the underlying layers to diagnose latency, resource exhaustion, networking errors, and security incidents. Distributed Systems as the Operating RealityA distributed system consists of components that communicate across a network and cooperate to provide a service. Cloud applications are usually distributed: a web front end may call application services, databases, queues, identity systems, storage services, and external APIs located in different failure domains. Distribution provides scalability and resilience, but it introduces uncertainty. Networks can delay, duplicate, reorder, or lose messages. Services can fail independently. Clocks may disagree. A transaction spanning several systems may not behave like a transaction within one database. These conditions make cloud engineering fundamentally different from designing for a single server. Important distributed-systems concepts include latency, the time required for communication; availability, the probability that a service is accessible when needed; consistency, the degree to which different readers observe the same data; and partition tolerance, the ability to continue operating when communication between components is disrupted. The CAP perspective highlights trade-offs under network partition; it does not mean that systems permanently choose only two characteristics in every circumstance. Resilient systems use techniques such as redundancy, replication, timeouts, retries with backoff, circuit breakers, queues, health checks, graceful degradation, and tested recovery procedures. These mechanisms can also create new risks. Unbounded retries may amplify an outage, replication may increase cost, and asynchronous processing may complicate user expectations. Reliability is therefore a design property requiring explicit trade-offs. DevOps as an Operating ModelDevOps is a set of cultural, organizational, and technical practices intended to improve the flow of value from idea to running software. It brings development and operations into a system of shared responsibility and feedback. Security, quality engineering, product management, compliance, and business stakeholders are increasingly included in this collaborative model. DevOps responds to a traditional organizational problem: development teams may be rewarded for delivering change, while operations teams may be rewarded for stability. When these goals are separated into handoffs, each group can optimize locally while the customer experiences delay, defects, or unreliable service. DevOps seeks to align incentives around customer outcomes and system performance. DevOps is not synonymous with continuous integration, containers, or a particular toolchain. A team can use sophisticated tools while retaining manual approvals, fragile deployments, poor testing, and adversarial relationships. Conversely, a small team can practice DevOps with simple automation if it owns its service, receives rapid feedback, and improves continuously. Core DevOps ideas include cross-functional ownership, automation of repeatable work, small and reversible changes, continuous feedback, infrastructure treated as code, observable systems, blameless learning from incidents, and the integration of security and compliance into delivery processes. CALMS and the Logic of TransformationThe CALMS framework provides a useful lens for evaluating DevOps capability. Its elements are Culture, Automation, Lean, Measurement, and Sharing. Culture concerns trust, collaboration, learning, shared ownership, and the removal of destructive incentives. A culture of blame encourages concealment; a learning culture encourages reporting and improvement. Culture cannot be created by slogans alone. It is expressed through budgeting, leadership behavior, team boundaries, promotion criteria, and responses to failure. Automation reduces manual effort and variation in building, testing, provisioning, deploying, securing, and operating systems. Effective automation is version-controlled, testable, observable, and designed with appropriate safeguards. Automating a poorly understood process can reproduce errors faster, so process clarity must precede or accompany automation. Lean focuses on maximizing customer value while reducing waste, delay, rework, excess inventory, unnecessary handoffs, and partially completed work. Lean thinking does not mean simply asking employees to work faster. It means improving the system that produces outcomes. Measurement makes performance and outcomes visible. Useful measures include deployment frequency, lead time for changes, change failure rate, time to restore service, availability, error-budget consumption, security findings, cost per transaction, and customer-impact indicators. Metrics should support learning rather than become targets that encourage manipulation. Sharing promotes transparency of knowledge, system status, operational information, documentation, reusable patterns, and lessons from incidents. Sharing reduces dependence on isolated experts and enables organizational learning. CALMS is not a maturity checklist in which every element is completed once. The elements reinforce one another. Automation without culture may produce resistance; measurement without trust may produce gaming; lean methods without sharing may optimize one team at the expense of the whole value stream. Value-Stream Thinking and FlowA value stream is the sequence of activities required to deliver a product or service to a customer. In software, it may begin with a customer need, proceed through product discovery, coding, review, testing, security validation, deployment, operation, and feedback. Value-stream thinking examines the complete path rather than treating each department as an independent productivity center. A value-stream map can identify queues, wait time, rework, approval bottlenecks, duplicated testing, unstable environments, and dependencies between teams. A frequent discovery is that active work takes hours while waiting takes weeks. Increasing individual team utilization may worsen the overall problem by creating more queues and work in progress. Lean flow is supported by limiting work in progress, reducing batch size, making bottlenecks visible, shortening feedback cycles, and improving the reliability of the delivery system. In software, small changes are generally easier to test, review, deploy, and recover than large releases. This does not imply that every change is risk-free; it means that risk can be managed in smaller units. Value-stream analysis should include security and governance activities. If compliance review occurs only at the end of a release, it becomes a bottleneck. Policy-as-code, automated evidence collection, and continuous controls can move assurance closer to the work while preserving accountability. Agile, Continuous Delivery, and DevOpsAgile methods emphasize iterative delivery, customer collaboration, adaptation to changing requirements, and working software. Agile improves the process of deciding and building what should be delivered. DevOps extends the concern into deployment, operation, reliability, security, and feedback from real use. The relationship is complementary. Agile teams may produce increments frequently, but if releases depend on a separate operations queue, value still accumulates in the delivery pipeline. DevOps addresses this gap by treating build, test, release, and operation as connected activities. Continuous integration keeps changes integrated and tested. Continuous delivery keeps software in a releasable state through automated validation and deployment preparation. Continuous deployment automatically releases qualifying changes, where the organization accepts the associated risk and has suitable controls. Agile ceremonies alone do not create DevOps. A team may conduct short iterations while retaining manual infrastructure provisioning and infrequent releases. Conversely, automation without customer-oriented planning can accelerate delivery of the wrong product. Effective organizations connect product discovery, engineering, operations, security, and customer feedback in one learning loop. The Shared-Responsibility ModelCloud security and operations are shared between the provider and the customer. The provider is responsible for the security of the cloud: physical facilities, hardware, foundational networking, and, depending on the service, parts of the virtualization and managed software stack. The customer is responsible for security in the cloud: identities, data, permissions, configurations, workloads, and usage. The boundary changes with the service model. In IaaS, the customer normally patches guest operating systems and secures applications. In PaaS, the provider manages more of the runtime, while the customer still manages code, data, identities, and configuration. In SaaS, the provider manages the application platform, but the customer remains responsible for access governance, data classification, user behavior, and configuration. The shared-responsibility model is not a transfer of accountability to the provider. Customers must understand provider documentation, contractual commitments, regional limitations, audit reports, service-level agreements, and incident-notification arrangements. They must also implement least privilege, multifactor authentication, encryption appropriate to the data, logging, backup and recovery, vulnerability management, secure configuration, and tested incident response. A useful practice is to create a responsibility matrix for every important service. The matrix should identify who owns identity, patching, encryption keys, backups, monitoring, incident response, regulatory evidence, availability decisions, and data deletion. Ambiguous ownership is itself a risk. Practical Applications Across Cloud and DevOpsIn application delivery, a team can use a source repository, automated build pipeline, unit and integration tests, security scanning, artifact storage, infrastructure-as-code, and progressive deployment. A canary release exposes a change to a small proportion of users before wider rollout. Feature flags allow functionality to be enabled or disabled independently of deployment, although unused flags create maintenance and testing debt. In operations, observability combines logs, metrics, traces, events, and meaningful service-level indicators. Monitoring asks whether known conditions are present; observability supports investigation of unfamiliar conditions. Service-level objectives express target reliability, while an error budget represents the amount of unreliability considered acceptable within that objective. When the budget is exhausted, an organization may reduce change velocity and prioritize reliability work. In governance, policy-as-code can automatically assess whether resources have approved regions, encryption, network restrictions, tags, backup policies, or identity controls. Automated governance must still allow exceptions through documented, time-bound, and accountable processes. Overly rigid controls may obstruct legitimate innovation; overly weak controls may create unacceptable exposure. In financial management, cloud cost becomes an engineering and managerial concern. Tagging, budgets, anomaly detection, rightsizing, scheduling, storage lifecycle policies, and architectural review can control consumption. Cost optimization must be balanced against availability, performance, security, and staff productivity. The cheapest design is not necessarily the most economical if it causes outages or excessive operational effort. Illustrative Case: A Retail Platform’s Cloud and DevOps TransitionBackgroundThe following is an illustrative case. Meridian Retail, a fictional online retailer, operated a seasonal commerce platform on company-owned servers. Development released software every six weeks. Operations performed production deployments manually during late-night maintenance windows. The organization experienced slow releases, inconsistent environments, and severe pressure during seasonal sales events. Situation and ProblemBusiness leaders wanted frequent promotional changes and improved customer experience. Operations was concerned that faster releases would increase outages. Security reviews occurred near the end of each release and frequently caused delay. The company decided to adopt public cloud services and DevOps practices, initially moving the product catalogue and order-management workloads. AnalysisA value-stream review showed that coding was not the principal source of delay. The largest queues occurred during environment provisioning, security approval, integration testing, and the operations deployment handoff. The review also found that no single team owned production outcomes. Developers lacked visibility into runtime failures, while operations lacked knowledge of application changes. The architectural analysis identified different workload needs. Product images were suitable for object storage and content delivery. The catalogue required a managed database and caching. Order processing required stronger consistency and carefully designed failure handling. A simple “move every server” strategy would not address these differences. Approach and StrategyMeridian created a cross-functional product team containing developers, operations engineers, security specialists, and a product owner. The team defined service-level objectives for catalogue availability and order-processing success. It introduced source-controlled infrastructure definitions, automated testing, dependency and container-image scanning, and a deployment pipeline. The team adopted a gradual migration. Stateless catalogue services were deployed across multiple availability zones. Database backups and restoration were tested rather than assumed. A canary release strategy reduced exposure during high-risk changes. Centralized logs, metrics, and traces improved diagnosis. Security controls included multifactor authentication, least-privilege roles, encryption, network segmentation, and automated configuration checks. Governance was redesigned rather than removed. Security policies were expressed as automated checks, while exceptions required an owner, justification, expiry date, and review. Cost dashboards showed spending by product and environment. Developers participated in incident reviews and received production feedback. OutcomeThe transition reduced the size of releases and made deployment more predictable. The organization could scale selected services during demand peaks without purchasing permanent capacity. Security review became more continuous, and operational incidents generated improvement work rather than blame. The case did not eliminate all risk: managed-service dependency, data-transfer cost, and the need for specialized cloud skills remained. Learning PointsSeveral conclusions follow. First, cloud migration does not automatically create agility; process and ownership must change. Second, service selection should follow workload characteristics rather than fashion. Third, reliability and security need explicit objectives and automation. Fourth, DevOps is a socio-technical change involving incentives, team design, feedback, and architecture. Finally, migration should be treated as an ongoing capability-building program, not a one-time infrastructure project. Challenges, Risks, and Common MistakesCloud and DevOps programs frequently fail through predictable errors. “Lift and shift” migration may reproduce inefficient architectures and operating procedures. Excessive dependence on manual console changes creates configuration drift and weak auditability. Over-permissioned identities increase the impact of compromised credentials. Publicly exposed storage or management interfaces can result from simple configuration mistakes. Other risks include uncontrolled resource consumption, inadequate backup testing, dependence on one provider or proprietary service, untested recovery assumptions, lack of observability, and alert overload. Organizations may also adopt DevOps terminology without changing team boundaries or incentives. Measuring only deployment frequency can encourage unsafe releases; measuring only uptime can discourage valuable change. Technical debt is not limited to source code. Pipeline debt, infrastructure debt, monitoring debt, documentation debt, and security debt all increase future delivery cost. Leaders should make such debt visible and allocate capacity for reduction. Ethical, Governance, and Professional ConsiderationsCloud professionals handle data, access privileges, and systems that may affect individuals and institutions. Ethical practice requires confidentiality, integrity, availability, proportional data collection, and respect for legal and organizational obligations. Decisions about data location, retention, automated decision-making, and third-party processing require more than technical convenience. Governance should establish accountability for architecture, cost, security, privacy, resilience, and supplier management. Regulatory requirements may concern financial records, health information, personal data, critical infrastructure, or cross-border transfer. Compliance is not equivalent to security, and a provider’s certification does not prove that a customer’s configuration is compliant. Incident response should preserve evidence, protect affected people, communicate accurately, and avoid concealment. Blameless post-incident review does not mean absence of accountability; it means examining system conditions and decisions without using personal blame as the primary learning mechanism. Current Developments and Emerging DirectionsCloud platforms increasingly provide managed artificial intelligence, event-driven integration, confidential computing, edge services, and specialized accelerators. These capabilities can shorten development time but introduce new concerns involving data governance, model risk, explainability, cost predictability, and supply-chain security. Platform engineering is emerging as an approach in which an internal platform provides approved, reusable paths for deploying and operating services. A well-designed platform reduces cognitive load without hiding essential responsibility. It should offer secure defaults, self-service interfaces, documentation, and escape paths for legitimate needs. Policy-as-code, software supply-chain security, software bills of materials, zero-trust architectures, and sustainability-aware engineering are also gaining importance. Organizations are increasingly evaluating carbon impact, energy use, hardware lifecycle, and regional workload placement alongside financial cost and performance. These developments reinforce a central principle: technology changes, but sound decision-making still depends on clear ownership, feedback, risk analysis, and alignment between technical work and organizational value. Best-Practice GuidanceA strong foundation for cloud and DevOps includes the following practices: - Define ownership for every production service, including security, cost, reliability, and recovery.
- Use identity-centric security, least privilege, multifactor authentication, and secure defaults.
- Manage infrastructure and configuration through version-controlled, reviewable automation.
- Design for failure using redundancy, timeouts, controlled retries, backup, and tested restoration.
- Build continuous testing and security validation into delivery pipelines.
- Measure both delivery performance and customer outcomes; avoid weaponizing metrics.
- Use small, reversible changes and progressive delivery where appropriate.
- Map the value stream to expose queues, handoffs, rework, and bottlenecks.
- Treat incidents as sources of system learning while preserving accountability.
- Review architecture, cost, compliance, and provider dependency continuously rather than only during migration.
Chapter SummaryCloud computing provides pooled, network-accessible, elastic, self-service, and measured computing capabilities. IaaS, PaaS, SaaS, serverless, and managed services move responsibility between provider and customer in different ways. Public, private, hybrid, and multi-cloud deployments represent choices shaped by workload, risk, cost, capability, and governance. Virtualization and containers provide abstraction, while distributed systems introduce latency, partial failure, consistency challenges, and the need for resilience engineering. DevOps connects development, operations, security, and business concerns through shared ownership, automation, feedback, and continuous improvement. The CALMS framework explains the mutually reinforcing roles of Culture, Automation, Lean, Measurement, and Sharing. Value-stream thinking focuses attention on end-to-end customer value rather than departmental activity. Agile supports iterative product development, while DevOps extends the feedback loop through delivery and operation. The shared-responsibility model clarifies that cloud providers secure the underlying cloud and customers secure their use of it. Successful adoption therefore requires technical competence, organizational change, governance, ethical judgment, and continuous learning. Key TermsCloud computing: Delivery of computing resources as network-accessible, scalable, and measured services. Elasticity: The ability to increase or decrease resources in response to changing demand. Resource pooling: Sharing provider resources among customers through a multitenant model. IaaS: A cloud model providing virtualized infrastructure resources such as compute, storage, and networking. PaaS: A managed application platform that abstracts much of the infrastructure and runtime. SaaS: A complete software application delivered and operated by a provider. Serverless computing: Execution model in which the provider manages server infrastructure for the consumer. Virtualization: Abstraction of logical computing environments from physical hardware. Container: An isolated application package that shares the host operating-system kernel. Distributed system: A system whose components communicate across a network to provide a coordinated service. Availability: The degree to which a service is accessible and functioning when required. Observability: The ability to understand internal system behavior from externally emitted signals. DevOps: A socio-technical approach integrating development, operations, security, and feedback. Continuous integration: Frequent integration and automated validation of code changes. Continuous delivery: Keeping software in a tested and deployable state. CALMS: A DevOps framework comprising Culture, Automation, Lean, Measurement, and Sharing. Value stream: The end-to-end activities through which an idea becomes customer value. Error budget: The acceptable amount of unreliability implied by a service-level objective. Shared responsibility: The allocation of cloud security and operational duties between provider and customer. Infrastructure as code: Managing infrastructure through version-controlled, machine-readable definitions. Review QuestionsShort Answer Questions1. What are the five essential characteristics commonly associated with cloud computing? 2. How does PaaS differ from IaaS in the distribution of operational responsibility? 3. Why does virtualization improve cloud resource utilization? 4. What is meant by shared responsibility in cloud security? 5. Identify the five elements of the CALMS framework. Long Answer Questions1. Explain the major cloud service and deployment models, including their principal benefits, limitations, and responsibility implications. 2. Discuss how distributed-system characteristics affect the design of reliable cloud applications. 3. Explain DevOps as an organizational operating model and distinguish it from the mere adoption of automation tools. 4. Analyze the relationship among Agile, continuous integration, continuous delivery, and DevOps. 5. Describe how value-stream thinking can improve software delivery and governance in a large organization. Analytical / Application Questions1. A company moves its applications to IaaS but continues manual provisioning, infrequent releases, and separate development and operations teams. Use the concepts in this chapter to explain why the expected agility has not appeared and recommend improvements. 2. A team wants to use a managed database to reduce operational effort, but the application has strict data-residency and portability requirements. What factors should guide the decision? 3. During a major incident, an automated retry mechanism generates additional traffic and worsens the outage. Analyze this failure using distributed-systems and DevOps principles, and propose preventive practices. 22. Multiple Choice Questions with AnswersQuestion 1Which characteristic most directly enables a consumer to provision cloud resources without waiting for provider staff to perform the request manually? A. Measured service B. On-demand self-service C. Resource pooling D. Broad network access Correct Answer: B. On-demand self-service Question 2An organization manages its virtual machines, guest operating systems, and applications while the provider manages physical servers and virtualization. Which service model is this? A. SaaS B. PaaS C. IaaS D. Function as a service Correct Answer: C. IaaS Question 3Why can a multi-cloud strategy increase organizational complexity? A. It prevents the use of automation B. It requires all workloads to run on private infrastructure C. It may require different skills, controls, and operational practices across providers D. It eliminates provider dependency entirely Correct Answer: C. It may require different skills, controls, and operational practices across providers Question 4Which CALMS element is most directly concerned with reducing queues, handoffs, rework, and excess work in progress? A. Lean B. Sharing C. Measurement D. Culture Correct Answer: A. Lean Question 5A team deploys a change to five percent of users, examines service behavior, and then expands deployment gradually. What practice is being used? A. Canary or progressive delivery B. Resource pooling C. Cold migration D. Manual capacity planning Correct Answer: A. Canary or progressive delivery Question 6In a typical cloud shared-responsibility model, which activity generally remains the customer’s responsibility even when using SaaS? A. Maintaining the provider’s physical data center B. Replacing failed provider hardware C. Managing user access and appropriate data configuration D. Patching the provider’s hypervisor Correct Answer: C. Managing user access and appropriate data configuration Question 7What is the principal purpose of value-stream mapping in a DevOps transformation? A. To measure only individual developer productivity B. To identify end-to-end delays, queues, dependencies, and rework affecting customer value C. To replace all governance controls with automation D. To select a single cloud provider Correct Answer: B. To identify end-to-end delays, queues, dependencies, and rework affecting customer value Question 8Which statement best distinguishes continuous delivery from continuous deployment? A. Continuous delivery keeps software deployable, while continuous deployment automatically releases qualifying changes B. Continuous delivery applies only to infrastructure, while continuous deployment applies only to applications C. Continuous delivery removes testing, while continuous deployment adds testing D. There is no meaningful distinction between them Correct Answer: A. Continuous delivery keeps software deployable, while continuous deployment automatically releases qualifying changes Question 9A cloud application retries every failed request immediately and without a limit. During a partial outage, traffic increases and the outage worsens. Which design principle would most directly address this problem? A. Use controlled retries with backoff and limits B. Increase the number of manual approvals C. Remove all monitoring D. Store all data on one server Correct Answer: A. Use controlled retries with backoff and limits Question 10Which statement best reflects the relationship between Agile and DevOps? A. Agile replaces the need for operations practices B. DevOps is only a project-management method for Agile teams C. Agile supports iterative product development, while DevOps extends collaboration and feedback through delivery and operation D. The two approaches are incompatible because Agile avoids automation Correct Answer: C. Agile supports iterative product development, while DevOps extends collaboration and feedback through delivery and operation
|
