I85PREP
⌘ K
FinOps Certified Engineer study materials
FinOps Certified Engineer study resources

FinOps Certified Engineer practice questions

One question at a time. Build your FinOps Certified Engineer understanding.

First 50 of 200 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.

Continue in the practice tool above to load more questions, 50 at a time.

Question 1FinOps for Containers

In FinOps for Containers, which Kubernetes construct is the primary mechanism for attributing cluster costs to a team, product, or cost center?

  1. Container image pull policies
  2. Namespaces combined with labels and annotations Correct answer.
  3. PersistentVolume reclaim policies
  4. The kube-scheduler priority class

Explanation

Cost allocation in Kubernetes relies on namespaces as the coarse boundary and labels/annotations as the fine-grained dimensions that map workloads to owners. Showback and chargeback reports are built by joining those metadata dimensions to resource consumption data.

Question 2FinOps for Containers

A platform team wants to compare the efficiency of two clusters that run different workload mixes. Which metric best normalizes cost against the value delivered?

  1. Cost per CPU-core-hour consumed
  2. Cost per unit of a business-relevant resource proxy such as requests served or namespace-level CPU requests Correct answer.
  3. Number of nodes provisioned
  4. Total monthly cluster spend in currency

Explanation

FinOps unit economics compare spend to a unit of value, so container efficiency needs a denominator tied to what the workload delivers. Cost per business unit or per requested resource normalizes across differing cluster sizes and mixes, while raw spend does not.

Question 3FinOps for Containers

Which combination of Kubernetes requests settings most directly reduces wasted spend caused by over-provisioned pods?

  1. Setting requests close to measured usage and using Horizontal Pod Autoscaler targets based on real demand Correct answer.
  2. Setting requests equal to observed high-percentile usage and removing limits entirely
  3. Increasing the cluster autoscaler maximum node count
  4. Setting requests far above measured usage so pods are never throttled

Explanation

Requests drive scheduler reservations and therefore the capacity the cluster must buy, so aligning them with measured usage reclaims stranded capacity. Autoscaling on real demand then matches replica count to load rather than to peak guesses.

Question 4FinOps for Containers

What is the key distinction between showback and chargeback in a container platform FinOps program?

  1. Showback applies only to namespaces; chargeback applies only to nodes
  2. Showback uses list prices; chargeback uses discounted rates
  3. Showback informs teams of their costs; chargeback moves those costs onto team budgets Correct answer.
  4. Showback is automated; chargeback is always manual

Explanation

Showback reports consumption to owners for awareness, while chargeback actually transfers the financial burden to the consuming team's budget. Many organizations start with showback and mature into chargeback once allocation accuracy is trusted.

Question 5FinOps for Containers

A shared observability stack runs in its own namespace and serves every product team. What is the most defensible way to allocate its cost?

  1. Distribute it using a documented shared-cost model such as proportional CPU requests or log volume per consuming team Correct answer.
  2. Split it evenly by the number of namespaces in the cluster
  3. Assign the full cost to the platform team's budget and exclude it from product reporting
  4. Leave it unallocated because shared services cannot be attributed

Explanation

Shared services still consume real money, so FinOps practice allocates them with a transparent, documented driver rather than ignoring them. Proportional resource consumption or usage volume gives an auditable basis that teams can influence.

Question 6FinOps for Containers

Which Kubernetes feature lets you cap the aggregate compute a namespace can consume, supporting budget guardrails?

  1. PodDisruptionBudget
  2. ResourceQuota Correct answer.
  3. LimitRange
  4. NetworkPolicy

Explanation

ResourceQuota enforces aggregate limits on requests and limits within a namespace, which acts as a hard ceiling on the capacity a team can reserve. LimitRange instead sets per-container defaults and bounds, not namespace totals.

Question 7FinOps for Containers

An engineer notices that pod CPU requests total 60 cores across the cluster while actual usage averages 12 cores. Which FinOps action addresses the root cause?

  1. Increase the number of availability zones
  2. Purchase committed use discounts for the existing node pool
  3. Move all workloads to spot instances without changing requests
  4. Right-size requests using historical usage percentiles and re-evaluate regularly Correct answer.

Explanation

The gap between reserved requests and actual usage is stranded capacity that the cluster pays for regardless of consumption. Right-sizing requests to observed usage shrinks the node footprint needed, which is the durable fix.

