Autodesk Revit Quiz: Linking Revit Models
10 questions · exam conditions
0:00
Linking Revit ModelsQuestion 1 of 10

A project manager links a consultant model using Auto - By Shared Coordinates. No coordinate relationship has ever been acquired or published between the host and consultant models.

What should the project manager expect during placement?

Revit displays a warning and falls back to Center to Center placement.
Revit silently aligns the two models using their internal origins.
Revit refuses to create the link until coordinates are published.
Revit automatically creates and saves matching shared coordinates in both files.
← Back to quizzes

Autodesk Revit Quiz

Autodesk Revit Quiz: Linking Revit Models

Practice Linking Revit Models in Autodesk Revit 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 Linking Revit Models, giving you a quick way to practice the rules, question types, and explanations that matter most for Autodesk Revit.

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

A project manager links a consultant model using Auto - By Shared Coordinates. No coordinate relationship has ever been acquired or published between the host and consultant models.

What should the project manager expect during placement?

  1. Revit displays a warning and falls back to Center to Center placement. (correct answer)
  2. Revit silently aligns the two models using their internal origins.
  3. Revit refuses to create the link until coordinates are published.
  4. Revit automatically creates and saves matching shared coordinates in both files.
Explanation: 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.

Question 2

Model A links Model B, and Model B links Model C. A coordinator then links Model A into an aggregate coordination model. Model C must appear automatically through the nested-link hierarchy.

How should the Model C link be configured within Model B?

  1. As an overlay, because overlays propagate only one level into host models.
  2. As an attachment, because attachments can appear when the parent model is linked. (correct answer)
  3. As a pinned overlay, because pinning enables nested links to propagate.
  4. As an unloaded attachment, because unloaded links resolve through the parent model.
Explanation: 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.

Question 3

A structural link has been correctly placed using shared coordinates. The coordinator pins the link immediately after verifying alignment. Later, another team member claims that pinning is what established the shared-coordinate relationship.

Which response is most accurate?

  1. Pinning stores the coordinate transformation in the linked file and makes it available to other hosts.
  2. Pinning locks survey coordinates while allowing the link instance to be moved and rotated.
  3. Pinning converts the current placement from shared coordinates to internal-origin coordinates.
  4. Pinning prevents ordinary movement but does not acquire, publish, or create shared coordinates. (correct answer)
Explanation: 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.

Question 4

A standard retail building model will occur twice in a campus host model. One occurrence must be rotated and positioned at the north parcel, and the other must be positioned differently at the south parcel. Both approved relationships must be reusable rather than recreated manually.

Which approach provides the most reliable shared-coordinate workflow?

  1. Create two link types from copied files and place both using Center to Center.
  2. Publish each approved position as a named site and assign the appropriate Shared Site to each instance. (correct answer)
  3. Acquire coordinates separately from each instance and switch the host's active project location.
  4. Use one pinned link instance, then copy it and edit the two project base points.
Explanation: 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.

Question 5

A campus project includes civil, architectural, structural, and mechanical models. The civil model contains the approved survey control. The other disciplines currently use local modeling coordinates, and the BIM manager wants to avoid inconsistent coordinate systems as coordination begins.

Which coordination strategy is most appropriate?

  1. Have every discipline acquire coordinates independently from whichever linked model it receives first.
  2. Move each model's internal origin to the nearest civil control point before creating any links.
  3. Align every model Center to Center because model extents provide a common geometric reference.
  4. Use the civil model as the coordinate authority and establish each discipline's relationship to that system. (correct answer)
Explanation: 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.

Question 6

A large mechanical link is slowing work in an architectural model. The team wants to stop loading it temporarily but preserve its link definition, instance placement, shared-coordinate relationship, and view-specific settings for later use.

Which action should the team take?

  1. Remove the link through Manage Links and recreate it after coordination resumes.
  2. Delete every link instance while retaining the imported mechanical geometry.
  3. Unload the link through Manage Links and reload it when coordination resumes. (correct answer)
  4. Bind the link into a group and hide the resulting group in all views.
Explanation: 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.

Question 7

An architectural model is the approved coordinate authority for a project. A structural model was linked into it, then moved and rotated until the grids aligned. The structural team wants its model to retain this relationship so it can later be linked by shared coordinates.

Which workflow best meets this requirement?

  1. Acquire Coordinates from the structural link, then save only the architectural model.
  2. Publish Coordinates to the structural link, then save the new position when prompted. (correct answer)
  3. Pin the structural link, then reload it using Origin to Origin positioning.
  4. Move the structural project base point, then unload the link from the host.
Explanation: 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.

Question 8

A civil model contains the approved survey location and True North orientation. An architectural model has already linked the civil model and manually aligned it using two known control points. The architect now wants the architectural model to use the civil model's coordinate system without changing the civil file.

Which action should the architect perform next?

  1. Acquire Coordinates from the civil link in the architectural model. (correct answer)
  2. Publish Coordinates from the civil link to the architectural model.
  3. Move the architectural project base point to the civil model origin.
  4. Reload the civil link using Auto - Center to Center positioning.
Explanation: 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.

Question 9

Two discipline models were created from the same approved startup template. Their internal origins were intentionally used as the common initial reference, but no shared-coordinate relationship has yet been established. One team's project base point may have been moved during early setup.

Which positioning method is the most dependable for the first link insertion?

  1. Auto - Project Base Point to Project Base Point, because base points from the same template share the same default position.
  2. Auto - Center to Center, because matching model extents confirm the original template location.
  3. Auto - Origin to Origin, because the intended common reference is the fixed internal origin. (correct answer)
  4. Auto - By Shared Coordinates, because matching templates automatically create shared sites.
Explanation: 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.

Question 10

After acquiring coordinates from a correctly positioned site model, an architect notices that a site plan oriented to True North changes orientation. Floor plans oriented to Project North continue to display the building in the familiar orthogonal working orientation.

Which explanation best accounts for this result?

  1. Acquire Coordinates updates shared survey data and True North without rotating Project North views. (correct answer)
  2. Acquire Coordinates rotates all model elements but view crop regions compensate in floor plans.
  3. Acquire Coordinates changes Project North, while True North remains fixed to the internal origin.
  4. Acquire Coordinates affects only spot-coordinate annotations and cannot change view orientation.
Explanation: 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.