- Which approach provides the most reliable shared-coordinate workflow?
Answer: Publish each approved position as a named site and assign the appropriate Shared Site to each instance.
When working with linked Revit models that need to appear in multiple positions within a host file, the key concept being tested is Shared Sites — Revit's built-in system for storing and reusing named coordinate relationships between a host and a linked model.
Revit allows each instance of a linked file to be assigned a different "Shared Site," which is essentially a saved, named coordinate position. When you finalize an approved placement — say, the rotated retail building at the north parcel — you publish that position as a named site directly within the linked file's coordinate data. You then assign that named site to the corresponding instance. The south parcel instance gets its own named site. Both positions are stored, reusable, and automatically restore if the link is reloaded. This is exactly what option B describes, making it the correct approach.
Option A fails because duplicating the linked file creates two separate RVT files to maintain, and "Center to Center" placement offers no saved coordinate intelligence — positions must be manually re-established if the link is ever removed and reloaded. Option C describes a backwards workflow: acquiring coordinates from individual link instances doesn't create reusable named sites, and toggling the host's active project location doesn't control where linked instances appear. Option D misunderstands Project Base Points — editing them affects the host file's survey relationship, not individual link instance positions, and copying a pinned instance doesn't save placement logic for reuse.
A good study tip: whenever a Revit question mentions "reusable positions" or "multiple instances of the same linked file in different locations," immediately think Shared Sites and named locations — that's the purpose-built tool for exactly this scenario.
- Which action should the team take?
Answer: Unload the link through Manage Links and reload it when coordination resumes.
When working with linked files in Revit, it helps to distinguish between removing a link and simply pausing it. Revit's Manage Links dialog gives you both options, and choosing correctly preserves all the metadata you've invested in the coordination workflow.
Unloading a link — option C — is exactly the right move here. When you unload through Manage Links, Revit stops reading the file from disk (eliminating the performance hit) while retaining every piece of setup: the link definition, all instance placements, shared-coordinate alignment, and any view-specific visibility overrides. When coordination resumes, a single "Reload" restores everything instantly, as if the link never left.
Option A is the most damaging distractor. Removing a link through Manage Links deletes the link definition entirely. When you recreate it, you must re-establish shared coordinates, reposition instances, and redo visibility settings — exactly the work the team wants to avoid. Option B describes deleting link instances, which removes the placed copies from the model but doesn't address the performance problem caused by loading the file; it also doesn't preserve instance placement data. Option D — binding the link into a group — permanently converts the linked geometry into native Revit elements. This destroys the live link relationship and balloons the host file size, making future coordination far more complex and defeating the purpose of using a linked file at all.
The study tip here: on Revit exam questions about linked files, watch for language like "preserve," "temporarily," or "restore later." Those words point directly to Unload, not Remove or Bind.
- Which action should the architect perform next?
Answer: Acquire Coordinates from the civil link in the architectural model.
Whenever you see a question about coordinate systems in Revit, focus on the direction of information flow: which model is the authority, and which model needs to adopt that authority's coordinates?
In this scenario, the civil model owns the approved coordinate system. The architectural model has already been physically aligned to it using control points — meaning the two models are spatially in sync, but the architectural model hasn't formally adopted the civil model's coordinate system yet. To do that, the architect uses Acquire Coordinates (answer A). This command reads the linked file's coordinate system and writes it into the host model's shared coordinates, making the architectural model speak the same coordinate language as the civil model — without touching the civil file at all.
Answer B reverses the flow. Publish Coordinates pushes the host model's coordinate system into the linked file, which would alter the civil model — exactly what the question says to avoid. This is the most tempting trap because students confuse which direction each command travels.
Answer C — moving the project base point — is a manual workaround that doesn't formally establish shared coordinates. It can cause confusion and doesn't reliably synchronize the coordinate systems the way Acquire Coordinates does.
Answer D — reloading with Auto - Center to Center — would reposition the link based on geometric centers, destroying the careful manual alignment already established with the two control points.
The key study tip: memorize the direction of each command. Acquire = pull coordinates from the link into your model. Publish = push your coordinates into the linked file. This distinction appears frequently on Revit exams.
- What should the project manager expect during placement?
Answer: Revit displays a warning and falls back to Center to Center placement.
When working with linked Revit models, shared coordinates are the backbone of proper multi-file alignment. Whenever you see a question about linking methods like "Auto - By Shared Coordinates," ask yourself: what happens when the prerequisite condition — an established shared coordinate relationship — doesn't exist?
Revit's "By Shared Coordinates" placement method relies on a previously published or acquired coordinate system shared between both files. When that relationship is absent, Revit cannot silently guess where the models should align. Instead, it issues a warning notifying you that no shared coordinates exist, then falls back to Center to Center placement — meaning it aligns the center of each model's bounding extents. This is exactly what answer A describes, making it correct.
Answer B is tempting but wrong. Revit does not silently fall back to internal origins (Project Base Point alignment) without notifying you. The silent behavior described would mask a critical coordination problem, which Revit is designed to flag rather than hide. Answer C is incorrect because Revit will still create the link — it doesn't refuse or block the process just because coordinates aren't published. It simply warns you and uses a fallback. Answer D is incorrect and represents a common misconception: Revit never automatically creates and saves matching shared coordinates between files. Establishing shared coordinates is always a deliberate, manual workflow requiring the Acquire or Publish Coordinates command.
As a study tip, remember this hierarchy: By Shared Coordinates requires prior setup; without it, Revit warns and falls back — it never silently assumes, refuses, or auto-fixes the relationship.
- Which response is most accurate?
Answer: Pinning prevents ordinary movement but does not acquire, publish, or create shared coordinates.
When working with linked files in Revit, it's critical to separate two completely independent operations: establishing shared coordinates and pinning a link. Questions like this test whether you understand that these actions have nothing to do with each other mechanically.
Shared coordinates are established through the "Acquire Coordinates" or "Publish Coordinates" workflow — a deliberate data exchange between the host model and the linked file that defines how their coordinate systems relate. Once that relationship exists, you can place the link "By Shared Coordinates" to honor it. Pinning, by contrast, is simply a UI lock. It prevents a user from accidentally dragging, moving, or deleting the element. That's the entire scope of what pinning does — answer D is correct.
Answer A is wrong because pinning writes nothing into the linked file and shares no transformation data with other hosts. It is purely a local, instance-level lock in the host model. Answer B is wrong because pinning does the opposite of allowing movement — it restricts movement. It also has no interaction whatsoever with survey coordinates. Answer C is wrong because pinning does not alter the coordinate method used for placement at all. The link remains placed by shared coordinates (or whatever method was originally used); pinning doesn't convert or overwrite that setting.
A useful rule of thumb: any question about how shared coordinates are created or transferred should direct your thinking toward Acquire/Publish Coordinates and the "By Shared Coordinates" placement option — never toward pinning, visibility settings, or other instance controls.
- How should the Model C link be configured within Model B?
Answer: As an attachment, because attachments can appear when the parent model is linked.
Whenever you see a question about linked Revit models and visibility in coordination workflows, focus on the core distinction between attachments and overlays — Revit's two link types that behave very differently in nested scenarios.
When Model B links Model C as an attachment, that relationship travels with Model B wherever it goes. So when a coordinator links Model A (which contains Model B), Model C automatically appears as a nested link — the attachment hierarchy propagates through each level. This is exactly what the scenario requires, confirming that B is correct.
A contains a common misconception. Overlays are specifically designed not to propagate — they appear only within the model that directly hosts them and are intentionally suppressed in any parent model. Choosing an overlay when you need nested visibility is the opposite of what you want.
C introduces the idea of "pinning," which controls whether a linked model can be accidentally moved or deleted — it has absolutely no effect on whether a link type propagates through nested hierarchies. Pinning and link type (attachment vs. overlay) are completely separate settings.
D is a trap because "unloaded attachment" contradicts itself in practice. An unloaded link won't display geometry regardless of its type, so it cannot satisfy the requirement that Model C appears automatically. Unloading is for suppressing a link, not enabling it.
Study tip: Memorize the one-liner: attachments travel, overlays stay local. On exam questions involving nested links or coordination models with multiple levels, immediately ask yourself whether the link needs to "travel up" — if yes, it must be an attachment.
- Which explanation best accounts for this result?
Answer: Acquire Coordinates updates shared survey data and True North without rotating Project North views.
When working with shared coordinates in Revit, it helps to keep two separate concepts clear in your mind: Project North (the working orientation you define for drafting convenience) and True North (the real-world geographic orientation tied to the survey coordinate system). These are independent settings, and understanding what Acquire Coordinates actually touches is the core of this question.
When you run Acquire Coordinates from a linked site model, Revit imports that model's shared coordinate system — including its survey point position and True North rotation — into your host file. This updates where True North points relative to your project, which is why any view set to display True North will visibly rotate. Project North, however, is a view-level orientation you set separately and is left completely untouched by the operation. Floor plans set to Project North continue showing the building in its familiar orthogonal orientation because that setting was never modified. This confirms that A is correct.
B describes a fictional compensation mechanism — crop regions don't automatically counter-rotate to preserve orientation; that's not how Revit works. C has the relationship backwards: Acquire Coordinates affects the shared coordinate system and True North, not Project North, which remains under your manual control. D severely understates the command's effect; Acquire Coordinates does far more than update annotations — it repositions the entire shared coordinate system.
As a study tip, remember this distinction: True North = survey/shared coordinates; Project North = your drafting convenience setting. Any question about coordinate acquisition should prompt you to ask which of these two systems is being modified.
- Which positioning method is the most dependable for the first link insertion?
Answer: Auto - Origin to Origin, because the intended common reference is the fixed internal origin.
When linking discipline models in Revit, your first instinct should be to ask: what reference point is guaranteed to be identical and unmovable across both files? That's the core of this question.
In Revit, every project file has a fixed internal origin — sometimes called the "survey point origin" or startup point — that never moves, regardless of what happens to the project base point or shared coordinates. When two models are created from the same template, their internal origins occupy the exact same geometric position in space. The Auto - Origin to Origin method links models by aligning these fixed internal origins, making C the most dependable choice when a common internal reference was intentionally used and no shared-coordinate system has been established yet.
Here's why the other options fail: A is tempting but dangerous — the project base point can be moved (the passage even tells you one team may have moved theirs during early setup), so matching templates don't guarantee matching base point positions. B is unreliable because "Center to Center" aligns the geometric midpoints of each model's bounding extents, which will differ if the two models have different amounts of geometry — there's no inherent connection to the original template reference. D requires a shared coordinate system to already exist between the two files; since the passage explicitly states no shared-coordinate relationship has been established, By Shared Coordinates would either fail or produce unpredictable results.
As a study habit, remember: Origin to Origin is your safe default when files share a common starting point but no shared coordinates have been published. Base points are user-controlled; internal origins are not.
- Which workflow best meets this requirement?
Answer: Publish Coordinates to the structural link, then save the new position when prompted.
Whenever you see a question about shared coordinates in Revit, ask yourself: which model owns the coordinate authority, and in which direction should coordinates flow? The model designated as the coordinate authority should push its coordinate system outward to other models — not receive from them.
In this scenario, the architectural model is the approved authority. The structural model was manually repositioned inside the architectural host until grids aligned. To "lock in" that relationship so the structural file itself remembers its correct real-world position, the architectural model must Publish Coordinates to the structural link. This writes the coordinate system into the structural RVT file, so when the structural team later links their own model using Shared Coordinates positioning, it lands exactly where it belongs. When prompted to save the new position, you must confirm — otherwise the change isn't written to disk. That makes B the correct workflow.
A is backwards. Acquire Coordinates pulls a coordinate system into the host from the link. Here, the architectural model is the authority, so it should be sending coordinates outward, not receiving them from the structural model.
C pins the link's visual position within the host session but does nothing to embed coordinate data into the structural file itself. Reloading with Origin to Origin would actually break the alignment.
D moves the project base point, which affects internal origin relationships, and unloading the link removes it entirely — neither step publishes shared coordinates to the structural file.
Your study tip: remember the direction of the workflow. The authority model publishes; dependent models acquire. If the question names a coordinate authority, that model always initiates the Publish Coordinates command.
- Which coordination strategy is most appropriate?
Answer: Use the civil model as the coordinate authority and establish each discipline's relationship to that system.
When managing multi-discipline BIM coordination in Revit, the core principle is that one model owns the coordinate authority — every other model establishes its relationship to that master system. Without this hierarchy, each discipline operates in its own isolated coordinate space, making clash detection, sheet overlays, and federated model reviews unreliable.
In this scenario, the civil model holds the approved survey control, which means it already contains the legally and contractually correct real-world positioning. Option D is correct because it designates that civil model as the single source of truth. Each discipline then uses "Acquire Coordinates" from the civil model (once linked), embedding the shared coordinate system into their own file. From that point forward, all models share a common origin and true north, enabling consistent coordination across every discipline.
Option A fails because acquiring coordinates from whichever linked model arrives first creates a cascade of misalignment — if the architectural team acquires from structural and structural hasn't yet acquired from civil, you've built a chain of errors with no authoritative anchor. Option B is a dangerous misconception: manually moving a model's internal origin after work has begun — or before links are established — can corrupt existing geometry and annotation and is never the recommended Revit workflow for coordinate alignment. Option C misunderstands what Center to Center linking actually does; it aligns model bounding-box centers geometrically but does nothing to reconcile differing coordinate systems or survey data.
As a study tip, remember that Revit coordinate questions almost always hinge on a single principle: one authoritative source, acquired once, shared outward. If an answer describes independent or ad-hoc coordinate assignment, it's a distractor.