Question 8FinOps for Containers

Which cost driver is unique to container platforms compared with traditional virtual machine fleets?

  1. Bin-packing efficiency, where scheduler placement determines how much idle capacity you pay for Correct answer.
  2. Storage replication factor
  3. Operating system licensing per host
  4. Data center power distribution

Explanation

Because the scheduler packs pods onto nodes, the utilization of purchased nodes depends on requests and placement decisions. Poor bin-packing leaves paid-for capacity idle in a way that is specific to orchestrated container environments.

Question 9FinOps for Containers

What does the term 'idle cost' mean when reporting Kubernetes cluster spend?

  1. The cost of unused container images in the registry
  2. The cost of network egress between zones
  3. The cost of nodes whose allocatable capacity is not reserved by any pod request Correct answer.
  4. The cost of pods that are crash-looping

Explanation

Idle cost is the portion of purchased node capacity that no workload request claims, so nobody is charged for it even though the organization pays. Tracking idle cost highlights opportunities to consolidate nodes or right-size requests.

Question 10FinOps for Containers

A team wants to reduce spend on a batch workload that tolerates interruption. Which lever most directly lowers the unit price of compute?

  1. Adding a PodDisruptionBudget with zero allowed disruptions
  2. Running the workload on spot or preemptible nodes with appropriate disruption handling Correct answer.
  3. Switching the image pull policy to Always
  4. Increasing replica count for redundancy

Explanation

Spot and preemptible capacity is priced below on-demand capacity, and batch work that can tolerate interruption is the ideal fit. Pairing it with disruption handling keeps the savings without sacrificing completion.

Question 11FinOps for Containers

Which labeling practice most improves the reliability of container cost allocation reports?

  1. Relying on node names to infer ownership
  2. Applying a consistent, enforced set of ownership labels such as team, cost-center, and environment Correct answer.
  3. Using free-text annotations for owner names
  4. Labeling only production namespaces

Explanation

Allocation quality depends on consistent, machine-readable metadata across every workload, enforced through policy so gaps do not appear. Standard keys for team, cost center, and environment let reports join consumption to owners without manual cleanup.

Question 12FinOps for Containers

How does the Kubernetes Horizontal Pod Autoscaler influence container cost if configured with an aggressive scale-down stabilization window?

  1. It increases cost by keeping extra replicas running longer
  2. It has no effect on cost because requests are unchanged
  3. It reduces cost by removing replicas quickly after load falls, at some risk of thrashing Correct answer.
  4. It forces nodes to be terminated immediately

Explanation

A short stabilization window lets the autoscaler shed replicas soon after demand drops, reducing reserved capacity and therefore cost. The tradeoff is potential flapping, which can offset savings through churn and latency.

Question 13FinOps for Containers

What is the purpose of a namespace-level cost report that separates requested, used, and idle capacity?

  1. To determine which pods should be evicted first
  2. To calculate container image vulnerability exposure
  3. To reveal where reservations exceed consumption so teams can act on efficiency Correct answer.
  4. To satisfy audit requirements for financial statements

Explanation

Showing requested versus used versus idle capacity makes the stranded-capacity gap visible per owner. That visibility is what enables teams to right-size and lets the platform team target consolidation.

Question 14FinOps for Containers

Which approach best estimates the fully loaded cost of a namespace in a multi-tenant cluster?

  1. Using only the namespace's egress bytes
  2. Charging each namespace the list price of one dedicated node
  3. Allocating node cost by each namespace's share of requested resources, then adding allocated shared and network costs Correct answer.
  4. Multiplying pod count by a flat per-pod rate

Explanation

A defensible estimate allocates node cost in proportion to the resources each namespace reserves, then layers in shared services and network charges. Flat per-pod or per-node rates ignore how much capacity each workload actually holds.

Question 15FinOps for Containers

A FinOps practitioner wants to forecast container spend for the next quarter. Which input is most important to model?

  1. The number of container images stored in the registry
  2. Projected aggregate resource requests multiplied by node pricing and expected utilization Correct answer.
  3. The count of Kubernetes API objects
  4. The number of developers on each team

Explanation

Container spend is driven by the node capacity required to satisfy aggregate requests, priced at the rates the organization pays and adjusted for how efficiently that capacity is used. Forecasting from requests and utilization captures the dominant drivers.

