Autodesk Revit Quiz: Project Units

10 questions · exam conditions

0:00

Project UnitsQuestion 1 of 10

A project uses feet and fractional inches for Length. A consultant requires only one category of dimensions to display decimal feet, while all other dimensions must continue following the project format.

Which workflow meets the requirement without changing the rest of the project?

Change Project Units to decimal feet, then override every dimension type that must remain fractional.

Duplicate the required dimension type, disable its use of project settings, and format that type in decimal feet.

Duplicate the affected views, set their view scales to decimal values, and place the dimensions there.

Edit the measured elements, enter their lengths in decimal feet, and keep all dimension types unchanged.

← Back to quizzes

Autodesk Revit Quiz

Autodesk Revit Quiz: Project Units

Practice Project Units 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 Project Units, 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

Which workflow meets the requirement without changing the rest of the project?

Change Project Units to decimal feet, then override every dimension type that must remain fractional.
Duplicate the required dimension type, disable its use of project settings, and format that type in decimal feet. (correct answer)
Duplicate the affected views, set their view scales to decimal values, and place the dimensions there.
Edit the measured elements, enter their lengths in decimal feet, and keep all dimension types unchanged.

Explanation: Whenever you see a Revit question about displaying units differently for some dimensions while leaving the rest of the project unchanged, you should immediately think about Dimension Type Properties — specifically the per-type unit format override rather than a global project setting. In Revit, every dimension type has a Units Format parameter. By default, it inherits the project units, but you can disable that inheritance and set a completely independent format for that type alone. The correct workflow (B) is to duplicate the existing dimension type, open its Type Properties, disable "Use Project Settings" for the Units Format, and choose decimal feet. Only dimensions placed with that duplicated type will display decimal feet; every other type continues using the project's fractional-inch format. This is surgical and non-destructive. Answer A gets the logic backwards. Changing Project Units to decimal feet forces every dimension that still uses project settings to switch — then you'd have to manually override all the remaining types, which is tedious, error-prone, and the opposite of efficient. Answer C conflates view scale with unit display. Scale controls how large elements appear on sheet, not how numeric values are formatted; changing scale does nothing to the unit style of dimension text. Answer D is simply not how Revit works — model element lengths are driven by geometry, not by typed text in a dimension, and editing elements just to satisfy a display requirement would corrupt the actual model geometry. Your study tip: on Revit exam questions about selectively overriding formats, look for the option that modifies a type duplicate with its own format setting — that pattern respects the project standard while meeting the exception cleanly.

Question 2

The project Length format is millimeters rounded to the nearest $10\text{ mm}$ . A door width is actually $914\text{ mm}$ , but documentation standards require a schedule column to display widths to the nearest millimeter while dimensions remain rounded to $10\text{ mm}$ .

Which action best produces the required result?

Change the project Length rounding to $1\text{ mm}$ and add a $10\text{ mm}$ suffix to dimensions.
Change the door family's width parameter to an integer and keep the schedule field on project settings.
Override the schedule field's unit formatting to $1\text{ mm}$ while leaving Project Units unchanged. (correct answer)
Increase the schedule view scale until the width column reports values to the nearest millimeter.

Explanation: Whenever you see a Revit question about displaying the same measurement differently in different contexts, you should immediately think about unit formatting overrides — Revit allows you to customize how units display at the view or schedule-field level without touching the global Project Units. In this scenario, Project Units are set to round length to the nearest

10\text{ mm}

, which is correct for dimensions. But the schedule column needs

1\text{ mm}

precision. The solution is to select the Width field in the Schedule Properties, open its Field Formatting dialog, uncheck "Use project settings," and set rounding to

1\text{ mm}

. This override is local to that schedule field only — dimensions throughout the project remain at

10\text{ mm}

rounding. That's exactly what option C describes, making it the correct answer. A gets the logic backwards. Changing project-wide rounding to

1\text{ mm}

