LFCS Service Configuration Practice Question
A system administrator manages a database server service (database.service) that experiences periodic CPU spikes, causing excessive load on the server. The administrator wants to limit the service's CPU usage to 25% of a single CPU core. The service is running on a system with cgroup v2. Which directive should be added to the [Service] section of the unit file to achieve this?
⚠ Common exam trap
Test-takers frequently confuse `CPUQuota=` (a hard limit) with `CPUWeight=` or `CPUShares=` (relative priority settings), mistakenly thinking a weight or share value can enforce a specific percentage cap on CPU usage.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
CPUQuota=25%
In cgroup v2, the `CPUQuota=` directive in a systemd unit file directly limits the CPU time a service can use, expressed as a percentage of a single CPU core. Setting `CPUQuota=25%` restricts the service to using at most 25% of one core, which matches the administrator's requirement to cap CPU usage at 25% of a single core.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
CPUAccounting=true
Why it's wrong here
CPUAccounting=true only enables CPU usage accounting for the cgroup; it records consumption but imposes no ceiling, so spikes continue. It is tempting because accounting is a prerequisite for CPU controls, and would be correct when you merely need metrics for monitoring or before applying CPUQuota.
- ✓
CPUQuota=25%
Why this is correct
CPUQuota constrains aggregate CPU time within the cgroup v2 hierarchy, expressed as a percentage of one core. Setting CPUQuota=25% caps database.service at a quarter of a single CPU, directly limiting the spikes causing excessive load.
- ✗
CPUWeight=100
Why it's wrong here
CPUWeight=100 assigns relative scheduling weight, not a hard limit, so the service can still use a whole core when nothing else competes. It is tempting because weight is the cgroup v2 replacement for shares, and would be correct for balancing CPU between services rather than enforcing a 25% ceiling.
- ✗
CPUShares=256
Why it's wrong here
CPUShares=256 sets relative weighting against other cgroups, not an absolute cap, so an idle system still lets the service consume a full core. It is tempting because shares do throttle under contention, and would be correct when prioritising services against each other rather than capping one at 25%.
Go deeper
Related to this question
About these practice questions
One of 406 original LFCS practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This LFCS practice question is part of Courseiva's free Linux Foundation certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the LFCS exam.