Question 16FinOps for Containers

Which practice helps an organization detect anomalous container cost spikes early?

  1. Setting budget alerts and daily trend monitoring on namespace-level spend Correct answer.
  2. Reviewing the monthly invoice after it is issued
  3. Relying on a single annual capacity review
  4. Disabling autoscaling to keep costs flat

Explanation

Early detection requires frequent monitoring against expected trends plus automated alerts when spend deviates. Monthly invoice review is too late to prevent overspend within the billing period.

Question 17FinOps for Containers

What role do Kubernetes resource limits play in cost governance compared with requests?

  1. Both requests and limits directly determine node pricing tiers
  2. Requests reserve capacity for scheduling; limits cap runtime consumption and can cause throttling or OOM kills Correct answer.
  3. Limits reserve capacity for scheduling; requests cap runtime consumption
  4. Limits only apply to storage volumes

Explanation

The scheduler places pods based on requests, which is what drives node count and cost. Limits bound actual runtime usage and protect neighbors, but they do not reserve capacity for scheduling.

Question 18FinOps for Containers

A platform team is deciding whether to consolidate two underutilized clusters into one. Which factor most affects the FinOps outcome?

  1. The age of the Kubernetes version
  2. The combined utilization achievable after consolidation versus the cost of isolation and blast-radius risk Correct answer.
  3. The container runtime used by each cluster
  4. The number of namespaces in each cluster

Explanation

Consolidation lowers cost by raising bin-packing density on fewer nodes, but it trades against isolation and failure domain risk. The FinOps decision weighs the utilization gain against those operational costs.

Question 19FinOps for Containers

Which metric best captures how much of the purchased cluster capacity is actually claimed by workloads?

  1. Error rate per service
  2. Allocation rate, the ratio of requested resources to allocatable capacity Correct answer.
  3. Mean time to recovery
  4. Deployment frequency

Explanation

Allocation rate compares what workloads reserve against what the cluster can offer, exposing unclaimed capacity. A low allocation rate signals over-provisioned nodes or under-set requests that waste money.

Question 20FinOps for Containers

How should a team treat the cost of a Kubernetes control plane in a managed service when allocating cluster costs?

  1. Ignore it because it is not a node cost
  2. Allocate it as a fixed shared cost across tenants using a documented driver Correct answer.
  3. Multiply it by the number of persistent volumes
  4. Charge it entirely to the namespace with the most pods

Explanation

Managed control plane fees are real, recurring costs that belong in the fully loaded cluster cost. Because they do not scale with any single workload, they are allocated as a shared fixed cost using a transparent driver.

Question 21FinOps for Containers

Which scenario most clearly indicates that committed use discounts would be a poor fit for a container platform?

  1. Highly variable workload volume with frequent large swings and short project lifetimes Correct answer.
  2. A production cluster running the same services continuously
  3. Steady, predictable baseline usage that has persisted for many months
  4. A platform with a stable, growing request baseline

Explanation

Commitments pay off when usage is predictable enough to cover the committed level over the term. Highly variable or short-lived workloads risk paying for capacity that goes unused, eroding the discount benefit.

Question 22FinOps for Containers

What is the main FinOps benefit of using namespace-level resource quotas alongside chargeback?

  1. They give teams a hard ceiling on reserved capacity, aligning spend authority with budget accountability Correct answer.
  2. They guarantee the lowest possible unit price
  3. They automatically convert on-demand nodes to committed capacity
  4. They eliminate the need for cost allocation labels

Explanation

Quotas cap how much capacity a team can reserve, which pairs naturally with chargeback so teams bear the consequences of their requests. Together they create accountability without relying on after-the-fact policing.

Question 23FinOps for Containers

Which set of dimensions is most useful for slicing a container cost report to drive action?

  1. API server version and admission controller list
  2. Kernel version, container runtime, and CNI plugin
  3. Namespace, team, environment, and workload type Correct answer.
  4. Node hostname, pod UID, and image digest

Explanation

Actionable cost reporting slices spend by the dimensions owners control and recognize, such as team, environment, and workload type. Those slices map directly to the people who can change requests, replicas, or scheduling.

Question 24FinOps for Containers

