Rust's ownership system is its most distinctive feature, enabling memory safety without a garbage collector. These exercises cover ownership, borrowing rules, lifetime annotations, shared ownership patterns, and interior mutability — the concepts every Rust developer must understand.
0 / 5 completed
1 / 5
At standup, a colleague asks what ownership means in Rust. What is the correct answer?
Ownership is Rust's core memory management model. Every value has exactly one owner. When the owner goes out of scope, Rust automatically calls drop() and frees the memory — with no runtime garbage collector. Ownership can be moved (transferring ownership to a new variable, making the old one unusable) or borrowed (temporarily lending the value via a reference). These rules are enforced at compile time by the borrow checker.
2 / 5
During a PR review, a teammate asks what the borrow checker enforces. Which answer is correct?
The borrow checker enforces two core rules at compile time. First, all references must be valid — a reference cannot outlive the data it points to (no dangling pointers). Second, at any point in the code you may have either one mutable reference (&mut T) OR any number of immutable references (&T), but never both at once. These rules eliminate data races and use-after-free bugs without runtime overhead.
3 / 5
In a design review, the team discusses lifetimes in Rust. A junior engineer asks what lifetime annotations like 'a express. What is correct?
Lifetime annotations don't change how long values live — they describe relationships between reference lifetimes so the borrow checker can verify safety. For example, &'a str means 'a reference to a string that lives at least as long as 'a'. When a function returns a reference, the compiler needs to know which input reference's lifetime it derives from. The compiler elides lifetimes in many cases (lifetime elision rules), but explicit annotations are required when the relationship is ambiguous.
4 / 5
An incident report shows a data structure needing multiple owners causing compile errors. A senior engineer asks when to use Rc vs Arc in Rust. What is correct?
Rc<T> (Reference Counted) allows multiple owners of a value in a single thread. Its reference count uses non-atomic operations — fast but notSend, so it cannot cross thread boundaries. Arc<T> (Atomically Reference Counted) uses atomic increment/decrement, making it Send + Sync and safe for multi-threaded shared ownership. Prefer Rc for single-threaded graphs or trees; use Arc when you need to share data across threads.
5 / 5
During a code review, a senior engineer asks what interior mutability means and when RefCell<T> is appropriate. What is accurate?
Interior mutability allows mutating data behind a shared (&T) reference, which the borrow checker normally forbids. RefCell<T> enforces borrow rules at runtime instead of compile time: .borrow() returns an immutable reference (panics if a mutable borrow is active), and .borrow_mut() returns a mutable reference (panics if any borrow is active). Use it in single-threaded code where you genuinely need shared mutability — for example, in a tree where nodes need to mutate each other through shared references. For multi-threaded code, use Mutex<T> instead.
What does the "Rust Ownership and Borrowing Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to rust ownership and borrowing vocabulary through 5 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 5 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 — browse the full vocabulary exercises hub to find related modules covering adjacent IT topics and roles.
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.