would fix the schedule but break every dimension on every sheet — and adding a suffix doesn't restore meaningful rounding to dimensions. B misunderstands the issue entirely; changing a parameter to an integer type is a family-authoring action that doesn't control how values display in schedules or dimensions, and it could corrupt parameter data. D is a fundamental misconception — view scale controls how large elements appear graphically on a sheet, not the numeric precision of reported parameter values. No scale setting will change how a number rounds. The key study tip: in Revit, Project Units set the default, but schedules, tags, and dimension types each have their own formatting overrides. Always look for the most targeted override rather than changing a global setting.

Question 3

For a metric project, the team changes the Length format from meters to millimeters. Room areas are already formatted as square meters, and no change is made to the Area row in Project Units.

What happens to room-area values after the Length setting is changed?

They convert automatically to square millimeters because Area always derives its display unit from Length.
They remain in square meters because Length and Area have independently configurable unit formats. (correct answer)
They become unitless until the Area setting is manually synchronized with the new Length format.
They convert to square millimeters only in schedules, while room tags remain in square meters.

Explanation: Whenever you see a question about Project Units in Revit, recognize that each measurement type — Length, Area, Volume, Angle, etc. — has its own independent format setting. These are not a hierarchy where changing one cascades into others. In Revit's Project Units dialog (accessed via Manage > Project Units), Length and Area are separate rows. If your team changes Length from meters to millimeters, that instruction only affects dimensions, distances, and other length-based annotations. Room areas, which reference the Area row specifically, continue to display exactly as that row is configured — in this case, square meters. No automatic conversion occurs. That's why B is correct: the two formats are independently configurable and neither inherits from the other. A is wrong because it describes a dependency that doesn't exist in Revit. Area does not "derive" its display unit from Length; they are configured separately in the same dialog. C introduces a fictional "unitless" state — Revit will not suspend or blank out area values just because a related unit type was changed. D is equally fabricated; Revit does not split behavior between schedules and tags based on unit changes. Tags and schedules both pull from the same Area format setting, and neither would convert in this scenario anyway. A useful study tip: when reviewing Project Units questions, mentally picture the dialog as a table of independent rows. Ask yourself, "which row does this value type belong to?" If a question implies that changing one row affects another automatically, that's almost always a trap.

Question 4

A linked architectural model was authored in metric units. It is positioned correctly in an imperial host project. The host team changes its Project Units Length format from feet and fractional inches to decimal inches.

What effect does this change have on the linked model and new host dimensions placed to linked elements?

The link is rescaled to decimal inches, and new host dimensions report the link's original metric values.
The link is unloaded until its source file is converted to the same units as the host project.
The link retains its physical size, but host dimensions must use the linked file's metric formatting.
The link retains its physical size, and new host dimensions display values using the host's decimal-inch format. (correct answer)

Explanation: Whenever you see a question about linked models and unit settings in Revit, separate two distinct concepts: physical geometry and display formatting. These operate independently, and confusing them is the source of most wrong answers here. When you link a model into a Revit host project, the geometry is placed in real-world coordinates. The link's physical size never changes based on the host's display units — a wall that is 3000 mm long remains exactly 3000 mm long regardless of how the host chooses to label it. Changing Project Units in the host file is purely a display preference; it tells Revit how to format dimension values on screen and in annotations, not how to resize or reinterpret geometry. So when the host switches from feet-and-fractional-inches to decimal inches, the linked model stays physically identical, and any new dimensions the host team places to linked elements will simply report those same real-world distances expressed in decimal inches. That makes D correct. A is wrong because Revit never rescales a linked model when units change — the geometry is untouched. B describes behavior that doesn't exist in Revit; links are not unloaded due to unit mismatches between host and linked files. C is wrong because host dimensions always follow the host project's unit settings, not the linked file's formatting — you don't inherit metric labels just because the linked file was authored in metric. The key study tip: in Revit, units are a display setting, not a geometric property. Project Units control how values are shown; they never rescale or reload geometry, whether local or linked.

