Blender Quiz: Insert And Edit Keyframes For Transforms
10 questions · exam conditions
0:00
Insert And Edit Keyframes For TransformsQuestion 1 of 10

At frame 40, an object already has rotation keyframes from earlier work, but no transform channels are keyed at frame 40. The animator changes both the object's location and rotation. With the pointer over the combined Location fields in the Transform panel, the animator inserts a keyframe for that property.

What is the resulting keyframe state at frame 40?

Both location and rotation are keyed because both transforms changed before insertion.
All three location components are keyed, while the changed rotation remains unkeyed at that frame.
Only the location component changed most recently is keyed, while the other components remain unkeyed.
The existing rotation curves receive keys, while location remains unkeyed because it had no prior curve.
← Back to quizzes

Blender Quiz

Blender Quiz: Insert And Edit Keyframes For Transforms

Practice Insert And Edit Keyframes For Transforms in Blender with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Insert And Edit Keyframes For Transforms, giving you a quick way to practice the rules, question types, and explanations that matter most for Blender.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

At frame 40, an object already has rotation keyframes from earlier work, but no transform channels are keyed at frame 40. The animator changes both the object's location and rotation. With the pointer over the combined Location fields in the Transform panel, the animator inserts a keyframe for that property.

What is the resulting keyframe state at frame 40?

  1. Both location and rotation are keyed because both transforms changed before insertion.
  2. All three location components are keyed, while the changed rotation remains unkeyed at that frame. (correct answer)
  3. Only the location component changed most recently is keyed, while the other components remain unkeyed.
  4. The existing rotation curves receive keys, while location remains unkeyed because it had no prior curve.
Explanation: When working with keyframe insertion in Blender, it's essential to understand that property-specific keying respects the exact property you target — nothing more, nothing less. The Transform panel groups location (X, Y, Z), rotation (X, Y, Z), and scale into distinct fields, and hovering over a specific field before pressing I keys only that property. In this scenario, the animator hovers over the combined Location fields and inserts a keyframe. Blender keys all three location components (X, Y, Z) because the cursor is over that entire property group. The rotation values — despite having been manually changed — are not under the cursor and are therefore not included in this insertion. This makes B correct: all three location components receive keys at frame 40, while the modified rotation goes unkeyed at that frame. A is wrong because Blender doesn't automatically key every property that changed during a session — it keys only what you explicitly target with your cursor at insertion time. C is wrong because hovering over the combined Location field keys all three location axes, not just the most recently edited component. D inverts the logic entirely — it's rotation that already had prior curve data, and location that was freshly changed, yet it's location that gets keyed because that's where the cursor was pointed. Prior curve existence doesn't determine what gets keyed; cursor position does. A useful habit: before inserting a keyframe with I, consciously check where your pointer is. The property highlighted in the UI is exactly what will be recorded — no more, no less.

Question 2

Auto Keying is disabled. At frame 30, an object's location and rotation are already keyed. The animator moves the object in the 3D Viewport but does not change its rotation.

Which action reliably replaces the stored location at frame 30 while leaving the rotation key unchanged?

  1. Enable Auto Keying after the move, then leave frame 30 without making another edit.
  2. Move to frame 31 and back, allowing Blender to update the existing location key automatically.
  3. Target the Location property and insert a keyframe again while remaining on frame 30. (correct answer)
  4. Change the location curve's handle type so the edited viewport position becomes the keyed value.