A workload's memory requests are set to the 99th percentile of usage while its actual average is far lower. What is the likely FinOps consequence?

  1. Higher node count and idle cost because capacity is reserved for rare peaks Correct answer.
  2. Lower node count because memory is reserved precisely
  3. No effect on cost because memory is not schedulable
  4. Reduced egress charges

Explanation

Memory requests determine how many pods fit on a node, so sizing to rare peaks reserves capacity that sits idle most of the time. The result is more nodes purchased than the average workload requires.

Question 25FinOps for Containers

Which statement correctly describes how the cluster autoscaler interacts with cost in a container platform?

  1. It adds or removes nodes based on pending pods and utilization, directly changing the capacity you pay for Correct answer.
  2. It sets per-namespace budgets
  3. It converts node pricing to committed rates
  4. It adjusts pod requests to match usage

Explanation

The cluster autoscaler scales the node pool to fit unschedulable pods and removes underused nodes, so it directly determines how much node capacity the organization pays for. It does not modify pod requests or budgets.

Question 26FinOps for Containers

In container cost allocation, what does the term 'unallocated cost' most precisely refer to?

  1. Spend on the managed control plane fee charged per cluster
  2. Spend on persistent volumes that are not yet bound to a pod
  3. Spend on cluster capacity that cannot be attributed to any labeled workload or namespace Correct answer.
  4. Spend on workloads whose labels are missing a team tag

Explanation

Unallocated cost is the residual of total cluster cost minus the cost already attributed to workloads, namespaces, or owners. It captures shared overhead such as system daemons, kube-system components, and unused capacity that no workload claim covers. Missing team labels cause misattribution within allocated spend, not the unallocated residual itself.

Question 27FinOps for Containers

Why is CPU measured in core-hours rather than in raw core counts when building container cost reports?

  1. Core-hours remove the effect of burstable CPU throttling from the measurement
  2. Core-hours normalize cost across time so workloads of different durations can be compared on one basis Correct answer.
  3. Core-hours are the only unit the Kubernetes metrics server exposes
  4. Core-hours convert memory usage into an equivalent CPU charge

Explanation

Cost is a rate applied over time, so a workload running four cores for one hour and one running one core for four hours both consume four core-hours. Using core-hours lets you compare, aggregate, and price workloads with different runtimes on a single consistent basis. Raw core counts say nothing about duration and therefore cannot be priced directly.

Question 28FinOps for Containers

Which Kubernetes object is the most direct source for attributing pod cost to an owning application team?

  1. The node's instance type tag
  2. The pod's restart count
  3. The container image registry path
  4. The namespace the pod runs in, combined with its labels Correct answer.

Explanation

Namespaces and labels are the standard dimensions that map workloads to organizational owners in Kubernetes. Cost tools join pod usage to these metadata fields to produce team-level reports. Node tags describe infrastructure, not ownership, and image paths or restart counts carry no ownership semantics.

Question 29FinOps for Containers

What does a showback report accomplish that a chargeback report does not?

  1. It makes container spend visible to teams without moving money on internal budgets Correct answer.
  2. It guarantees that every dollar of cluster cost is recovered from tenants
  3. It automatically applies committed use discounts to the cluster
  4. It replaces the need for resource quotas in each namespace

Explanation

Showback informs teams about their consumption and cost so they can change behavior, but no financial transfer occurs. Chargeback goes further by debiting team budgets for their attributed spend. Quotas and discount application are separate controls that neither report type performs by itself.

Question 30FinOps for Containers

A platform team wants each namespace's cost to reflect the CPU and memory it reserves, not just what it uses at any instant. Which allocation method matches this goal?

  1. Allocate by peak observed usage over the billing period
  2. Allocate by resource requests, treating reserved capacity as the billed quantity Correct answer.
  3. Allocate by the number of pods deployed in the namespace
  4. Allocate evenly across all namespaces regardless of size

Explanation

Request-based allocation charges each namespace for the capacity the scheduler has reserved for it, which is what actually blocks other workloads from using that capacity. This is the common approach when reserved capacity is the scarce resource being purchased. Peak usage and pod counts ignore reservation, and even splitting ignores consumption entirely.

Question 31FinOps for Containers