Question 5

An imperial project displays a dimension as $0'\text{-}6"$ . The documentation standard requires the same measurement to appear as $6"$ , while values of one foot or more must continue showing feet and inches.

Which Length formatting adjustment should be used?

Enable suppression of zero feet while retaining feet-and-fractional-inches formatting. (correct answer)
Enable suppression of trailing zeros while changing Length formatting to decimal inches.
Set the unit symbol to None while retaining feet-and-fractional-inches formatting.
Round Length to the nearest inch while changing the dimension type to decimal feet.

Explanation: When working with dimension formatting in Revit, questions like this test your understanding of unit formatting controls — specifically, how to suppress unwanted components of a measurement without changing the underlying unit system or losing precision for larger values. The scenario requires that

0'\text{-}6"

display as

6"

, while values like

1'\text{-}6"

continue showing feet and inches normally. This is a classic case for zero-feet suppression. In Revit's Type Properties for a dimension type, the Length formatting dialog includes a "Suppress 0 Feet" option. When enabled, any measurement whose feet component is zero simply omits the

0'

prefix — so

0'\text{-}6"

becomes

6"

— while measurements of one foot or more continue displaying both feet and inches unchanged. Answer A correctly identifies this solution. Answer B is a trap because switching to decimal inches (e.g.,

6.00"

) changes the format of all dimensions, not just zero-foot values — larger measurements would no longer display in feet-and-inches, violating the documentation standard. Answer C is tempting but misleading: removing the unit symbol would hide the inch mark entirely, producing bare numbers rather than a properly labeled

6"

. It also doesn't suppress the zero-feet component. Answer D is entirely off-track — rounding to the nearest inch affects precision, and switching to decimal feet would display everything as

0.5'

style values, which contradicts the requirement. As a study tip: on Revit exam questions about dimension display, distinguish between suppression options (which conditionally hide components) and format changes (which alter the entire unit system). They are not interchangeable.

Question 6

A project has Length rounding set to the nearest $5\text{ mm}$ . A measured offset is actually $1012\text{ mm}$ and displays as $1010\text{ mm}$ . A user assumes the model has been shortened and changes the Project Units rounding to the nearest $1\text{ mm}$ .

What should the user expect after changing only the rounding setting?

The offset remains physically $1012\text{ mm}$ , but the display stays $1010\text{ mm}$ because the previous rounding permanently fixed the displayed value.
The offset remains physically $1012\text{ mm}$ , but its display stays $1010\text{ mm}$ until the element is deleted and redrawn in the model.
The offset is physically adjusted from $1012\text{ mm}$ to $1010\text{ mm}$ to match the value that was previously displayed in the project.
The offset remains physically $1012\text{ mm}$ , and its displayed value changes from $1010\text{ mm}$ to $1012\text{ mm}$ due to the increased precision. (correct answer)

Explanation: Whenever you see a question about Revit's Project Units settings, keep this principle front of mind: rounding is purely a display filter. The actual geometry stored in the Revit model database is never altered by changing how numbers are presented on screen. In this scenario, the element's true physical length is

1012 \text{ mm}

. When rounding is set to the nearest

5 \text{ mm}

, Revit rounds

1012

down to

1010

for display purposes only — the underlying geometry remains untouched at

1012 \text{ mm}

. The moment you increase precision to the nearest

1 \text{ mm}

, Revit re-evaluates that same stored value and now displays

1012 \text{ mm}

accurately. This makes D the correct answer: the physical offset stays at

1012 \text{ mm}

, and the displayed value updates to reflect the finer rounding setting. A is wrong because it treats the previous display value as if it "locked in" permanently — rounding never permanently fixes a displayed value; it recalculates dynamically based on the current setting. B is wrong for a similar reason and adds a false requirement: deleting and redrawing the element has no effect on how rounding works. C describes the opposite of reality — rounding never physically modifies geometry to match a displayed value. If that were true, changing precision would corrupt your model, which Revit explicitly prevents. A good study tip: always distinguish between stored model data (immutable by display settings) and display formatting (controlled by Project Units). On the Revit exam, any answer suggesting that a display setting physically changes geometry is almost certainly a trap.