Explanation: Keyframing in Blender requires you to think carefully about what gets recorded and when — specifically, that Blender only stores values you explicitly tell it to store, unless Auto Keying is active. When you insert a keyframe, Blender records the current value of whichever properties you target at the current frame. So if you're on frame 30 and you insert a keyframe targeting Location only, Blender overwrites the existing location key with the object's new position while leaving the rotation key completely untouched. That's exactly what option C describes, and it's the only action that reliably accomplishes the goal. Option A fails because enabling Auto Keying after you've already made the move doesn't retroactively record anything — Auto Keying only triggers when you move the playhead after making a change while it's active. The move already happened with it off, so nothing gets keyed. Option B is a common misconception: moving to another frame and back does not cause Blender to update or re-record keyframe values. Scrubbing the timeline reads stored keys; it doesn't write new ones. Your viewport change simply gets undone or ignored. Option D confuses handle types with keyed values. Changing a curve handle's type affects interpolation between existing keys — it reshapes the curve's path — but it doesn't replace the stored value at frame 30 with your new viewport position. The study tip here: whenever a question involves updating a specific keyframe, ask yourself whether the action actually writes data. Only an explicit keyframe insertion (or active Auto Keying during a move) writes values — everything else just reads or interpolates.

Question 3

An object has existing F-curves only for X Location and Z Rotation. At a later frame, the animator changes location, rotation, and scale, then inserts keys using the Available keying set.

Which channels receive keys at the later frame?

  1. X Location and Z Rotation receive keys because those are the object's available F-curves. (correct answer)
  2. Every changed transform component receives a key because each differs from its earlier value.
  3. Only X Location receives a key because Available excludes rotational properties by default.
  4. All location and rotation components receive keys, but scale is omitted because it lacks curves.
Explanation: When working with keying sets in Blender, the key distinction to understand is that different keying sets use fundamentally different logic to decide which channels get keyframed. The Available keying set doesn't ask "what changed?" or "what transform type is this?" — it asks "what F-curves already exist for this object?" That's exactly what makes A correct. Because the object already has F-curves for X Location and Z Rotation, the Available keying set inserts keys only on those two channels at the new frame — regardless of what else the animator touched. It's essentially saying: "I'll only write data where animation tracks are already established." B is wrong because it describes behavior closer to the Whole Character or a manual "insert key on changed channels" workflow. The Available keying set doesn't evaluate whether a value changed; it strictly references existing F-curve channels. C introduces a false rule that Available excludes rotational properties by default. Available has no such bias — it would absolutely keyframe Z Rotation here, because a Z Rotation F-curve already exists. The filtering is based on existing curves, not property type. D sounds plausible because scale lacks curves, and that part happens to be true — but D incorrectly claims all location and rotation components receive keys. Only X Location and Z Rotation have existing F-curves, so only those two are targeted. Y Location, X Rotation, etc. are untouched. As a study tip, memorize this phrase: Available = existing F-curves only. On exam questions about keying sets, always identify which keying set is active before reasoning about what gets keyframed.

Question 4

An object is positioned by an active Copy Location constraint. At several sampled frames, an animator wants to key the object's displayed location so that the constraint can later be removed while the sampled positions are retained.

Which keyframe insertion method should the animator use at each sampled frame?

  1. Insert ordinary Location keys, which store the unmodified transform beneath the active constraint.
  2. Insert Visual Location keys, which record transform values derived from the evaluated displayed position. (correct answer)
  3. Key only the constraint influence, which converts each evaluated position into an object transform key.
  4. Insert Delta Location keys, which automatically compensate for the target object's constrained motion.
Explanation: Whenever you see a question about baking or "freezing" constraint-driven motion in Blender, the key concept to keep in mind is the distinction between an object's stored transform and its evaluated (displayed) transform. Constraints don't modify the underlying keyframe data — they modify what you see in the viewport after evaluation. These two values can be completely different, and knowing which one you're recording is critical. Visual Location keys (choice B) are the correct tool here because they sample the object's final evaluated position — exactly what appears in the viewport after the Copy Location constraint is applied — and write those world-space values back as ordinary location keys. Once those keys exist, you can remove the constraint and the object stays exactly where it appeared, frame by frame. Choice A is the classic trap: ordinary Location keys record the object's base transform data, which sits beneath the constraint stack. If the base location is (0, 0, 0), that's what gets keyed — not the constrained position you see on screen. Removing the constraint afterward would cause the object to snap back to that unmodified position, losing all the baked motion. Choice C is incorrect because keying the constraint's influence value only animates how strongly the constraint is applied; it doesn't convert evaluated positions into independent location keys at all. Choice D is a fabrication — Delta Location keys store offsets relative to the object's base transform and have no automatic awareness of or compensation for constraint targets. The study tip to remember: any time you want to "bake" or preserve what you see rather than what is stored, reach for Visual keyframe insertion.

