Unit 5 - Practice Quiz

Cloud computing is the on-demand delivery of IT resources—including servers, storage, databases, networking, and software—over the Internet ('the cloud').

On-demand self-service is a core characteristic, allowing users to provision computing resources like server time and network storage as needed, automatically, without requiring human interaction with each service provider.

Services like Google Drive and Dropbox are popular cloud storage applications that allow users to store, synchronize, and access their files from any device over the internet.

SaaS stands for Software as a Service. It is a cloud service model where software applications are delivered over the internet, usually on a subscription basis, such as Microsoft 365 or Gmail.

A Private Cloud is a cloud computing environment dedicated to a single organization, providing greater control and privacy, whether managed internally or by a third party.

A hypervisor is software that creates and runs virtual machines. It allows one physical host computer to support multiple guest VMs by virtually sharing its resources, like memory and CPU.

IaaS provides the most basic level of cloud resources, such as virtual servers, storage, and networking. It is analogous to renting raw hardware components in the cloud.

AWS, Azure, and Google Cloud are the leading Public Cloud providers, offering their services to the general public over the internet on a pay-as-you-go basis.

A Cloud Architect is a strategic role that involves planning, designing, and overseeing the implementation of an organization's overall cloud computing strategy.

Docker is a leading platform for containerization, which involves packaging an application and all its dependencies into a standardized, isolated unit called a container.

The pay-as-you-go model is a key financial benefit of cloud computing, allowing users to pay only for the specific services they use, for as long as they use them, without long-term contracts.

PaaS provides a platform with tools to build, test, and deploy applications. The provider manages the underlying infrastructure, including servers and operating systems, allowing developers to focus on their code.

A Hybrid Cloud integrates a private cloud with one or more public cloud services, allowing data and applications to be shared between them to provide greater flexibility and deployment options.

The cloud provides vast and elastic resources on-demand, which is ideal for processing the large and variable datasets involved in big data analytics, without a large upfront investment.

A Virtual Machine (VM) is a virtual representation of a physical computer. It runs on a physical machine and has its own virtual CPU, memory, and storage, and is a foundational element of cloud computing.

Gmail is a complete software application delivered over the internet. Users do not manage the underlying infrastructure or platform; they simply use the software, which is the definition of SaaS.

A Community Cloud is a collaborative effort where infrastructure is shared between several organizations from a specific community with common concerns, such as security, compliance, or jurisdiction.

Kubernetes is a container orchestration tool. It automates the scaling, deployment, and management of applications that are packaged in lightweight, portable containers.

A Cloud Engineer or Administrator is a hands-on technical role responsible for implementing, monitoring, and maintaining the cloud environment to ensure it runs smoothly and efficiently.

With IaaS, the cloud provider manages the physical hardware, but the user is responsible for managing the operating system, middleware, and applications, giving them the highest level of control and flexibility among the main service models.

Rapid Elasticity is the ability to quickly and automatically scale computing resources up or down as needed. The scenario describes scaling out during peak hours and scaling in during off-peak hours, which is a perfect example of this characteristic.

PaaS provides a platform allowing customers to develop, run, and manage applications without the complexity of building and maintaining the infrastructure typically associated with developing an app. The cloud provider handles the OS, middleware, and runtime.

A Hybrid Cloud combines a private cloud (on-premises infrastructure) with a public cloud. This allows the institution to run the scalable, non-sensitive parts of its application in the public cloud while keeping critical, regulated data secure in their private cloud.

A Type 1 hypervisor (e.g., VMware ESXi, KVM) is installed directly on the physical server ('bare metal'), offering better performance and security, making it common in datacenters. A Type 2 hypervisor (e.g., VirtualBox, VMware Workstation) runs as an application within a host OS.

Infrastructure as Code (IaC) is the process of managing and provisioning computer data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools. Tools like Terraform and AWS CloudFormation are used for IaC.

A multi-cloud strategy involves using cloud services from more than one public cloud provider. This is often done to prevent vendor lock-in, increase resiliency, and take advantage of specialized services or better pricing from different providers.

Managed big data frameworks like EMR (which uses Hadoop and Spark) are specifically designed for processing and analyzing vast amounts of data in batch mode. They are ideal for complex, long-running jobs on unstructured data, unlike transactional databases or real-time streaming services.