Question 7

Project Length is formatted in millimeters and rounded to the nearest $10\text{ mm}$ . A wall's actual modeled length is $2438\text{ mm}$ . Most dimensions use project settings, but one dimension type has a Units Format override rounded to the nearest $1\text{ mm}$ .

How will dimensions of that wall display when the two dimension types are used?

The project-based type displays $2438\text{ mm}$ , and the overridden type displays $2440\text{ mm}$ .
Both types display $2440\text{ mm}$ because Project Units always take precedence over type formatting.
The project-based type displays $2440\text{ mm}$ , and the overridden type displays $2438\text{ mm}$ . (correct answer)
Both types display $2438\text{ mm}$ because rounding changes only entered values, not dimensions.

Explanation: Whenever you see a question about Revit dimension formatting, keep two layers in mind: Project Units (the global default) and Type Properties Units Format overrides (which apply only to that specific dimension type). The override wins for its type — it does not get overruled by the project setting. Here's how the logic works for this scenario. The wall is modeled at exactly

2438\text{ mm}

. The project-based dimension type rounds to the nearest

10\text{ mm}

, so

2438

rounds up to

2440\text{ mm}

— that's what it displays. The second dimension type has a Units Format override set to round to the nearest

1\text{ mm}

, so it preserves the full value and displays

2438\text{ mm}

. That makes C correct. A has the two values swapped — it assigns

2438

to the project type and

2440

to the override type, which is exactly backwards from how rounding actually works in each case. B claims Project Units always take precedence, which is a common misconception. In Revit, a Units Format override in Type Properties specifically exists to bypass the project setting for that dimension type — the override wins, not the project default. D suggests rounding never affects dimension display at all, only entered values. This is false; rounding settings in both Project Units and dimension type overrides directly control how measured lengths are displayed in your views. Study tip: Think of it as a hierarchy — Type Override beats Project Units. If a dimension type has its own Units Format set, that's what you'll see, regardless of what's configured globally.

Question 8

A roof has a rise of $3\text{ in.}$ for every $12\text{ in.}$ of horizontal run. The project currently displays slope as rise over run, but the deliverable requires percentage slope.

Which Project Units change and resulting displayed value are appropriate?

Change the Slope unit to Percentage; the roof displays approximately $25\%$ . (correct answer)
Change the Angle unit to Percentage; the roof displays approximately $14\%$ .
Change the Slope unit to Degrees; the roof displays approximately $25^\circ$ .
Change the Length unit to Percentage; the roof displays approximately $3\%$ .

Explanation: Whenever you see a question about roof slope display in Revit, focus on two things: which parameter type controls slope (not angle or length), and what the math produces when converting formats. In Revit, roof slope is controlled by the Slope unit setting under Manage → Project Units. A slope of

3:12

means the roof rises

3\text{ in.}

for every

12\text{ in.}

of run. To convert to a percentage, you divide rise by run and multiply by 100:

\frac{3}{12} \times 100 = 25\%

. Changing the Slope unit to Percentage tells Revit to display this value as

25\%

, which is exactly what option A describes — making A the correct answer. Option B is wrong on two counts: "Angle" is a separate unit type from "Slope," and

14\%

actually corresponds to the tangent-based percentage of the angle (

\arctan(3/12) \approx 14.04°

, not

14\%

) — it conflates angular measure with slope percentage. Option C changes Slope to Degrees, which is a legitimate Revit option, but the resulting value would be approximately

14°

(not

25°

), so both the unit type reasoning and the number are wrong. Option D is a clear distractor — Length units govern dimensions like feet and millimeters, not slope, and there's no meaningful way to express slope as a "length percentage." As a study tip, remember that Revit separates Slope, Angle, and Length as distinct unit categories — mixing them up is the most common trap in Project Units questions. Always match the parameter type to the correct unit family.

