- Which setting in Model A should be checked first to determine why Model B is absent from the campus host?
Answer: Whether Model B is configured as Overlay rather than Attachment in Model A.
When working with nested Revit links, the key concept to understand is how Revit controls whether a linked model "passes through" to higher-level host models. This is governed by the Attachment vs. Overlay setting, and recognizing this distinction is essential whenever you see a question about links that appear in one model but disappear in another.
In Revit, a linked model set to Attachment will travel with its parent model when that parent is linked elsewhere — it becomes visible in the grandparent host. A link set to Overlay, however, stays local: it displays when you open the model directly, but it does not propagate to any host that links that model. This perfectly explains the scenario described — Model B is visible inside Model A but absent in the campus host. Checking the Overlay/Attachment setting in Model A's Manage Links dialog is the correct first step, making B the right answer.
A is a distractor about worksharing. Workset visibility affects whether elements display within a single model, not whether a nested link propagates to a host model. C addresses coordinate positioning — Origin to Origin vs. By Shared Coordinates affects where a link lands, not whether it appears at all in a higher-level host. D describes linked view display settings, which control category visibility within views but have no bearing on whether a nested link is transmitted to a campus model.
As a study tip: whenever a Revit exam question describes a link that "disappears" when hosted elsewhere, immediately think Overlay vs. Attachment — it's the most common cause of missing nested links on both the exam and in real projects.
- Which correction best uses the coordination information that the teams actually established?
Answer: Relink using Project Base Point to Project Base Point so the agreed base-point locations align.
Whenever you see a Revit linking question, your first move should be to identify what coordinate information was actually established between the teams. That determines which link placement method is appropriate.
In this scenario, both teams placed their project base points at the same agreed grid intersection — that's the specific coordination they set up. They did not run the Acquire/Publish Shared Coordinates workflow, so no shared-coordinate relationship exists between the files. With that framework in mind, the right fix becomes clear: relinking using Project Base Point to Project Base Point (C) directly honors what the teams agreed on. Revit places the linked model so that its project base point lands exactly on the host file's project base point — aligning both files at that agreed grid intersection.
A is wrong because Center to Center positions files based on the geometric center of all model elements, which has nothing to do with the grid intersection the teams carefully coordinated. Model extents shift as design evolves, making this method unreliable.
B is the most tempting trap: Origin to Origin does not align project base points. It aligns each file's internal origin (0,0,0), which the question explicitly tells you are in different locations — explaining exactly why the model appears offset.
D is wrong because By Shared Coordinates requires the Acquire or Publish Shared Coordinates workflow to have been completed. Matching base-point positions alone don't create a shared-coordinate relationship in Revit's data model.
Your study tip: memorize that Origin to Origin = internal origins, Project Base Point to Project Base Point = PBPs, and Shared Coordinates = requires the full Acquire/Publish workflow. Confusing these three is one of the most common mistakes on coordination questions.
- Which Revit Link display configuration is the best way to show the framing as it appears in the structural team's plan?
Answer: Use By Linked View and select the structural Level 2 framing plan.
Whenever you see a question about displaying linked model elements that aren't visible in the host view, think about Revit Link display modes — specifically how each mode controls whose view settings govern what you see.
In Revit, when a model is linked, you can control its visibility through three modes: By Host View (linked model inherits the host view's settings), By Linked View (linked model displays exactly as it appears in a chosen view from that file), or Custom (you manually override individual graphic settings). Here, the beams are missing because the architectural host view's cut plane and view range don't capture the structural framing — but the structural team's Level 2 framing plan is already configured correctly to show those beams. The cleanest solution is By Linked View, where you select the structural framing plan as the reference. Revit then renders the linked model exactly as that source view displays it, beams included, without touching the host view at all. That's why B is correct.
A is wrong because it requires modifying the host view range — exactly what the architect wants to avoid, and it could disrupt architectural documentation. C is wrong because the Custom mode can control graphics like color and line weight, but it does not resolve a visibility issue caused by view range; the beams would still be cut out of the display. D is wrong because changing the host view discipline to Structural would alter the host view's behavior broadly, affecting the architectural documentation and again modifying the host view the architect wants to preserve.
As a study tip: remember that By Linked View is your go-to whenever you need a linked model to reflect another team's view configuration without compromising your own host view settings.
- Which workflow most directly establishes the required coordinate relationship while keeping the civil model as the coordinate authority?
Answer: Select the civil link and use Acquire Coordinates to transfer its shared coordinate system to the host.
Whenever you see a question about shared coordinates in Revit, focus on the direction of information flow: which model is the authority, and which model is receiving the coordinate system?
In this scenario, the civil model already has the correct survey coordinate system, and the building (host) model needs to adopt it. Acquire Coordinates (answer A) does exactly this — you select the linked civil file, run Acquire Coordinates, and Revit pulls the linked model's shared coordinate system into the host. After this, the host's survey point, spot coordinates, and true north orientation all reflect the civil model's system. The civil model remains unchanged, preserving it as the coordinate authority. This is the correct and most direct workflow.
Answer B describes Publish Coordinates, which is the opposite direction — it pushes the host's coordinate system into the linked file, overwriting the civil model's carefully established survey data. This is exactly what you don't want here.
Answer C, moving the project base point manually, doesn't establish shared coordinates at all. The project base point controls the internal origin offset, not the shared coordinate system, and this approach would require manual input of survey values rather than transferring them systematically from the civil model.
Answer D, relinking Center to Center, changes only the insertion point of the link instance. It doesn't transfer any coordinate system data, and "recording the position as a shared site" is not a formal Revit workflow for establishing shared coordinates.
A useful memory rule: Acquire = receive (host gets coordinates from the link); Publish = send (host gives coordinates to the link). Know this direction, and you'll consistently answer coordinate-sharing questions correctly.
- What should the user do to restore the established coordinated position most reliably?
Answer: Remove and relink the structural model using the By Shared Coordinates positioning option.
When working with linked models in Revit, positioning method is everything. Revit offers several options when linking a file — Origin to Origin, Center to Center, By Shared Coordinates, and Auto - Internal Origin. Each means something different, and confusing them is one of the most common coordination mistakes on real projects.
Here's the core concept: Shared Coordinates is Revit's mechanism for remembering an agreed-upon real-world position between two models. When both teams have properly published and acquired shared coordinates, that relationship is stored. The By Shared Coordinates positioning option tells Revit to place the linked file exactly where the shared coordinate system says it should go — restoring the established relationship regardless of where each file's internal origin sits.
That's why A is correct. Relinking with By Shared Coordinates reads the shared coordinate data already embedded in both files and places the structural model in its intended position. No manual adjustment needed.
B is wrong because reloading preserves the current (incorrect) Origin to Origin placement — that's exactly what caused the displacement in the first place. Reloading doesn't change positioning logic.
C is wrong because manually dragging a link to match origins is imprecise and error-prone. Even if you visually align base points, you're guessing rather than using the coordinate data the teams already established.
D is wrong because Center to Center positions the link based on bounding box centers, which have no relationship to the shared coordinate agreement. Pinning it just locks that incorrect position in place.
Your study tip: whenever a question involves restoring a previously coordinated position between linked models, By Shared Coordinates is almost always the answer — it's the only option that leverages the actual coordinate handshake between files.
- Which action most directly addresses the visibility problem without changing the link's placement or display overrides?
Answer: Open the dedicated link workset through the Worksets dialog and regenerate the active view.
Whenever you see a Revit visibility problem that affects only one user while others see the content normally, your first instinct should be to think about worksharing — specifically, workset visibility — rather than view settings or link configurations, since those would affect everyone equally.
In a workshared model, each workset can be opened or closed independently when a user opens their local file. When a workset is closed, all objects on it are hidden from view for that user, regardless of Visibility/Graphics settings or whether the link shows as "Loaded" in Manage Links. The link appearing as Loaded simply means Revit knows where the file is — it doesn't mean the instance is visible if its hosting workset is closed. Opening the workset through the Worksets dialog restores the instance to the model for that session, and regenerating the active view refreshes what's displayed. That makes D the most direct fix.
A is wrong because switching between Attachment and Overlay affects whether the link is visible when that model is itself linked into another — it has no bearing on workset-based visibility for a direct user. B is a red herring; reloading with Origin to Origin re-positions the link relative to a coordinate system, which solves placement drift, not a visibility gap caused by a closed workset. C would be valid if the Revit Links category were turned off in Visibility/Graphics, but that would affect all users equally — not just one — making it the wrong diagnosis here.
As a study tip: when a Revit problem is isolated to a single user in a workshared environment, always check worksets before touching view settings or link management.
- What is the most efficient first test for an instance-specific visibility override?
Answer: Activate Reveal Hidden Elements and check whether the missing link instance was hidden in the view.
When two instances of the same link type behave differently in a view — one visible, one not — you're dealing with an instance-specific override rather than a type-level or file-level issue. The key diagnostic framework here is Revit's visibility hierarchy: file status → link type settings → view-level type overrides → instance-level overrides. Since both instances share the same loaded link type, the problem must live at the instance level.
Reveal Hidden Elements (C) is your most efficient first test because it directly exposes whether the missing instance was manually hidden in the view using Hide in View → Elements. This is a one-click operation that immediately answers the question without changing any settings. If the instance appears highlighted in Reveal Hidden Elements mode, you've found your culprit and can unhide it instantly.
Answer A is a category-level intervention — adjusting Visibility/Graphics for the linked model affects all instances of that link type in the view equally. Since the other instance is already visible, categories aren't the issue, making this unnecessary and misdirected. Answer B targets the link's loaded status, but Manage Links already confirms the file is Loaded, so reloading it addresses a problem that doesn't exist here. Answer D changes the Overlay/Attachment reference setting, which controls how the link behaves in nested hosting scenarios, not instance visibility within a single view — this is a completely unrelated setting.
As a study tip, remember that in Revit troubleshooting questions, always match the scope of the problem to the scope of the fix. Instance-specific symptoms call for instance-specific diagnostics first — Reveal Hidden Elements is always your quickest instance-level check.
- Which setting should be reviewed first to resolve this phase-dependent linked-model visibility issue?
Answer: The phase mapping between the host phases and the linked model's differently named phases.
Whenever you see a question about linked models behaving differently across phases, your first instinct should be to investigate how Revit maps phases between the host file and the linked file. Revit's phase filters control element visibility based on phase status (new, existing, demolished, temporary), but this system only works correctly when Revit knows which phases in the linked model correspond to which phases in the host.
When a linked model uses different phase names than the host — here, "Existing Conditions" and "Proposed Work" versus the host's "Existing" and "New Construction" — Revit cannot automatically align them. The Phase Mapping settings, found in the Visibility/Graphics Overrides dialog under the Revit Links tab, let you specify which linked phase should appear when viewed through each host phase. If this mapping is unconfigured or mismatched, elements from the linked model may appear in one host phase but vanish in another, which is exactly the symptom described.
Answer A is a distractor involving path type (Absolute vs. Relative), which affects whether Revit can locate the file — not how it displays by phase. Since the link is confirmed as loaded, path type is irrelevant here. Answer B relates to positioning methods like Auto - Origin to Origin or Shared Coordinates; these affect where the model appears in space, not phase-dependent visibility. Answer C involves project base points, which is similarly a spatial positioning concern, not a visibility-by-phase issue.
As a study tip: anytime a linked model is visible in one phase but not another, and the link is confirmed loaded and categories are on, go straight to phase mapping — it's the most common culprit and easy to overlook.
- What is the most appropriate next step to restore the link in the floor plan without affecting unrelated views?
Answer: Edit the assigned view template and enable the link under the Revit Links category.
When a linked file appears in some views but not others, and you can't edit Visibility/Graphics directly in that view, your first instinct should be to look at the view template. View templates override per-view settings, which is exactly why the floor plan's V/G settings are grayed out — the template is controlling them.
The fix is straightforward: edit the assigned view template and ensure the linked file is checked under the Revit Links category. Once you enable it there, every view using that template will reflect the change — but views using different templates or no template remain unaffected. This is precisely what the question asks for: restoring visibility without impacting unrelated views. Option A is the correct path.
Option B is a red herring. Reloading the link addresses file path or synchronization issues, but the passage already tells you the link is Loaded in Manage Links. There's no file-access problem to solve here.
Option C misunderstands where visibility is controlled. You don't open the linked model to fix its visibility in the host's floor plan. Category visibility in the linked model doesn't govern whether the link appears in the host's views — that's controlled by the host's V/G settings or its view template.
Option D confuses link type (Overlay vs. Attachment) with visibility. That setting governs whether a link propagates into nested host situations, not whether it appears in a specific view.
A useful pattern to remember: whenever a Revit view has a locked or grayed-out V/G panel, always check the view template first. That template is almost always the root cause of display discrepancies that seem puzzling at the view level.
- Which workflow provides the required result with the least effect on host-model graphics?
Answer: Set the link display to Custom and disable Levels and Grids for the linked model.
When working with linked Revit models, you have granular control over what you see from each link without disturbing the host model's own settings. The key concept here is Revit Link Display Settings, which let you override a linked file's visibility on a category-by-category basis, independently from the host view's Visibility/Graphics overrides.
Setting the linked model's display to Custom (option B) is exactly the right tool. In the Visibility/Graphics dialog, under the Revit Links tab, you can switch a specific link from "By Host View" to "Custom," then navigate to the Annotation Categories tab for that link and turn off Levels and Grids. This hides only those categories from the linked file while leaving walls, doors, and everything else intact — and crucially, it doesn't touch the host model's own levels and grids at all.
Option A fails because disabling Levels and Grids in the host view's Annotation Categories applies globally to the entire view, which would hide the host model's own levels and grids — exactly what the plan requires you to keep visible. Option C is destructive and impractical; hiding the entire link loses walls and doors, forcing you to manually redraw geometry that already exists, which defeats the purpose of linking. Option D is the most dangerous choice: permanently deleting elements from the source file affects every project that references it, far exceeding the scope of a single view override.
As a study habit, remember that link-level overrides always take precedence without harming host-model visibility — whenever a question asks you to filter linked content without side effects, Custom link display settings are your first instinct.
