- Which statement best describes the result of this action?
Answer: Only that area changes editor type, and the modified arrangement belongs to the current workspace.
Whenever you see a question about Blender's interface, think about the relationship between areas, editors, and workspaces. Each workspace contains its own arrangement of areas, and each area can display any editor type independently.
When you use the editor-type selector in an area's header, you are changing only that specific area's editor — nothing else is affected. The change is local to that area and persists as part of the current workspace's layout. So if you swap a Timeline for a Shader Editor, only that one area updates, and the result belongs to the current workspace's configuration. That makes A correct.
B is wrong because editor changes are never global across workspaces. Each workspace stores its own area layout independently, so swapping an editor type in one workspace has absolutely no effect on other workspaces — even if they happen to contain a Timeline in a similar position.
C is wrong because Blender does not create a new workspace when you change an editor type. New workspaces are only created explicitly, such as by duplicating or adding one from the workspace tab bar at the top. Simply changing an editor type modifies the existing workspace in place.
D is wrong because editor-type changes do not open new operating-system windows. Blender does support separate OS windows (via Window > New Window), but that is a completely distinct action from changing an editor type through the header selector.
A useful rule of thumb: in Blender, changes made inside an area stay inside that area and its workspace — they never ripple outward automatically.
- Which procedure best accomplishes this?
Answer: Split the existing area from an area corner, then change one resulting area's editor type to Outliner.
Whenever you see a Blender question about adding editors to a workspace, think about how Blender manages screen space: every Blender window is divided into areas, and each area holds one editor. To display multiple editors side by side, you split an existing area rather than opening new windows or switching workspaces.
The correct approach — choice D — uses Blender's built-in area-splitting feature. By hovering over any corner of an area, your cursor changes to a crosshair, allowing you to click and drag to split that area into two. Once split, you can click the editor-type icon in the new area's header and select Outliner. Both the 3D Viewport and Outliner now coexist in the same window and the same workspace, exactly as the question requires.
Choice A fails because merging separate operating-system windows is not a Blender feature — Blender windows are independent and cannot be fused together after the fact. Choice B misunderstands workspaces: duplicating a workspace creates an entirely separate tab with its own layout; you cannot display two workspaces simultaneously in one window, so the 3D Viewport and Outliner would still be on different screens. Choice C confuses two unrelated features — maximizing a viewport fills the entire window with just that editor, and the Properties panel context icons switch between property categories (like Object or Material), not editor types.
As a study tip, remember: splitting areas is always the answer when a question asks you to show multiple editors in the same window and workspace. If the question mentions "same window," think area splits first.
- Which action is the most direct correction if the object should remain visible and become selectable again?
Answer: Click the object's selectability icon in the Outliner to toggle it back on.
When working with object visibility and interactivity in Blender, it helps to think of each icon in the Outliner as an independent toggle controlling one specific property. The Outliner displays several per-object icons — including viewport visibility (the eye), render visibility (the camera), and selectability (the cursor symbol). Each toggle is isolated, meaning changing one does not affect the others.
In this scenario, the object is already visible but unselectable because the cursor/selectability icon has been turned off. The most direct fix is simply clicking that same cursor icon in the Outliner to re-enable it — which is exactly what C does. No other settings need to change, and no workarounds are required.
A is a red herring. Switching the Outliner from View Layer mode to Blender File mode changes how the hierarchy is displayed, not the actual selectability state of the object. The toggle is still off regardless of which mode you're viewing.
B describes toggling the viewport visibility icon (the eye) off and on, which controls whether the object appears in the viewport at all — not whether it can be selected. Cycling this icon would briefly hide the object but would leave the selectability problem completely untouched.
D is a distractor built around a real but unrelated feature. Pinning a data-block in the Properties Editor is useful for inspecting specific data, but it has no effect on an object's selectability in the viewport.
As a study tip, remember that Blender's Outliner icons are independent switches — always match the icon's symbol to the property it controls rather than assuming toggling any icon will fix everything.
- What is the expected interface behavior?
Answer: The Properties Editor area is maximized within the Blender window until the command is toggled again.
When working with Blender's multi-panel interface, it helps to distinguish between three different "size-changing" operations: maximizing an area within the Blender window, making Blender itself fill the OS screen, and splitting or duplicating areas. Keeping these concepts separate will help you navigate questions like this one.
Pressing Ctrl+Spacebar with your cursor over any editor triggers Blender's Maximize Area toggle. The targeted editor — in this case the Properties Editor — expands to fill the entire Blender window, pushing all other editors out of view. Pressing the shortcut again restores the original layout. This makes D the correct answer: the Properties Editor is maximized within the Blender window until you toggle it off.
A is wrong because Ctrl+Spacebar doesn't selectively expand individual regions (like panels or sub-sections) inside an editor while leaving neighboring editors intact — it affects the entire editor area as a whole. B describes Alt+F11 (or the Window menu's "Toggle Window Fullscreen"), which sends the Blender application into OS-level fullscreen, hiding the title bar and taskbar entirely — a completely different command and outcome. C describes opening a new OS window (achievable through Window → New Window), which keeps both windows simultaneously visible; Ctrl+Spacebar does nothing of the sort.
A useful memory anchor: think of Ctrl+Spacebar as giving one editor a temporary "solo" moment on stage — everything else steps aside, but nothing truly leaves the building. On the Blender exam, watch for distractors that confuse area maximizing, fullscreen mode, and new window operations, as they are frequently swapped.
- Which interpretation of the resulting interface is correct?
Answer: The area remains a Properties Editor but changes to the active mesh's Modifiers context.
When working in Blender's Properties Editor, it's essential to understand that the editor is a single, unified space with multiple contexts — not a collection of separate editors. The vertical tab icons on the left (object, modifier, material, etc.) are all context-switchers within that one editor. Clicking any of them simply changes what that editor displays, not the editor type itself.
That's exactly what happens here. When you click the wrench icon — the Modifiers context tab — the Properties Editor stays a Properties Editor, but it now displays the modifier stack for the active mesh. This makes B the correct interpretation: the area remains a Properties Editor, just updated to show the Modifiers context.
A is wrong because the Properties Editor doesn't transform into a new, dedicated editor type when you switch contexts. Blender has no standalone "Modifier Editor" as a separate area type — modifiers live as a context within Properties. C mistakes context-switching for tool-switching, which are entirely unrelated systems; your active tool lives in the toolbar and is unaffected by Properties navigation. D is particularly far off — clicking a tab in one editor has no effect on your workspace layout or any other editor in the interface. Blender's areas are independent; actions in one don't cascade to others.
A helpful study habit: always ask yourself what layer of Blender's interface a change operates on — editor type, context tab, active tool, or workspace. These are four distinct levels, and exam questions frequently blur them to test whether you understand the boundaries.
- Which Outliner configuration is most appropriate for this task?
Answer: Change the Outliner's display mode to Blender File and browse the categorized data-blocks.
When working with Blender's Outliner, the key distinction to understand is what data is being displayed: the current View Layer's object hierarchy, or the entire .blend file's data-block library. This question tests whether you know which display mode gives you file-wide visibility without being restricted to what's active or visible in the scene.
Blender File mode — answer B — is precisely designed for this. It organizes every data-block in the .blend file into categories (meshes, materials, textures, etc.), regardless of whether those data-blocks are linked to any object in the current View Layer or even any scene. A material with no object using it will still appear here, making it the correct tool for the described task.
Answer A fails because View Layer mode only shows objects that belong to the active View Layer's collection hierarchy. Disabling viewport filters changes which object types are visible, not whether unlinked or orphaned data-blocks appear — that material simply won't show up at all.
Answer C is similarly limited: Scenes mode organizes data by scene and collection, so it still won't surface a material that isn't attached to any object in the hierarchy. Expanding only the active collection makes this even more restrictive.
Answer D is a clever trap. Orphan Data mode does list unused data-blocks, but its purpose is specifically to surface data-blocks with zero users — it won't show materials that are used elsewhere in the file. The question asks for general file-wide browsing, not a filter for unused assets.
Remember: Blender File mode = full file inventory; Orphan Data mode = unused assets only. Keep that distinction sharp.
- Which action most directly reveals the active mesh in the Outliner without changing its collection membership?
Answer: Place the pointer over the Outliner and invoke Show Active or View Selected.
When working with complex scenes in Blender, the Outliner and 3D Viewport are linked — selecting an object in one context highlights it in the other. The key concept here is revealing an already-selected object within the Outliner's hierarchy without restructuring the scene.
Placing your pointer over the Outliner and pressing the shortcut for Show Active (or View Selected, typically the period key on the numpad or via the View menu) automatically scrolls the Outliner to the active object and expands any collapsed parent collections needed to display it. This is exactly what A describes — it surfaces the mesh in the hierarchy non-destructively, preserving all collection memberships.
B is a trap because Frame Selected (also often the period key) is a 3D Viewport operation. It recenters the viewport camera around the selected object, which has nothing to do with the Outliner hierarchy. C changes the Outliner's display mode to Blender File, which reorganizes how data is presented globally — it doesn't navigate to or highlight your active object, and it may obscure your collection-based workflow. D is a red herring entirely: double-clicking to rename in the 3D Viewport edits the object's name label but does nothing to reveal or navigate the Outliner tree.
A is correct because it is the only option that both targets the Outliner and uses a built-in navigation command designed specifically for this workflow.
As a study tip, remember that Blender's shortcut behavior is context-sensitive — the same key pressed over different editors often triggers different (but parallel) actions. Knowing which editor your pointer is over is frequently the deciding factor on exam questions like this.
- What happened to the entries that are no longer displayed?
Answer: They remain in the file but are temporarily excluded from the Outliner's filtered display.
When working with Blender's Outliner, it helps to understand the difference between display filtering and actual scene changes. The Outliner is essentially a panel that lists your scene's contents — searching or filtering it only affects what you see in that panel, not what actually exists in your file or scene.
Typing "bolt" into the Outliner's search field triggers a display filter: Blender compares every entry's name against your search term and temporarily hides anything that doesn't match. The filtered-out objects remain exactly where they are — still part of their collections, still present in the scene, still renderable. The moment you clear the search field, every entry reappears. This makes C the correct answer.
A is wrong because Blender doesn't automatically reorganize your collections based on a search. No objects are moved anywhere — the collection hierarchy is completely untouched. B describes what happens when you use the visibility toggles (the eye or camera icons) in the Outliner, which genuinely hide objects from viewports or renders. Searching does none of that. D describes unlinking or deleting scene instances, which is a deliberate user action that affects data-blocks — a search filter has no destructive effect whatsoever.
A useful mental model: think of the Outliner search like a coffee filter. The filter only changes what pours through into your view; it doesn't remove the coffee grounds from existence. On Blender exam questions, whenever an action involves the Outliner's search or filter tools, ask yourself whether the action is destructive (changes scene data) or non-destructive (changes display only). Filtering is always non-destructive.
- Which outcome is most consistent with how workspaces function?
Answer: The geometry changes remain, while the screen arrangement changes to the Layout workspace's saved layout.
When studying Blender workspaces, the key distinction to keep in mind is that workspaces control the screen layout — which editors are visible and how they're arranged — but they all share the same underlying scene data. Think of workspaces like different camera angles in a film studio: changing cameras doesn't alter the set itself.
This is exactly why A is correct. When you switch from the Modeling workspace to the Layout workspace, Blender rearranges the interface to show the editors saved with that workspace (such as a full 3D Viewport without extra panels), but your mesh edits are fully preserved. The geometry lives in the scene, not in any particular workspace.
B describes a completely false model of how workspaces work. Workspaces are not sandboxed environments with independent scene versions — they're just saved UI configurations. Geometry changes are never "owned" by a workspace. C gets the directionality backwards: when you switch workspaces, the entire screen arrangement changes, not just the tools inside an existing layout. Editors themselves aren't swapped in place — the whole panel configuration is replaced. D introduces a duplication concept that simply doesn't exist in Blender's workspace system. Workspaces don't fork or copy scene data; there is always one shared mesh, accessible from any workspace.
A useful rule of thumb: in Blender, workspaces = UI configuration, scene = data. These two things are independent. Any question that implies workspaces can isolate, store, or duplicate scene data is describing a feature that doesn't exist.
- What should the user expect immediately after selecting Key?
Answer: Key becomes active, but the pinned Properties Editor continues displaying Housing-related properties.
When working with Blender's interface, it helps to understand that the Properties Editor pin and scene selection are completely independent systems. Pinning the Properties Editor tells it to stay locked on a specific object's data regardless of what happens elsewhere in the scene — it does not affect which objects are active or selected.
So when you pin Housing's properties and then click Key in the Outliner, two things happen simultaneously: Key becomes the active object (selection always works normally), but the Properties Editor ignores that change and keeps displaying Housing's data. This is exactly what A describes, making it the correct answer.
B is wrong because pinning exists precisely to prevent the automatic switch it describes. If the Properties Editor unpinned itself whenever you selected something new, the pin feature would be pointless.
C contains a plausible-sounding but completely fabricated behavior. Pinning has no effect on scene selection whatsoever — it only affects what the Properties Editor displays. Housing does not stay "active" just because its properties are pinned.
D introduces the idea of "accumulating" active objects, which isn't how Blender works at all. Blender supports multi-selection, but clicking in the Outliner without modifier keys simply changes the active object — it doesn't stack selections. Pinning adds nothing to this behavior.
A useful tip: on the Blender exam, watch for questions that conflate display state with scene state. Pinning, panel layouts, and editor configurations affect what you see, not what is actually selected or active in the scene. Keep those two layers separate in your thinking.