Question 9

A project was modeled with Length formatted as feet and fractional inches. The team changes the Project Units Length setting to millimeters with rounding to the nearest millimeter. Existing linear dimension types are configured to use project settings.

What is the expected result after the Project Units change?

Model geometry is rescaled from feet to millimeters, and existing dimensions retain their original numeric values.
Model geometry retains its physical size, and existing dimensions display converted millimeter values using the new rounding. (correct answer)
Model geometry retains its physical size, but existing dimensions continue displaying feet and fractional inches until recreated.
Model geometry is rescaled only in views created after the change, while existing views retain imperial values.

Explanation: When you see a question about Project Units in Revit, the core concept to anchor yourself to is this: Project Units control how measurements are displayed, not how geometry is stored. Revit always stores model geometry in absolute real-world coordinates internally — changing the display unit never rescales or moves anything. With that framework in place, answer B is clearly correct. When you switch Length from feet and fractional inches to millimeters, every wall, door, and slab stays exactly the same physical size. What changes is how Revit reports those distances. Because the existing dimension types are set to "use project settings," they automatically adopt the new unit (millimeters) and apply the specified rounding, displaying converted values immediately without any manual recreation required. Here's why each distractor fails: A incorrectly suggests the geometry itself is rescaled — Revit never changes the model's physical size based on a unit setting change. That would be a catastrophic and irreversible action, not a display preference. C claims dimensions would keep showing feet and fractional inches until recreated — this would only be true if the dimension type had a hardcoded unit override rather than being set to use project settings; since the question explicitly states they use project settings, they update automatically. D introduces a fictional behavior where only new views are affected — Revit's Project Units are project-wide and apply universally to all views immediately. As a study tip, always distinguish between display settings (units, rounding, formatting) and geometric data in Revit. Exam questions frequently try to blur this line.

Question 10

A project displays Length in decimal feet. A designer must create an element exactly $2500\text{ mm}$ long and wants to avoid manually converting the value to feet.

Which input is the most reliable in a temporary dimension or length field?

Enter $2500$ without a suffix so Revit recognizes the intended metric magnitude automatically based on the numeric scale of the value.
Enter $2500\text{ mm}$ explicitly so Revit converts the value into the project's displayed units without requiring a change to Project Units. (correct answer)
Change Project Units to millimeters, enter $2500$ , and change Project Units back to decimal feet once the element is placed.
Enter $2.5$ without a suffix because bare decimal values in imperial projects are always interpreted as meters when they fall below a threshold of 10.

Explanation: Whenever you see a Revit question about entering measurements in a project with mixed or unfamiliar units, the key concept is explicit unit suffixes. Revit's input fields respect the unit tag you type alongside a number, regardless of what the project's display units are set to. Typing 2500 mm directly into a dimension or length field tells Revit exactly what unit system you intend. Revit internally converts that value into the project's native units — decimal feet in this case — and places the element at precisely

2500 \text{ mm}

. No manual conversion, no Project Units change required. That makes B the most reliable and efficient approach. A is wrong because Revit does not infer units from the magnitude of a bare number. If your project is set to decimal feet, typing 2500 means

2500 \text{ ft}

— an enormous and unintended dimension. Revit has no threshold logic that guesses "this number looks metric." C would technically work, but it's unnecessarily cumbersome and introduces risk: switching Project Units mid-workflow can affect annotations, schedules, and other active elements. It's the long way around a problem that a simple suffix solves instantly. D is entirely false. Revit does not interpret bare decimal values as meters based on any numeric threshold. A number without a suffix always adopts the project's current display unit — period. Study tip: Memorize that Revit accepts inline unit suffixes (mm, cm, m, ft, in) in almost any input field. This is one of Revit's most practical features and a frequent exam trap when unit mismatches are involved.