A Cloud Architect is responsible for the high-level design of the cloud environment. They translate business requirements into a technical cloud strategy, making key decisions about services, security, and overall structure, which perfectly matches the described responsibilities.

Cloud-based Disaster Recovery allows organizations to avoid the massive capital expenditure (CapEx) and operational costs (OpEx) of owning and managing a secondary physical DR site. The pay-as-you-go model means they only pay for full compute capacity when a disaster actually occurs.

IaaS provides the most control, offering fundamental computing resources like virtual machines, storage, and networking. A 'lift and shift' migration requires this level of control to replicate the on-premises environment, including the OS and its specific configurations, in the cloud.

Unlike VMs, which virtualize hardware and require a full guest OS, containers virtualize the OS. They package an application and its dependencies but share the kernel of the host system. This results in a much smaller footprint, faster startup times, and greater efficiency, which is ideal for deploying many small, independent microservices.

Capital Expenditure (CapEx) refers to major, long-term purchases like physical servers. Operational Expenditure (OpEx) refers to ongoing, day-to-day costs like a monthly cloud bill. Cloud computing allows businesses to convert CapEx into OpEx, reducing the need for large initial investments.

Auto-Scaling (or autoscaling) is a cloud computing feature that automatically adjusts the amount of computational resources in a server farm—typically measured by the number of active server instances—based on the load. This scenario perfectly describes a scale-out policy based on a CPU metric.

A Community Cloud is a collaborative effort in which infrastructure is shared between several organizations from a specific community with common concerns (e.g., security, compliance, jurisdiction), whether managed internally or by a third party and hosted internally or externally.

A Cloud Administrator is focused on the implementation and operational management of the cloud environment. Their role is hands-on, dealing with the practical aspects of keeping the cloud services running smoothly, which aligns with the tasks of a traditional sysadmin.

SaaS delivers software applications over the Internet, on a subscription basis. The provider manages the application, data, and infrastructure. A web-based CRM like Salesforce is a classic example of SaaS, where the user simply consumes the end-product software.

For real-time fraud detection, the system must be able to ingest, process, and analyze data as it is generated with minimal delay (low latency). If processing is slow, fraudulent trades could be completed before they are detected. Services like AWS Kinesis or Google Cloud Dataflow are designed for this.

MBaaS, also known as Backend as a Service (BaaS), is a cloud service model that provides backend functionalities like user management, push notifications, and cloud storage as pre-built blocks, allowing mobile app developers to focus on the frontend user experience.

Data sovereignty is the concept that information which has been converted and stored in binary digital form is subject to the laws of the country in which it is located. This is a major consideration for companies operating in multiple countries with differing data privacy laws, like GDPR in Europe.

In the IaaS model, the cloud provider is responsible for the security of the cloud (physical hardware, networking, virtualization layer). The customer is responsible for security in the cloud. This includes securing the guest operating system, applications, network configurations, and identity and access management.

SR-IOV is a hardware specification that allows a single PCIe device, like a NIC, to appear as multiple separate physical devices. This enables guest VMs to bypass the hypervisor's virtual switch and gain direct, low-latency access to the NIC's resources. While Intel VT-x/AMD-V are fundamental for CPU virtualization and Nested Paging is for memory, SR-IOV specifically targets I/O performance bottlenecks, which is the core issue described. Memory ballooning is a memory management technique and is irrelevant to network I/O latency.

IaaS (e.g., EC2, Azure VMs) is the optimal choice here. The requirement for a 'custom-compiled runtime environment' and the team's 'strong sysadmin skills' make IaaS a natural fit, as it provides full control over the operating system and software stack. PaaS would be too restrictive for the custom runtime. FaaS is unsuitable for a monolithic application. CaaS is a viable alternative but often requires refactoring the application into containers, which might be a step too far for an initial migration of a legacy monolith. IaaS provides the necessary control for a 'lift-and-shift' migration while still offloading hardware management.

Data gravity is the concept that as a body of data grows, it becomes increasingly difficult and costly to move. In this scenario, the massive volume of raw patient data must be anonymized on-premises and then a significant subset transferred to the public cloud for analysis. The latency of the network link and the sheer bandwidth required to move terabytes or petabytes of data become the primary bottleneck and cost center. While identity management and VM provisioning are challenges, they are generally well-understood problems with established solutions. The physics of data transfer (gravity and latency) presents the most fundamental and difficult architectural hurdle.