Question 5

An object has location and rotation keys at frames 1, 20, and 40. At frame 20, the animator wants to remove only the location key at the current frame while retaining the location keys at frames 1 and 40 and all rotation keys.

Which property-context command should be applied to Location at frame 20?

  1. Choose Clear Keyframes for Location, which removes every keyframe on the Location channels.
  2. Choose Delete Drivers for Location, which removes any driver expressions controlling the Location channels.
  3. Choose Delete Keyframes for Location, which removes the Location key at the current frame only. (correct answer)
  4. Choose Insert Keyframes for Location with the current value, which overwrites and effectively removes the unwanted key.
Explanation: When working with keyframes in Blender, it's important to understand the distinction between commands that affect a single frame versus those that affect all frames across an entire channel. This question tests whether you know how to surgically remove one keyframe without disturbing the rest of your animation data. In the Graph Editor or Dope Sheet, right-clicking a property and choosing Delete Keyframes targets only the keyframe at the current frame on the selected channel. Since you're parked at frame 20 and apply this to Location, Blender removes exactly that one Location key — leaving the keys at frames 1 and 40 intact, and never touching the rotation channels. That's precisely what the animator needs, making C the correct answer. A is a common trap: "Clear Keyframes" sounds similar but behaves very differently — it wipes every keyframe across the entire Location channel, destroying the keys at frames 1 and 40 as well. B describes deleting drivers, which are expression-based controls unrelated to manually placed keyframes entirely; drivers and keyframes are separate systems, and confusing them is a frequent misconception among newer Blender users. D is logically flawed — inserting a keyframe adds data at frame 20 rather than removing it, so you'd still have an unwanted key sitting there, just with an updated value. A useful rule of thumb: any time you see the word "Clear" in Blender's keyframe menu, think scorched earth — it removes all keys on that channel. "Delete" is the precise, per-frame scalpel you want for targeted removal.

Question 6

A child object has no constraints, and all rotations and scales are neutral. Its local X location is keyed at 00 on frame 1 and 1010 on frame 11. Its parent initially has a constant X location of 55. The parent is later edited so its constant X location becomes 88; the child's keyframes are not edited.

What are the child's world-space X locations at frames 1 and 11 after the parent is edited?

  1. 00 and 1010, because child transform keyframes always store final world-space positions.
  2. 55 and 1515, because the parent's original position was incorporated when the child was keyed.
  3. 33 and 1313, because only the parent's change is added to the child's local key values.
  4. 88 and 1818, because the child keys remain local and are evaluated through the edited parent. (correct answer)
Explanation: Whenever you see a question about parenting in Blender, anchor your thinking to one rule: child keyframes store local-space values, and the parent's transform is applied on top at evaluation time. The world-space result is always computed as child local + parent world. In this scenario, the child's keyed local X values are 00 (frame 1) and 1010 (frame 11). After editing, the parent's world X is 88. Blender re-evaluates those stored local values through the current parent transform every time the scene plays back. So the child's world-space positions become 0+8=80 + 8 = 8 and 10+8=1810 + 8 = 18, making D correct. A is wrong because it assumes keyframes bake world-space positions into themselves. They don't — Blender stores local coordinates, so changing the parent always shifts the child's world result. B reflects what the positions would have been before the edit (0+5=50 + 5 = 5, 10+5=1510 + 5 = 15), as if the original parent value were permanently baked into the keys — but again, keys are local, not world-baked. C adds only the delta of the parent change (+3+3) to the original world positions, which would make sense if keys stored world positions — but since they store local values, the full new parent position (88), not just its change, is what gets applied. A reliable study tip: mentally label every transform as either "local" or "world." In Blender's parent–child system, animation keys live in local space, and the parent chain transforms them into world space at playback — every frame, every edit.