Which practice most directly prevents a container cost report from double-counting shared platform services?

  1. Assign all shared service cost to the largest namespace
  2. Define one explicit rule for distributing shared costs and apply it consistently to every report Correct answer.
  3. List shared services in a separate report that is never reconciled
  4. Exclude shared services from the total cluster cost

Explanation

Shared costs such as logging, ingress, and system daemons must be distributed by a documented rule so the sum of allocated cost plus the unallocated residual equals total cluster cost. Applying the rule consistently avoids counting the same spend twice or losing it. Ad hoc assignment or exclusion breaks reconciliation and hides real spend.

Question 32FinOps for Containers

What is the primary reason to tag or label Kubernetes nodes with their purchasing model, such as on-demand versus spot?

  1. It reduces the node count needed to run the cluster
  2. It causes the scheduler to prefer cheaper nodes for all pods
  3. It automatically converts on-demand nodes into spot nodes
  4. It lets cost tools price workload usage at the correct rate per node pool Correct answer.

Explanation

Different node pools carry different unit prices, so a cost model needs to know which pool a pod ran on to apply the right rate. Node labels or taints provide that mapping. Labels do not change scheduling economics by themselves, reduce capacity, or convert purchasing models.

Question 33FinOps for Containers

Which cost is typically excluded from a namespace-level container cost report because it varies with the cloud provider rather than with workload behavior?

  1. Memory requests from the namespace's pods
  2. CPU usage from the namespace's pods
  3. Persistent volume storage attached to the namespace
  4. Data transfer egress charges incurred by the namespace's services Correct answer.

Explanation

Egress and other network charges depend on provider pricing and traffic patterns rather than on how the workload consumes cluster compute. Many allocation models therefore report them separately or attribute them only where flow data exists. CPU, memory, and attached storage are directly attributable to the namespace's workloads.

Question 34FinOps for Containers

A cluster runs many short-lived jobs that start and stop within minutes. Which allocation cadence best captures their cost fairly?

  1. Charging only for jobs that run longer than one hour
  2. Sampling usage at fine intervals and integrating over the actual runtime of each job Correct answer.
  3. Charging each job a flat fee per pod regardless of runtime
  4. Sampling usage once per day at a fixed hour

Explanation

Short jobs can start and finish entirely between coarse samples, so daily snapshots miss or misprice them. Fine-grained sampling integrated across each job's real runtime reflects actual consumption. Flat fees and runtime thresholds distort cost for workloads that differ widely in duration.

Question 35FinOps for Containers

A team sets CPU requests far above observed usage for a latency-sensitive service. What is the most accurate cost consequence of this choice?

  1. The scheduler will automatically reduce the request to match usage
  2. The service incurs no additional cost because billing tracks only actual CPU consumption
  3. The cluster must hold capacity that is billed even though it is largely unused, raising the cost per transaction Correct answer.
  4. The request has no effect because limits govern billing rather than requests

Explanation

Requests reserve capacity on nodes, and that reserved capacity is what the organization pays for in aggregate. Over-requesting blocks other workloads and leaves paid capacity idle, which inflates the unit cost of the service's output. Billing at the cluster level follows purchased capacity, not instantaneous usage.

Question 36FinOps for Containers

When attributing cost to a pod, why do many models blend request-based and usage-based allocation?

  1. Blending removes the need to collect any usage metrics
  2. Blending guarantees the sum of allocations equals the cloud invoice
  3. Requests reflect reserved capacity while usage reflects actual consumption, so blending balances fairness for both reserved and bursty workloads Correct answer.
  4. Blending is required by the Kubernetes scheduler to place pods

Explanation

Pure request-based allocation can overcharge workloads that reserve but rarely use capacity, while pure usage-based allocation can undercharge workloads that hold large reservations. A blend, often weighted toward requests, shares the cost of reserved capacity while still reflecting consumption. The scheduler does not depend on the allocation method.

Question 37FinOps for Containers

A namespace shows high cost but low utilization. Which follow-up most directly identifies the cause within that namespace?

  1. Check the cluster's Kubernetes version upgrade history
  2. Compare the namespace against other namespaces in the same cluster
  3. Review the cloud provider's list price for the node instance types
  4. Break the namespace's cost down by controller and compare requests against observed usage for each workload Correct answer.

Explanation

Drilling from namespace to controller and then comparing requests with usage isolates which workload holds the over-reserved capacity. Cluster-level comparisons and list prices do not explain behavior inside one namespace. Version history is unrelated to consumption patterns.

