- Which workflow correctly adds the new root bone to the armature's rest structure?
Answer: Enter Edit Mode and add a bone at the 3D Cursor without parenting it to an existing bone.
When working with armatures in Blender, the key distinction to keep in mind is which mode controls the armature's rest structure. Edit Mode is where bones are permanently added, removed, repositioned, and parented — it defines the armature's actual skeleton. Pose Mode, by contrast, only manipulates temporary poses layered on top of that structure.
To add a new, independent root bone to an existing armature, you select the armature, enter Edit Mode, and use Add → Bone (Shift+A). Blender places the new bone at the 3D Cursor by default. Because you don't parent it to any existing bone, it becomes a root bone — a chain with no parent — exactly what the scenario requires. This is why A is correct.
B is wrong because you cannot add new bones in Pose Mode at all. Pose Mode manipulates existing bones through rotations, translations, and constraints. Disabling inheritance affects how a bone receives parent transforms, but it doesn't make a new bone or alter the rest structure.
C is a common trap. Adding an armature object in Object Mode creates a separate, new armature object — it does not insert bones into the already-selected armature. You'd end up with two distinct armature objects, violating the condition that existing bones remain in the same armature.
D is wrong because Pose Mode duplication only creates pose-level copies that don't persist as real structural bones. Clearing transforms would just reset a pose, not establish a new root in the rest skeleton.
As a study tip: whenever a question involves permanently changing bone structure, your answer almost always lives in Edit Mode.
- What is the resulting armature structure?
Answer: Three sequentially connected bones replace the original span and form a chain.
When working with armatures in Blender's Edit Mode, it helps to understand what "cuts" actually do geometrically. Subdividing a bone works similarly to subdividing a mesh edge — each cut adds a new point along the bone's length, splitting it into additional segments.
With Number of Cuts set to 2, you are inserting two points along the original bone, which divides it into three segments. Those three segments become three bones automatically connected head-to-tail, forming a continuous chain. This is exactly what C describes — three sequentially connected bones replacing the original span.
A is wrong because it confuses "Number of Cuts" with "Number of Bones." The setting controls how many times the bone is sliced, not the final bone count. Two cuts produce three bones, not two.
B describes disconnected bones with a shared parent, which would be the result of duplicating a bone or using a different tool entirely. Subdivide specifically creates a chained hierarchy, not a fan of siblings parented to the original.
D suggests that each cut doubles the bone count, implying some kind of multiplicative logic. That's not how subdivision works — the relationship is simply bones=cuts+1. Two cuts yield three bones, not four.
The key formula to memorize is: bones = cuts + 1. This mirrors how cutting a rope twice gives you three pieces. On Blender exam questions involving Subdivide, always ask yourself how many cuts are being made, then add one to find the resulting bone count. - What is the most efficient hierarchy edit?
Answer: Parent the thigh to the pelvis with Keep Offset, leaving the shin and foot relationships unchanged.
When working with armature hierarchies in Blender, the key principle is that motion inheritance flows downward through a chain — a child inherits its parent's transforms, and that inheritance cascades automatically to all descendants. This question tests whether you understand that parenting the root of an existing chain is all you need to propagate motion through every bone below it.
Here's the logic: the leg chain is already built — thigh → shin → foot. The shin is already a child of the thigh, and the foot is already a child of the shin. If you parent the thigh to the pelvis using Keep Offset (which preserves current rest positions), the pelvis motion flows into the thigh, then automatically cascades down to the shin and foot through the existing relationships. One edit, complete inheritance for all three bones. That's option C, and it's the most efficient solution.
Option A fails because inheritance only flows downward, never upward. Parenting the foot to the pelvis would make the foot a direct child of the pelvis, breaking the chain logic entirely and leaving the thigh and shin unaffected.
Option B is redundant and destructive — parenting each bone separately to the pelvis would dismantle the thigh → shin → foot chain, replacing a clean hierarchy with three disconnected direct children of the pelvis. You'd lose the chain behavior entirely.
Option D introduces unnecessary steps. Clearing the shin and foot parents destroys the very chain you're trying to leverage, and "preventing double motion" is not a concern when inheritance is simply cascading through a proper hierarchy.
As a study tip: whenever a chain already exists, only parent its topmost root to the new parent — let the cascade do the rest.
- How should the upper-arm bone be parented to satisfy both requirements?
Answer: Parent it using Keep Offset so it inherits motion without snapping to the clavicle tail.
When parenting bones in Blender, you need to distinguish between two parenting modes: Connected and Keep Offset. Connected physically snaps the child bone's head to the parent bone's tail, merging them into a continuous chain. Keep Offset preserves each bone's current position while still establishing the parent-child relationship, meaning the child inherits rotations and transformations without any positional snapping.
In this scenario, the upper-arm bone's head sits at the shoulder, while the clavicle's tail sits near the neck — two different locations. You need the upper arm to move with the clavicle (inheriting its motion) but without relocating its head to the clavicle's tail. That's exactly what B, Keep Offset, accomplishes: it creates the parent-child link while respecting the spatial gap between the two bones.
A is the trap most students fall into. Connected does parent the bone, but it forcibly snaps the upper arm's head to the clavicle's tail, destroying your carefully placed shoulder position — the opposite of what the question requires.
C is incorrect because the Deform property controls whether a bone deforms mesh geometry; it has no effect on how motion propagates between bones. Leaving a bone unparented means no hierarchical relationship exists at all.
D is incorrect because joining two bones merges them into a single bone, eliminating both original pivots entirely. You'd lose the independent control the rig requires.
Your study tip: whenever a question mentions two bones that are already correctly positioned but need a parent-child link, that phrasing is a signal for Keep Offset — you're preserving positions, not connecting endpoints.
- After extruding the first child, what should the artist do to create the second child with the intended hierarchy?
Answer: Reselect the torso bone's tail and extrude again, producing another connected child of the torso.
When building branching bone hierarchies in Blender's Edit Mode, the key principle to remember is: the parent of a new bone is determined by which bone's tail is selected at the moment you extrude. Understanding this lets you create any branching structure deliberately.
In this scenario, the torso bone's tail sits at the shoulder joint. After extruding once to create the arm bone (first child), the artist needs a second child that also originates from that same shoulder joint — meaning it also needs the torso as its parent. To do this, the artist should reselect the torso bone's tail and extrude again. Blender will create a new bone rooted at that same point, automatically parented to the torso, giving you the branching fork you need. That's why B is correct.
A is a tempting trap: selecting the first child's tail and extruding would create a grandchild of the torso, extending the arm chain further — not a second branch off the shoulder. The parent would be the arm bone, not the torso.
C is wrong because duplicating bones in Pose Mode doesn't replicate Edit Mode hierarchy relationships properly. Pose Mode duplication is not the right tool for building skeleton structure.
D is wrong because subdividing the first child creates an intermediate bone within that chain, then clearing its parent orphans a segment — a messy workaround that doesn't achieve the intended clean branching hierarchy.
Study tip: When you need a branching skeleton, always ask yourself "whose tail am I extruding from?" — that bone becomes the parent of whatever you create next.
- Which workflow most directly creates the required hierarchy?
Answer: In Edit Mode, select the existing tail, extrude to the ankle, then extrude again to the toes.
When building armature hierarchies in Blender, the key principle is that bones extruded from an existing bone automatically inherit a parent-child relationship — the new bone's head connects directly to the parent's tail, forming a seamless chain without any manual parenting steps.
This is exactly why A is correct. Starting in Edit Mode with your existing hip-to-knee bone, selecting the tail (knee point) and extruding creates a new bone whose head is welded to that tail — Blender automatically parents it to the original bone. Extruding again from the ankle repeats this, giving you three bones (hip→knee, knee→ankle, ankle→toes) in one continuous, properly parented chain. The workflow is fast, precise, and non-destructive.
B is fundamentally flawed because joining separate armature objects in Object Mode does not create parent-child relationships between the bones inside them — you'd end up with three unconnected bones sharing one armature object, requiring manual re-parenting afterward.
C makes a similar mistake. Adding independent bones in Edit Mode places them in the armature without any hierarchy. Enabling Deform only controls whether a bone deforms mesh geometry — it has nothing to do with establishing parent-child connections between bones.
D misuses Pose Mode entirely. Duplicating pose bones creates copies within the same pose layer but does not build bone hierarchy, and "Apply Pose as Rest Pose" bakes current pose rotations into the rest state — it isn't a rigging tool for creating new bones.
A useful study rule: in Blender, extrude = connect. Whenever you need chained bones, extrusion in Edit Mode is always faster and more reliable than joining or manually parenting separate bones.
- Which selection and parenting setup will produce the intended result?
Answer: Make the palm active, then use Keep Offset parenting for the selected finger roots.
When parenting bones in Blender's Edit Mode, two decisions always work together: which bone is active and which parenting method you use. The active bone is the parent; the selected (but non-active) bones become the children. Keep that hierarchy in mind before choosing a method.
Here, you want the palm to become the parent of the three finger roots without moving any bones. Making the palm active and using Keep Offset parenting accomplishes exactly this — Blender establishes the parent-child relationship while preserving each finger root's current world position. That's option C, and it's the correct answer.
Option A fails on two counts: making a finger root active would make it the parent, not the palm, inverting the intended hierarchy. Connected parenting would also snap the child bone's head to the parent's tail, which would displace all the finger roots. Option B corrects the active bone mistake — palm active is right — but Connected parenting is still wrong here. Connected mode physically attaches the child's head to the parent's tail, meaning the finger roots would snap to the palm's tip, breaking their positions entirely. Option D is backwards: making "all finger roots active simultaneously" is not how Blender works — only one bone can be active at a time, and regardless, having a finger root active would again flip the parent-child relationship.
A quick rule to memorize: active = parent, selected = children. When you need to preserve existing bone positions after parenting, always reach for Keep Offset. Connected parenting is only appropriate when you specifically want bones to physically link end-to-end.
- What is the expected result of selecting the left chain and using Symmetrize in Edit Mode?
Answer: A mirrored right chain is created with .R names and corresponding parent-child relationships.
When you see a question about Symmetrize in Blender's Edit Mode, think about what this tool is specifically designed to do: create a true mirror of selected bones across the armature's local X axis, preserving all relationships and automatically handling naming conventions.
Symmetrize reads your selected bones, mirrors their positions to the opposite side of the X axis, generates new bones with the corresponding suffix (.L becomes .R and vice versa), and reconstructs the parent-child hierarchy among the mirrored bones. This makes A the correct answer — you get a complete, properly parented right-side chain with .R suffixes, ready to use without any manual cleanup.
B is wrong because Symmetrize absolutely does copy parent-child relationships. The resulting chain isn't a loose collection of disconnected bones — upper_arm.R will parent forearm.R, which will parent hand.R, mirroring the original structure precisely.
C describes a move operation, not a mirror. Symmetrize never relocates or deletes your original bones. The left chain stays exactly where it is; Symmetrize only creates new geometry on the opposite side.
D describes what a plain duplicate (Shift+D) does when names conflict — Blender appends numeric suffixes like .001. Symmetrize is a specialized tool that understands the .L/.R naming convention and uses it intentionally, so no numeric suffixes appear.
For the exam, remember this pattern: Symmetrize = mirror + rename + reparent, all in one step, non-destructively. It leaves originals untouched and generates a complete, usable chain on the other side.
- Which correction preserves the hierarchy while removing only the endpoint connection?
Answer: Use Disconnect Bone to convert the relationship to an offset while keeping the parent.
When working with armature hierarchies in Blender, it helps to distinguish between two separate concepts: parenting (which bone controls another's transforms) and connection (whether a child bone's head is physically locked to its parent's tail). These can exist independently, and questions like this test whether you know how to modify one without disturbing the other.
The "Connected" checkbox in a bone's relationship settings locks the child's head to the parent's tail, but removing that lock does NOT require breaking the parent-child hierarchy. Disconnect Bone (found in the Armature menu in Edit Mode, or via Alt+P > Disconnect Bone) does exactly this: it clears the Connected flag, freeing the child bone's head to be repositioned anywhere while fully preserving transform inheritance. This is why B is correct — you keep the parent, keep the hierarchy, and gain positional freedom for the gap the artist needs.
A is the most tempting wrong answer, but Clear Parent removes the hierarchy entirely, meaning the forearm would no longer inherit rotations or transforms from the upper arm at all — the opposite of what the question asks. C is a red herring: the Deform property controls whether a bone influences mesh vertices, not its positional relationship to its parent; disabling it does nothing to unlock the head. D is extreme overkill — separating the bone into another armature object introduces object-level parenting, which is far more complex and breaks the native bone hierarchy system unnecessarily.
Remember: in Blender, "parent" and "connected" are independent toggles. When a question asks you to preserve inheritance but remove the endpoint lock, think disconnect, not unparent.
- Which change satisfies the requirement without breaking the bone hierarchy?
Answer: Disable Deform on the control bone while retaining its existing parent and children.
Whenever you see a question about armature rigs in Blender, separate two concerns in your mind: hierarchy (which bones control which) and deformation (which bones actually move mesh vertices). These are independent settings, and confusing them is exactly the trap this question sets.
Each bone in Blender has a Deform checkbox in its Bone Properties panel. Disabling it tells Blender's skinning system to ignore that bone when calculating vertex weights, meaning the mesh won't deform based on it — but the bone itself still exists, still has its parent, and still passes transforms down to its children. That's precisely what option D does: the control bone remains in the hierarchy, the hand mechanism beneath it still receives its motion, and the mesh is left untouched by that specific bone.
Option A breaks the hierarchy entirely by deleting the control bone, which would disconnect the hand mechanism from the torso — the opposite of what's needed. Option B misunderstands the direction of the fix; clearing the parent severs the control bone from the torso, destroying the very chain you're trying to preserve. Option C exploits a common misconception: disconnecting a bone changes its visual attachment point, not whether it influences vertices — a disconnected bone with Deform enabled still deforms the mesh.
The key takeaway: when a rig needs a "passthrough" bone that controls motion without touching the mesh, your first instinct should be to reach for the Deform toggle, not restructure the hierarchy. On rigging questions, always ask yourself whether the issue is about transform flow or mesh influence — they're controlled separately in Blender.