Question 7

A location F-curve passes through the desired values at two bounding keyframes, but its Bezier handles create easing and a slight overshoot between them. The animator needs that segment to move at a constant rate without changing the two keyed endpoint values.

Which edit most directly produces the required motion?

  1. Set the segment to Constant interpolation so the first value is held until the second key.
  2. Set the handles to Auto Clamped so overshoot is reduced while Bezier easing is retained.
  3. Set curve extrapolation to Linear so the motion between the two keys becomes straight.
  4. Set the segment to Linear interpolation so the value changes uniformly between the keys. (correct answer)
Explanation: When working with F-curves in Blender's Graph Editor, the key distinction to understand is the difference between interpolation (how values change between keyframes) and extrapolation (how the curve behaves outside the keyframe range). Questions like this test whether you know the right tool for each job. The scenario requires uniform, constant-rate movement between two existing keyframes — that's a job for Linear interpolation. When you set a segment to Linear (D), Blender draws a straight line between the two keyed values, producing perfectly uniform change over time. The endpoint values remain exactly as keyed, and the Bezier handles are effectively replaced by a straight path — no easing, no overshoot. Choice A is a trap: Constant interpolation does hold the first value, but it then jumps instantly to the second value at the next keyframe. That's a step function, not uniform movement — the opposite of what's needed here. Choice B addresses overshoot but keeps the Bezier easing intact. Auto Clamped handles prevent the curve from exceeding the keyframe values, but the motion still accelerates and decelerates — it won't move at a constant rate. Choice C is the most common misconception. Extrapolation only affects the curve beyond the outermost keyframes — it has no effect on the segment between two existing keys. Setting extrapolation to Linear does nothing to the internal segment behavior. Study tip: Remember the boundary: interpolation controls inside keyframes, extrapolation controls outside. When a question mentions behavior between two keys, always look at interpolation mode first.

Question 8

A location channel has keys at frames 1 and 20. The animator wants the frame-1 value to be held unchanged until immediately before frame 20, while preserving the channel's existing interpolation after frame 20.

Which edit best produces the requested result?

  1. Select only the frame-20 key and set its interpolation mode to Constant.
  2. Select only the frame-1 key and set its interpolation mode to Constant. (correct answer)
  3. Select both keys and set their interpolation mode to Linear.
  4. Select only the frame-20 key and set its handle type to Vector.
Explanation: When working with F-Curves in Blender's Graph Editor, it's crucial to understand that an interpolation mode controls how the curve travels from that key forward to the next one — not how it arrives. In other words, the interpolation setting on a key governs the segment that begins at that key. To hold a value constant from frame 1 until just before frame 20, you need the segment between those two keys to be flat. That means setting the frame-1 key's interpolation to Constant — which is exactly what B does. The Constant mode causes Blender to hold the key's value unchanged until the next keyframe is reached, then jump. Everything after frame 20 is untouched because you only modified the frame-1 key. A is a tempting trap: selecting the frame-20 key and setting it to Constant affects the segment starting at frame 20, not the one before it. This would hold the frame-20 value forward, which is the opposite of what's needed, and it alters behavior after frame 20 — violating the requirement to preserve it. C sets both keys to Linear, which produces a gradual ramp between frames 1 and 20 rather than a held value. That's neither constant nor does it respect the after-frame-20 behavior. D changes the frame-20 key's handle type to Vector, which affects the tangent shape of a Bézier curve — it does not produce a constant hold over the preceding segment. A useful rule of thumb: the key you select owns the segment ahead of it. When you need to control a specific segment, select the key where that segment begins.