Question 38FinOps for Containers

Which metric should a FinOps practitioner pair with total container spend to judge whether the platform is becoming more efficient over time?

  1. Total node count in the cluster
  2. Average pod restart rate
  3. Cost per unit of business output, such as cost per thousand requests or per order Correct answer.
  4. Number of namespaces in the cluster

Explanation

Unit economics divide spend by a business or service output so growth can be separated from efficiency gains. A rising total bill may be healthy if cost per request is falling. Node count, namespace count, and restart rate describe scale or reliability rather than the cost of delivering output.

Question 39FinOps for Containers

A team wants to cut spend on a development cluster that is idle outside business hours. Which lever most directly reduces cost without changing application architecture?

  1. Scale non-production node pools down or to zero during off-hours Correct answer.
  2. Add more replicas to development deployments
  3. Increase CPU requests for all development pods
  4. Move development workloads to the production node pool

Explanation

Idle non-production clusters still incur charges for provisioned nodes, so scheduling them off outside working hours removes that spend. Requests, replicas, and pool consolidation change capacity or placement but do not remove the cost of running idle nodes overnight.

Question 40FinOps for Containers

A cost report shows a namespace's allocated cost exceeding the sum of its workloads' usage-based cost. Which explanation is most consistent with a request-based allocation model?

  1. The report double-counted the namespace's pods
  2. The cloud provider billed the namespace twice
  3. The namespace reserves more capacity than it uses, so it is charged for the reservation rather than for consumption Correct answer.
  4. The namespace's storage volumes were counted as compute

Explanation

Under request-based allocation, a namespace is billed for the capacity reserved on its behalf, which can exceed the cost implied by actual usage. The gap is the price of holding capacity available. Double billing or misclassified storage would be data errors, not the expected behavior of the model.

Question 41FinOps for Containers

Which labeling dimension is most actionable for reducing container spend after a report shows a cost spike?

  1. The container runtime in use on each node
  2. The Kubernetes API version used by the cluster
  3. The creation timestamp of each node
  4. The owning team or application, so the spike can be routed to the people who can change the workload Correct answer.

Explanation

A cost report drives action only when it points to an accountable owner who can change configuration or demand. Ownership labels connect the spike to a team or application. Runtime, API version, and node age describe platform characteristics that the responsible team cannot usually change to reduce spend.

Question 42FinOps for Containers

A company runs a multi-tenant cluster and wants to recover the cost of the managed control plane and system components. Which approach is most defensible?

  1. Ignore the control plane cost because it is small relative to compute
  2. Assign the full control plane cost to the tenant with the most pods
  3. Distribute those costs across tenants using a documented, stable driver such as each tenant's share of requested capacity Correct answer.
  4. Charge the control plane cost only to tenants that use the API server most often

Explanation

Shared platform cost must be spread by a driver that is stable, documented, and roughly proportional to the benefit each tenant receives. Share of requested capacity is a common and defensible driver. Pod counts and API call frequency are volatile and easy to game, and ignoring the cost understates the true price of tenancy.

Question 43FinOps for Containers

Which pattern best supports forecasting container spend when workload demand is highly seasonal?

  1. Forecast from the number of engineers on each team
  2. Forecast from the cluster's Kubernetes release schedule
  3. Model cost as a function of historical usage patterns plus the pricing of the capacity needed to serve forecast demand Correct answer.
  4. Assume next quarter equals the last month multiplied by three

Explanation

Container cost follows both demand and the price of the capacity provisioned to meet it, so a forecast needs historical seasonality and the relevant pricing. Simple linear extrapolation from a single month ignores seasonal swings. Team headcount and release schedules do not directly determine resource consumption.

Question 44FinOps for Containers

A cluster's pods request 40 cores in total while the node pool provides 64 cores and average usage is 10 cores. Which statement best describes the cost situation?

  1. The organization pays for 64 cores, allocates 40 by request, and must decide how to treat the remaining 24 as idle or shared overhead Correct answer.
  2. The organization pays for 10 cores because billing follows actual usage
  3. The organization pays for 40 cores because requests define the bill
  4. The organization pays for 64 cores and can allocate all of it to workloads by request

Explanation

