A cloud architect reviews an AWS bill with an engineering manager: "We're paying on-demand rate for EC2 instances that have run continuously for eight months. If we switch to a 1-year Reserved Instance, we'd save 40%. For burstable workloads we should use Savings Plans — they're more flexible than RIs." What is the difference between Reserved Instances and Savings Plans in cloud billing?
Reserved Instances (RIs): a billing commitment to use a specific instance type, in a specific region, for 1 or 3 years. Discounts: 30-72% vs on-demand. Types: Standard RI — fully fixed (instance type + region + AZ); deepest discount. Convertible RI — can change instance family during the term; smaller discount. Savings Plans: commit to a specific $/hour spend (e.g., $10/hr), applied flexibly across any instance type and region. Types: Compute Savings Plans — most flexible; applies to EC2, Fargate, Lambda. EC2 Instance Savings Plans — less flexible (fixed instance family per region) but higher discount. Cloud cost terminology: On-Demand pricing — pay per hour/second, no commitment; most expensive per unit. Spot Instances (AWS) / Preemptible VMs (GCP) — unused capacity auctioned at 60-90% discount; can be terminated with 2-minute notice. PAYG (Pay-As-You-Go) — Azure equivalent of on-demand. Unit economics — cost per transaction, per user, or per GB processed. Cloud spend — total cloud infrastructure cost. TCO (Total Cost of Ownership) — comparing cloud vs on-premises including people, hardware, facilities. In conversation: "We converted our always-on dev environments to Savings Plans and cut the bill by $8,000/month without changing a line of code."
2 / 12
A FinOps engineer presents to leadership: "Right now we can see our total cloud bill, but we can't break it down by team, product, or environment. I'm proposing a tagging strategy: every resource gets tagged with team, product, environment, and cost-centre. Then we can allocate costs and do showback." What is showback and how does it differ from chargeback?
Showback: teams see their allocated cloud costs in reports/dashboards for awareness and accountability — but there's no actual financial transfer. Builds cost-awareness culture without org-chart complexity. Chargeback: teams' cloud costs are transferred to their budget/P&L. Creates hard financial accountability — teams feel direct pain for waste. Cloud cost allocation vocabulary: Cost allocation tags — metadata key-value pairs attached to cloud resources (e.g., Team=backend, Env=production, CostCentre=CC-001). Enable filtering in billing dashboards. Tag governance — enforcing tagging policies; untagged resources = unallocatable spend. Cost centre — an internal accounting unit that accrues spend. Shared cost allocation — shared infrastructure (networking, monitoring) split across teams by a formula (e.g., proportional to compute spend). FinOps vocabulary: Unit economics — metric like cost-per-API-call or cost-per-active-user. Cloud waste — idle resources spending money (stopped EC2 instances with EBS attached, unattached load balancers, unused elastic IPs). Rightsizing — reducing oversized resources to a size that matches actual usage. FinOps Foundation — the industry body defining FinOps practices; FinOps phases: Inform → Optimise → Operate. In conversation: "We did showback for 6 months to educate teams, then switched to chargeback — teams immediately started rightsizing their oversized instances."
3 / 12
A cloud engineer explains a cost anomaly: "The data processing team had instances running around the clock at r6g.4xlarge — 16 vCPUs, 128 GB RAM — but CPU was only at 8% average and memory at 15%. They were massively overprovisioned. We rightsized to r6g.large and saved $4,200 per month on that cluster alone." What is rightsizing in cloud cost management?
Rightsizing: matching the compute, memory, and storage of cloud resources to their actual usage. Over-provisioning is the most common form of cloud waste: instances are sized for peak load that never arrives. Rightsizing process: 1) Collect utilisation data (CPU, memory, network, disk I/O) over 2-4 weeks. 2) Identify instances where peak usage < 30% of provisioned capacity. 3) Test on a smaller instance type. 4) Monitor for performance degradation. 5) Commit. Cloud resource optimisation vocabulary: Oversized instance — paying for compute you don't use. Opposite: undersized — causing performance degradation. CPU credits — T-series AWS instances (burstable) earn/spend CPU credits; important to monitor for applications that burst occasionally. IOPS (Input/Output Operations Per Second) — storage throughput metric; often a hidden cost when running high I/O databases. Auto Scaling — automatically adding/removing instances based on demand; reduces waste during off-peak hours. Hibernation / Stop-Start schedules — turn off development/staging instances outside business hours; saves 60-70% on non-production environments. Graviton instances (AWS) — ARM-based instances up to 40% cheaper than x86 equivalents for compatible workloads. In conversation: "We saved $60K/year just by scheduling dev environments to shut down at 8pm and start at 7am — no code changes needed."
4 / 12
A FinOps practitioner introduces a new team framework: "FinOps isn't just about cutting costs — it's about maximising value from cloud spend. The three pillars are: Inform (visibility into who's spending what), Optimise (reduce waste and increase efficiency), and Operate (ongoing governance through policies and automation). We're starting with the Inform phase." What is FinOps?
FinOps (Cloud Financial Operations): a practice and cultural shift that makes cloud spending a shared engineering-finance-business responsibility — not just a finance problem. The FinOps Foundation defines it as "a financial operating model for cloud." Three FinOps phases: Inform — visibility and allocation. Tagging, dashboards, cost reports, anomaly detection. Answer "who spends what on what?" Optimise — waste reduction and efficiency. Rightsizing, scheduling, commitment discounts, architectural changes. Operate — governance and automation. Budget alerts, policies, automated enforcement, cost benchmarking, unit economics tracking. Key FinOps vocabulary: Cloud cost forecasting — predicting future cloud spend based on growth models and committed capacity. Budget alert — a notification when spending exceeds a threshold. Cost anomaly detection — automated detection of unexpected spend spikes (AWS Cost Anomaly Detection, Azure Cost Alerts). Idle resource (cloud waste) — resources incurring cost without being actively used. Common sources: unattached EBS volumes, idle load balancers, unused static IPs, over-provisioned RDS. Cloud cost per feature — unit economics for product teams. Shared services cost model — how to allocate the cost of Kubernetes clusters, monitoring, NAT gateways shared by multiple teams. In conversation: "Before FinOps, engineering optimised for performance and finance optimised for budget — they rarely talked. FinOps made cloud cost a shared OKR."
5 / 12
A cloud architect makes the case for Spot Instances on a batch processing workload: "Our nightly data transformation job runs for 90 minutes. It's fault-tolerant — if a Spot Instance is reclaimed, the job checkpoints and resumes. We can save 70% versus on-demand by using Spot. For anything that can't tolerate interruption — databases, user-facing APIs — we stay on On-Demand or RIs." What are Spot Instances and what workloads are they suitable for?
Spot Instances (AWS) = Preemptible VMs (GCP) = Azure Spot VMs: cloud provider's unused capacity offered at steep discounts (60-90%). The provider can reclaim them with 2-minute warning when demand increases. Suitable workloads for Spot: Batch processing — nightly ETL, data transformation, log processing. CI/CD runners — build and test pipelines; job failure = retry. Machine learning training — checkpointing allows resuming after interruption. Stateless web tier — behind a load balancer; losing one instance doesn't affect users. Rendering farm — video/image rendering are naturally parallelisable and resumable. NOT suitable: databases (data loss risk), session-based applications without sticky sessions, anything with < 5 minutes of interruption budget. Advanced Spot patterns: Spot fleet — a collection of Spot Instances across instance types and AZs; if one pool is reclaimed, others fill in. Spot + On-Demand mix — base capacity on On-Demand, burst on Spot. Interruption handling — applications receive a termination notice; must checkpoint state within 2 minutes. Spot Advisor — AWS tool showing interruption frequency and savings by instance type. In conversation: "We moved 80% of our CI pipeline to Spot Instances and saved $15,000/month — build times increased by 2 minutes on average but nobody noticed."
6 / 12
Sarah (FinOps Engineer) is discussing cost optimization strategies with David (Dev Lead) in a Slack channel. "I'm seeing a lot of unused EC2 instances running in the Dev environment – we're paying for them even when they aren't actively being used. We need to implement auto-scaling and set appropriate minimum instance sizes to prevent this waste." What does David likely mean by 'setting appropriate minimum instance sizes'?
David is referring to the concept of minimum sizes. This ensures there's always *some* capacity running, avoiding idle time charges from on-demand pricing. Setting a minimum size prevents the instance from being completely shut down when it briefly needs to be restarted or scaled up. Options A and D are related to scaling policies; option B is about high availability.
7 / 12
Mark (Cloud Architect) writes a PR description for a new deployment pipeline: "We've automated the provisioning of Kubernetes clusters using Terraform. To track costs associated with these deployments, we are using CloudWatch metrics and setting up budget alerts. If spending exceeds $500 per month, an alert will be triggered to notify the FinOps team.". What is the primary purpose of setting up a budget alert in this scenario?
Budget alerts are specifically designed to *proactively* detect when spending exceeds a defined threshold. This allows the FinOps team – or whoever is responsible – to investigate and take corrective action before significant costs accumulate. Options A, C, and D represent different functionalities; budget alerts are about triggering alarms based on spending.
8 / 12
Mark (Cloud Architect) is writing a comment on a Terraform script for deploying Kubernetes clusters. He's added a cost tracking mechanism using CloudWatch Metrics and wants to ensure the team understands how to interpret the data. Which of the following best describes what Mark is trying to achieve?
Option A: He's simply adding logging statements to the script for debugging purposes.
Option B: He's implementing a cost allocation strategy using CloudWatch, focusing on granular resource tracking and identifying potential overspending trends.
Option C: He's configuring automated scaling rules based on CPU utilization to minimize instance costs.
Option D: He's creating alerts that trigger when the total cloud spend exceeds a predefined threshold.
The question tests understanding of CloudWatch metrics in FinOps. Option B is correct because CloudWatch allows for detailed resource tracking – crucial for identifying where money is being spent and for comparing costs across different environments. Options A and C focus on different aspects (debugging/scaling), while D is a reactive measure, not the proactive cost analysis Mark intends.
9 / 12
"Lisa (FinOps Engineer) is presenting to her team about 'Rightsizing' instances. She explains: 'We're running EC2 instances that are significantly larger than what our applications actually need. By matching the instance size to the workload demand, we can dramatically reduce costs without impacting performance.' Which of the following best summarizes Lisa's approach?
Option A: Lisa is advocating for using Spot Instances exclusively to take advantage of discounted pricing.
Option B: Lisa is promoting a proactive strategy of regularly evaluating and adjusting instance sizes based on actual usage patterns.
Option C: Lisa is recommending implementing a strict budget cap for all cloud resources, regardless of their utilization.
Option D: Lisa is suggesting using reserved instances to secure long-term cost savings.
This question tests understanding of the core concept behind 'Rightsizing'. Option B accurately describes Lisa's strategy – it's about aligning resource size with demand. Options A and D represent specific techniques (Spot Instances/Reserved Instances), while option C is a restrictive approach that doesn't align with FinOps principles.
10 / 12
David (Dev Lead) is in a Slack channel discussing the cost of running his team's CI/CD pipeline. He sees a large spike in costs associated with Kubernetes clusters and wants to understand why. Which of the following explanations would be MOST helpful for David to investigate?
Option A: The spike is normal, as Kubernetes clusters often have periods of high resource consumption during deployments.
Option B: The spike is due to excessive logging and monitoring configurations within the Kubernetes clusters.
Option C: The spike is likely caused by inefficiently configured Kubernetes deployments, such as running too many pods or using overly large container images.
Option D: The spike indicates a vulnerability in the application code that's causing it to consume excessive resources.
This question focuses on identifying potential root causes of cost spikes. Option C is the most relevant because inefficient Kubernetes deployments are a common cause of unexpectedly high cloud spending – especially if not properly monitored. The other options present less direct or likely explanations.
11 / 12
Emily (FinOps Analyst) is writing a PR description for a new automated cost optimization process. She wants to clearly explain the goal of the process to the development team. Which of the following statements best captures Emily's intention?
Option A: "This script automatically shuts down all idle EC2 instances to minimize costs."
Option B: "This process continuously monitors resource utilization and dynamically adjusts instance sizes to align with actual demand, reducing unnecessary spending."
Option C: "This script generates detailed reports on cloud usage, allowing you to identify areas for potential cost savings."
Option D: "This automation ensures that all development environments are compliant with our security policies."
Option B is the best because it reflects a core FinOps principle – proactive optimization. It highlights dynamic adjustment based on demand. Options A is overly simplistic and potentially disruptive; C describes reporting (a supporting activity), and D relates to compliance, not cost optimization.
12 / 12
John (Cloud Engineer) is explaining a new FinOps initiative to his team. He states: "We're going to use Tagging to track the cost of each application running in our cloud environment." What is the PRIMARY benefit of this approach?
Option A: Tagging ensures all resources are automatically scaled based on demand.
Option B: Tagging enables granular cost allocation by identifying which teams and applications are responsible for specific spending patterns.
Option C: Tagging eliminates the need for any manual monitoring of cloud resource usage.
Option D: Tagging simplifies the process of creating new cloud resources.
The primary benefit of tagging in FinOps is granular cost allocation. Option B accurately describes this – it allows you to see *who* is spending money on *what*. Options A and C are related but secondary benefits; D is simply a feature of cloud resource management.
Multi-Cloud Strategy— useful for Cloud architecture & FinOps (Solution Architect)
Frequently Asked Questions
What does the "Cloud FinOps Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to cloud finops vocabulary through 12 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 12 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — this module shares real-world context with 3 other vocabulary modules. See "Related vocabulary" below to keep building a connected skill set.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.