Question 9

In the Dope Sheet, an object-level summary key at frame 20 represents simultaneous location, rotation, and scale keys. The animator wants all of those keys moved to frame 28, with no copies remaining at frame 20.

After selecting the summary key, which operation accomplishes the edit?

  1. Press Shift+D and enter 88, which duplicates the selected keys and offsets the copies to frame 28.
  2. Press G and enter 2828, which moves the selected keys to frame 48 because the value is treated as an offset.
  3. Press G and enter 88, which offsets the selected transform keys from frame 20 to frame 28. (correct answer)
  4. Press G and enter −8-8, which offsets the selected transform keys backward to frame 12.
Explanation: Whenever you see a Dope Sheet editing question, focus on two things: what the operation does (move vs. copy) and how values are interpreted (absolute frame vs. relative offset). In the Dope Sheet, pressing G initiates a grab/move operation, and the number you type is treated as a relative offset — it shifts the selected keys by that many frames from their current position. Since the keys sit at frame 20 and you want them at frame 28, the difference is 28−20=828 - 20 = 8. Pressing G then entering 88 moves all selected keys exactly 8 frames forward to frame 28, leaving no copies behind. That makes C the correct answer. A is wrong because Shift+D duplicates the keys — it creates copies at the offset position while leaving originals at frame 20. The question explicitly states no copies should remain at frame 20, so duplication is the wrong tool entirely. B describes a misunderstanding of how G works. Entering 2828 doesn't jump to frame 28 as an absolute destination; it offsets by 28 frames, moving the keys to frame 20+28=4820 + 28 = 48. That overshoots the target significantly. D enters a negative offset of −8-8, which moves the keys backward to frame 20+(−8)=1220 + (-8) = 12, the opposite direction of what's needed. A handy rule to lock in: G = offset, not destination. If you ever need to land on a specific frame, calculate the difference between the target and current frame, then type that delta after pressing G.

Question 10

Two selected transform keys are at frames 88 and 3232. In the Dope Sheet, the pivot is set to Current Frame, the current frame is 2020, and the animator scales the selected key timing by a factor of 0.50.5.

At which frames will the two keys be placed?

  1. Frames 1414 and 2626, because each temporal distance from frame 2020 is halved. (correct answer)
  2. Frames 44 and 1616, because both original frame numbers are multiplied by 0.50.5.
  3. Frames 88 and 3232, because scaling changes keyed values rather than key timing.
  4. Frames 22 and 3838, because each temporal distance from frame 2020 is increased.
Explanation: Whenever you see a question about scaling keys in the Dope Sheet, the critical concept is understanding what the pivot point controls: it defines the origin from which all scaling is measured — not the frame numbers themselves, but the distances from that pivot. When the pivot is set to Current Frame (frame 2020) and you scale by 0.50.5, each key's temporal distance from frame 2020 is halved. Key A sits at frame 88, which is 20−8=1220 - 8 = 12 frames to the left of the pivot. Half of 1212 is 66, so the new position is 20−6=1420 - 6 = 14. Key B sits at frame 3232, which is 32−20=1232 - 20 = 12 frames to the right. Half of 1212 is 66, giving 20+6=2620 + 6 = 26. This confirms A is correct — both keys land at frames 1414 and 2626. B is wrong because it ignores the pivot entirely and simply multiplies raw frame numbers (8×0.5=48 \times 0.5 = 4, 32×0.5=1632 \times 0.5 = 16). That would only be valid if the pivot were at frame 00. C is wrong because scaling in the Dope Sheet absolutely affects key timing (horizontal position), not keyed values — you're thinking of the Graph Editor's value axis. D describes the distances increasing, which would correspond to scaling by a factor greater than 11, not 0.50.5. A reliable tip: always ask yourself "where is the pivot, and what is the distance from it?" before calculating any Dope Sheet scale operation.