Provisioned capacity sets the bill, so the organization pays for all 64 cores regardless of usage. Requests account for 40 cores of allocation, leaving 24 cores that are either idle or absorbed as shared overhead under a documented rule. Billing does not follow usage or requests at the cluster level.

Question 45FinOps for Containers

Why is charging back the cost of idle cluster capacity to tenants a contested practice?

  1. It always increases total cluster cost
  2. It is prohibited by the Kubernetes API
  3. It removes the ability to use committed use discounts
  4. It charges tenants for capacity nobody reserved, which can feel unfair and weaken incentives to right-size requests Correct answer.

Explanation

Idle capacity arises from the gap between provisioned nodes and total requests, so charging it to tenants penalizes teams for headroom they did not ask for. Many organizations instead treat it as platform overhead or charge it only to the team that controls provisioning. The practice is a policy choice, not a technical restriction.

Question 46FinOps for Containers

A platform team wants container cost reports to reconcile exactly to the cloud invoice each month. Which control is most important?

  1. A monthly reconciliation step that compares allocated plus unallocated cost against the invoice and investigates gaps Correct answer.
  2. A requirement that all workloads use the same container image base
  3. A policy that disables autoscaling during the billing period
  4. A rule that every namespace must have at least one pod

Explanation

Reconciliation closes the loop between internal allocation and the actual bill by surfacing unallocated spend, pricing mismatches, and discounts not yet applied. Without it, reports drift from reality and lose credibility. Pod counts, image bases, and autoscaling policy do not by themselves guarantee that allocations sum to the invoice.

Question 47FinOps for Containers

Two clusters have the same total cost, but cluster A has 70 percent of requested capacity covered by commitments while cluster B has 30 percent. What does this most likely imply for cost efficiency?

  1. Cluster A is more likely to realize commitment savings because its steady reserved load matches purchased commitments Correct answer.
  2. Cluster B is more efficient because it has more flexibility to scale
  3. Both clusters realize identical savings because total cost is equal
  4. Cluster A will pay more because commitments reduce flexibility

Explanation

Commitments save money only when steady usage covers them; a cluster whose reservations consistently align with committed capacity is more likely to capture the discount. Cluster B's lower coverage suggests more of its spend is at on-demand rates or that commitments are underused. Equal total cost does not imply equal effective rates.

Question 48FinOps for Containers

A workload's memory usage is stable at 8 GiB, but its request is set to 16 GiB to avoid eviction risk. Which action best improves cost efficiency while preserving safety?

  1. Lower the request toward the stable usage level and keep a limit above it as a buffer Correct answer.
  2. Move the workload to a larger node pool
  3. Raise the limit to 32 GiB to guarantee headroom
  4. Remove both the request and the limit so the scheduler ignores memory

Explanation

Requests reserve capacity and therefore drive cost, so aligning the request with stable usage reclaims reserved capacity while a higher limit still protects against unexpected growth. Removing requests makes scheduling unpredictable, and raising limits or node size increases cost without addressing the reservation.

Question 49FinOps for Containers

A cost report attributes a large share of spend to a single DaemonSet that runs on every node. What is the most appropriate treatment?

  1. Exclude it from the report because it is infrastructure
  2. Charge its cost only to the team that wrote the manifest
  3. Classify it as shared platform overhead and distribute its cost by a documented driver across the tenants it serves Correct answer.
  4. Charge its full cost to the namespace where the DaemonSet manifest is stored

Explanation

A DaemonSet that runs on every node provides cluster-wide value, so its cost is shared overhead rather than the responsibility of one namespace. It should be distributed by a documented driver such as each tenant's share of requested capacity. Charging the manifest's namespace or excluding the cost misrepresents who benefits.

Question 50FinOps for Containers

A team wants to reduce the cost of a stateless service that over-provisions replicas during low-traffic periods. Which combination of levers most directly targets the waste?

  1. Demand-driven replica scaling plus requests sized to observed per-replica usage Correct answer.
  2. More namespaces plus stricter network policies
  3. Longer image build times plus more frequent deployments
  4. A larger node pool plus higher memory limits

Explanation

Over-provisioned replicas waste capacity during low traffic, so scaling replicas with demand removes that waste, and right-sized requests ensure each replica reserves only what it needs. Larger nodes, higher limits, build times, and namespace changes do not address replica over-provisioning.