This option describes a true GitOps workflow. By making the Git repository the single source of truth and automating application via a CI/CD pipeline, it proactively enforces the desired state. Combining this with strict Role-Based Access Control (RBAC) to prevent manual changes directly in the cloud console addresses the root cause of the drift. State locking prevents concurrent runs but doesn't stop manual changes. Running terraform plan is reactive, not proactive. Shell scripts are a less robust, custom-built solution compared to a proper GitOps pipeline.

The requirement for 'complex event processing' within a specific time window (windowed operations) and the need for low latency points directly to a stateful stream processing engine. Apache Flink is purpose-built for these tasks. A batch architecture (Redshift) or a serverless query engine (Athena) cannot provide real-time, low-latency results. A classic Lambda architecture could work, but it's often more complex to manage than a dedicated stream processing framework like Flink, which is designed to handle stateful computations over time windows natively and efficiently.

In a Community Cloud, the primary challenge is not technical but organizational and related to governance. Each member bank has its own security posture, risk tolerance, and interpretation of regulations. Creating a single, unified security and compliance framework that is robust enough for the most stringent member, yet flexible enough for others, and then ensuring continuous adherence and auditing across all members, is a massive governance hurdle. The other options (cost, APIs, networking) are significant technical challenges, but the multi-party governance of security and compliance is the most complex and defining challenge of a Community Cloud in a regulated industry.

The CAP theorem states that in the presence of a network partition (P), a system must choose between Consistency (C) and Availability (A). For a globally distributed system built on the public internet and across multiple geographic regions, network partitions are not a possibility but an inevitability. Therefore, any practical system must tolerate partitions. This forces a choice between C and A. Most large-scale cloud database services prioritize Availability (the system must always respond to requests) over strong Consistency, opting for models like 'eventual consistency'. Sacrificing P is not a realistic option for a distributed system. Sacrificing A would mean the service becomes unavailable during a partition, which is unacceptable for many modern applications.

Statistical multiplexing is the key concept. A single enterprise's workload often has predictable peaks and troughs. A cloud provider serves thousands of customers whose workloads are largely non-correlated (e.g., a retail website's peak shopping hours are different from a financial firm's end-of-day batch processing). By pooling resources to serve these varied workloads, the provider can smooth out the overall demand, leading to much higher and more efficient server utilization than any single customer could achieve on their own. This high utilization directly translates to lower costs per unit of compute, which is the essence of economies of scale in the cloud. The other options are NIST characteristics of cloud but do not explain the core economic engine as directly.

Nested virtualization performance hinges on reducing the overhead of memory address translation. EPT/RVI are hardware features that allow the CPU's Memory Management Unit (MMU) to handle guest-to-physical address translation directly, avoiding costly exits to the hypervisor. In a nested scenario, this is even more critical. The physical CPU must support this, and crucially, the L0 hypervisor must be configured to pass through this capability to the L1 hypervisor. This allows the L1 hypervisor to efficiently manage the L2 guest's memory, minimizing the performance penalty of the two-level translation.

This is a strategic architectural decision with significant financial implications. The Cloud Architect is responsible for the overall design, ensuring it meets requirements for scalability, resilience, and maintainability, and calculating the Total Cost of Ownership (TCO). The FinOps Specialist is a newer role focused specifically on the financial management of cloud services. They would build detailed cost models for both scenarios, considering not just the direct service costs but also operational overhead, data transfer fees, and potential for cost optimization. While other roles provide input, the final decision balancing technical architecture and financial impact rests primarily with the Architect and FinOps roles.

This is a subtle distinction. While FaaS meets the 'pay for execution' and 'low overhead' goals, it often requires coding to a vendor-specific interface, hindering portability. Serverless Containers (a form of CaaS) provide the same serverless benefits (no server management, pay-per-use) but operate on standard OCI container images. This allows the team to package their application with any language or framework, completely avoiding vendor-specific function signatures. It accommodates both short-lived and long-running tasks, making it the most flexible and portable serverless option for their needs.

While an Ingress Controller manages traffic entering the cluster (North-South traffic), a service mesh is designed to manage traffic between services within the cluster (East-West traffic). Features like mTLS, advanced traffic shifting for canary/A/B testing, and detailed observability are the core functionalities of a service mesh. It operates by injecting a sidecar proxy next to each service, which intercepts all network traffic and enforces policies, keeping this complex logic out of the application itself. CNI plugins handle basic pod-to-pod networking, and CI/CD tools manage deployment, but not the runtime traffic management.

The 'lowest common denominator' approach creates portability but at a high cost: it prevents the company from using powerful, differentiating services like Google's BigQuery, AWS's Lambda, or Azure's AI services. These higher-level services can provide significant competitive advantages by reducing development time, lowering operational burden, and offering unique capabilities. By restricting themselves to the basics, the company forgoes much of the innovation and value proposition of the cloud, turning it into a mere commodity VM provider. While cost, IAM, and networking are challenges, the opportunity cost of not using high-value services is the most significant strategic risk.

The key driver here is minimizing complexity and avoiding divergence. The Lambda architecture's primary drawback is that it requires maintaining two separate codebases for the batch and speed layers, which can easily lead to subtle bugs where the results from the two paths differ. The Kappa architecture solves this by using a single stream-processing engine (like Flink or Spark Streaming). For reprocessing, the historical data is simply replayed from a message log (like Kafka) into the same stream processing code. This unifies the logic, simplifies maintenance, and guarantees consistent results, directly addressing the team's stated priorities.

Standard CDN features are for caching static content. The requirement to run custom, complex logic (like a database lookup for authentication) on every request at the edge, before the cache is checked or the origin is contacted, is the exact use case for edge computing. Services like Lambda@Edge or Cloudflare Workers allow developers to deploy serverless functions that execute within the CDN's global network of Points of Presence (PoPs). This enables powerful request manipulation, custom authentication, A/B testing, and more, directly at the edge, minimizing latency for the end-user.

The core essence of a 'cloud' (public or private) is not just virtualization, but the operating model. Traditional private clouds often still rely on IT teams fulfilling tickets (imperative: 'build me a server with these specs'). A modern, cloud-native private cloud (e.g., using OpenStack, or Kubernetes with platforms like Rancher) exposes cloud-like, API-driven, self-service portals. Developers can declaratively define the desired state of their application ('I need a database with this configuration'), and the platform automates the provisioning and management. This shift in operating model is the most significant change, enabling agility and DevOps practices on-premises.

This question probes a deep, conceptual difference. Electricity is a fungible commodity; a kilowatt-hour is the same regardless of the provider. Switching electric companies is a purely contractual change. In contrast, cloud services are 'sticky'. An application built on AWS using services like DynamoDB, Lambda, and S3 cannot be easily moved to Azure or GCP. The data stored in these services has 'gravity', and the application logic is tightly coupled to the provider's specific APIs. This lack of fungibility and the high cost of switching providers due to state and data gravity is a fundamental way cloud computing diverges from the simple utility analogy.

This question targets a key transition point in the Shared Responsibility Model. In IaaS, the customer provisions a virtual machine and is fully responsible for the guest OS, including security patching, maintenance, and configuration. In a PaaS model (e.g., AWS Elastic Beanstalk, Azure App Service), the provider manages the entire underlying platform, which includes the operating system, runtime, and middleware. Therefore, the responsibility for patching the OS for vulnerabilities like Meltdown or Heartbleed shifts from the customer (in IaaS) to the provider (in PaaS). The customer is still responsible for their application code and data access (options A and B), and physical security (D) is always the provider's job.

This solution addresses both speed and security. PXE booting a standard OS image is slow. Using containers or hypervisors is not 'bare-metal'. The most robust approach is to boot a minimal, stateless OS entirely into RAM for provisioning. When a tenant is finished, the server is rebooted, wiping the OS state. Crucially, an out-of-band Baseboard Management Controller (BMC) can then trigger a certified, cryptographically secure erasure of the local SSDs/HDDs to guarantee no data remnants remain for the next tenant. This combination provides the speed of a reboot with the security of a verified wipe, which is essential for a multi-tenant bare-metal offering.

Policy-as-code tools work by evaluating the intent of the code, not by changing the behavior of the underlying tool (Terraform). The terraform plan command will generate a valid execution plan, as the Terraform syntax is correct. However, the CI/CD pipeline should be designed with a separate step after the plan. This step converts the plan to JSON (terraform show -json .tfplan) and feeds it to OPA. OPA evaluates this JSON against the policy, detects the violation (missing encryption), and returns a failing exit code. This causes the CI/CD pipeline to fail, thus preventing the non-compliant infrastructure from ever being applied.