R Programming Quiz: Select And Rename
10 questions · exam conditions
0:00
Select And RenameQuestion 1 of 10

A data frame named records has columns id, score, and batch, in that order. What are its column names after rename(records, subject_id = id, result = score)?

id, score, batch, subject_id, result
id, score, batch; no names are changed
id, score; the unmentioned column is removed
subject_id, result, batch, in that order
← Back to quizzes

R Programming Quiz

R Programming Quiz: Select And Rename

Practice Select And Rename in R Programming 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 Select And Rename, giving you a quick way to practice the rules, question types, and explanations that matter most for R Programming.

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 data frame named records has columns id, score, and batch, in that order. What are its column names after rename(records, subject_id = id, result = score)?

  1. id, score, batch, subject_id, result
  2. id, score, batch; no names are changed
  3. id, score; the unmentioned column is removed
  4. subject_id, result, batch, in that order (correct answer)
Explanation: When working with dplyr's rename(), the key idea is that you're relabeling existing columns — not reordering, duplicating, or dropping them. The syntax always follows new_name = old_name, and only the columns you explicitly mention get renamed; everything else stays exactly as it was. In this question, rename(records, subject_id = id, result = score) renames id to subject_id and score to result. The column batch isn't mentioned, so it remains unchanged. Critically, the order of columns is preserved — rename() never shuffles positions. That makes D correct: the resulting column names are subject_id, result, batch, in the original order. A is wrong because it suggests the new names are appended to the end, as if rename() adds columns rather than relabeling them. That's not how it works — no new columns are created. B reflects the misconception that rename() does nothing or that the syntax is invalid. The syntax is perfectly correct, and the renaming absolutely takes effect. C describes behavior similar to select(), not rename(). With select(), unmentioned columns are dropped by default. But rename() is specifically designed to leave unmentioned columns intact — it's a common trap to confuse these two functions. A good study habit: remember the rename() vs. select() distinction. If you want to rename and keep everything, use rename(). If you want to rename and control which columns survive, use select() with new_name = old_name syntax. These two functions overlap in capability but differ in their defaults.

Question 2

A data frame x has columns in this order: alpha_2, beta, alpha_1, and id. What is the result of select(x, id, starts_with("alpha"))?

  1. id, alpha_1, alpha_2, because matching names are alphabetized
  2. alpha_2, alpha_1, id, because source order takes priority
  3. id, alpha_2, alpha_1, because matches keep source order (correct answer)
  4. id, alpha_2, beta, alpha_1, because helpers retain intervening columns
Explanation: When working with dplyr::select(), the key concept to understand is how column order is determined: the output order follows the order of your selection expressions, and within each helper function like starts_with(), matched columns appear in their original source order from the data frame. Here, select(x, id, starts_with("alpha")) first places id explicitly, then appends all columns whose names start with "alpha". The original data frame has alpha_2 before alpha_1, so starts_with("alpha") returns them in that same source order: alpha_2, then alpha_1. The final result is id, alpha_2, alpha_1 — confirming that C is correct. Choice A is wrong because select() never alphabetizes column names. There is no automatic sorting behavior — matches are returned in the order they appear in the data, not in lexicographic order. Choice B is wrong because it ignores the explicit id argument entirely. When you name a column first in select(), it appears first, period — the explicit selection sets the leading order, and starts_with() fills in after it. Choice D is wrong because select() with a helper only returns the columns that match the helper — it does not retain "intervening" columns like beta that fall between matches in the source data. A helpful mental model: think of select() as building a list. Explicit names are added in the order you write them, and helpers append their matches in source order — no extras, no reordering, no alphabetizing.

Question 3

Suppose sales_data has columns sales, cost, region, and year, in that order. After wanted <- c("cost", "sales"), what are the columns returned by select(sales_data, all_of(wanted), region)?

  1. sales, cost, region, following the data frame's source order
  2. cost, sales, region, following the character vector's order (correct answer)
  3. cost, sales, region, year, retaining every unmentioned column
  4. wanted, region, because the object name is treated as a column
Explanation: When working with dplyr::select(), the key principle to internalize is that column order in the output follows the order you specify in the call, not the order columns appear in the original data frame. Here, wanted <- c("cost", "sales") stores a character vector listing "cost" before "sales." When you pass this to select(sales_data, all_of(wanted), region), dplyr processes your selection left to right: first it expands all_of(wanted) into "cost" then "sales," then appends "region." The result is exactly those three columns — cost, sales, region — in that order, making B the correct answer. A is wrong because select() does not reorder your chosen columns to match the source data frame's layout. Even though sales comes before cost in sales_data, you asked for cost first via the vector, and dplyr honors that. C is wrong because select() is explicitly restrictive — unmentioned columns like year are dropped unless you use something like everything() to pull them in. D reveals a misunderstanding of all_of(): it evaluates the contents of the object named wanted (i.e., the strings inside it), not the object name itself as a column identifier. A useful rule of thumb: think of select() as building a column list from your arguments in sequence — all_of() unpacks a vector in its own order, and each additional argument appends to that list. When you see all_of() on an exam, always trace what's inside the vector, not just that the vector exists.

Question 4

The columns of orders are order_id, client_id, total, and status. What does select(orders, customer = client_id, total, order_id) return?

  1. Columns customer, total, and order_id, in that order (correct answer)
  2. Columns order_id, customer, and total, in source order
  3. Columns client_id, total, and order_id, without renaming
  4. Columns customer, total, order_id, and status, in that order
Explanation: When working with dplyr's select(), you need to keep two behaviors in mind: column ordering and renaming syntax. The select() function returns columns in the exact order you list them, and it lets you rename columns inline using newname = oldname syntax. In select(orders, customer = client_id, total, order_id), you're asking for three columns. The expression customer = client_id renames client_id to customer in the output — it does not create a new column or keep the original name. The remaining columns, total and order_id, are selected as-is. Since you listed them in the order customer, total, order_id, that's exactly the column sequence you get back. This confirms A is correct. B is wrong because select() does not preserve source order — it uses the order you specify in the call. order_id appears last in your call, so it appears last in the result, not first. C is wrong because the renaming does take effect. customer = client_id is valid dplyr syntax; the output column will be named customer, not client_id. D is wrong because status was never included in the select() call. Unlike mutate() or arrange(), select() only returns the columns you explicitly name — any unmentioned columns are dropped. A handy rule of thumb: think of select() as "what you list is what you get" — in that order, with any renames applied. If a column isn't listed, it's gone.

Question 5

A data frame logs has columns id, event, and time, in that order. What are the resulting columns from logs |> rename(user_id = id) |> select(event, starts_with("user"))?

  1. event only, because starts_with() examines the original names
  2. user_id, event, because the renamed column keeps its original position
  3. event, user_id, because selection uses the renamed names and stated order (correct answer)
  4. event, user_id, time, because rename() retains every original column
Explanation: When chaining rename() and select() in R's tidyverse, the key principle is that subsequent operations always see the most current column names. Think of each pipe step as producing a brand-new data frame that the next function receives — there's no memory of what columns were called before. Here's the chain: logs |> rename(user_id = id) produces a frame with columns user_id, event, time (in original position order). Then select(event, starts_with("user")) operates on that renamed frame. It finds event first (explicitly named), then user_id (because it now starts with "user"). The result is event, user_id — exactly in the order you specified in select(). That makes C correct. A is wrong because it assumes starts_with() looks at the original column names before renaming. It doesn't — starts_with() evaluates whatever names exist at the moment select() runs. The original name id is already gone. B gets the right columns but the wrong order. select() returns columns in the order you list them — event is listed first, so it comes first, not user_id. D is wrong because select() is explicitly limiting which columns appear. It does not retain every column the way rename() or mutate() would — only the columns matched by event and starts_with("user") survive. A good rule of thumb: in a pipe chain, every function sees the output of the previous step, not the original data frame. When you rename first, everything downstream uses the new names.

Question 6

A data frame df contains only id and amount. The vector requested is c("amount", "discount"). What happens when select(df, any_of(requested)) is evaluated?

  1. It returns only amount and silently ignores the absent discount name (correct answer)
  2. It returns only amount but issues an error for the absent name
  3. It returns amount and creates a discount column filled with missing values
  4. It returns both id and amount because absent names are not exclusions
Explanation: When working with dplyr's selection helpers, the key distinction to understand is between all_of() and any_of() — they handle missing column names very differently, and exam questions frequently test exactly this boundary. any_of() is explicitly designed for permissive selection: it returns whichever names from your vector exist in the data frame and quietly skips any that don't. So when select(df, any_of(requested)) runs with requested = c("amount", "discount"), it finds amount in df, includes it, notices discount is absent, and moves on without complaint. The result is a one-column data frame containing only amount. That makes A correct. B describes the behavior of all_of(), not any_of(). If you used all_of(requested), R would throw an error because all_of() requires every name in the vector to be present — it's the strict counterpart. Confusing these two is the most common trap in this topic area. C is wrong because neither helper invents columns. Column creation is handled by mutate(), not select(). Selection helpers can only work with columns that already exist. D is wrong because id is never part of requested, and any_of() only selects names that appear in the supplied vector. The absence of discount in the data frame doesn't magically expand the selection to include unrelated columns like id. A reliable study tip: mentally map any_of() → "at least some, no complaints" and all_of() → "all or error." That contrast alone covers most exam questions on this topic.

Question 7

The columns of quarterly are id, date, sales, cost, and region, in that order. Which columns are returned by select(quarterly, cost:date)?

  1. date, sales, cost, arranged in their original forward order
  2. cost, date, because only the two range endpoints are selected
  3. cost, sales, date, following the specified reverse range (correct answer)
  4. id, date, sales, cost, including columns before the endpoint
Explanation: When working with dplyr::select(), the colon operator (:) creates a range of consecutive columns based on their position in the dataframe — and crucially, the range follows the order you specify, not the original column order. In quarterly, the columns are ordered: id, date, sales, cost, region. When you write select(quarterly, cost:date), you're telling R to start at cost (position 4) and move backward to date (position 2). Because dplyr respects the direction of the range, the result is cost, sales, date — traversing the columns in reverse. That makes C the correct answer. Choice A is tempting because it contains the right columns, but it gets the order wrong. date, sales, cost would be the result of select(quarterly, date:cost) — the forward direction. Don't assume select() always reorders results alphabetically or canonically. Choice B reflects a common misconception that the colon only returns the two endpoint columns, as if it worked like a simple two-column selection. The colon always captures everything between the endpoints, inclusive. Choice D is wrong because id lies outside the specified range entirely — select() won't pull in columns beyond your endpoints just because they precede one of them. A useful habit: when you see col_a:col_b in select(), mentally locate both columns in the dataframe's actual column order. If col_a comes after col_b, the range runs backward and the result is returned in that reversed sequence.

Question 8

A data frame inventory has columns sku, qty, and site. What is the result of rename(inventory, qty = sku)?

  1. qty, site; sku is silently dropped and the original qty is overwritten
  2. sku, qty, site; the name collision causes the call to be ignored
  3. qty, qty, site; duplicate column names are created automatically
  4. An error, because the resulting column names would not be unique (correct answer)
Explanation: When working with dplyr::rename(), the syntax is rename(data, new_name = old_name). That means rename(inventory, qty = sku) is attempting to rename the column sku to qty. Here's the critical issue: qty already exists as a column in the data frame. The resulting data frame would have two columns both named qty, which violates dplyr's requirement that all column names be unique — so this call throws an error. That makes D the correct answer. Each wrong answer reflects a plausible but incorrect assumption about how dplyr handles this conflict. A imagines dplyr silently dropping or overwriting the original qty column, but dplyr does not perform any silent destructive operations here — it simply refuses. B suggests the call is ignored and the original data frame is returned unchanged, which would be a reasonable "safe failure" behavior, but that's not what dplyr does; it raises an error rather than silently no-ops. C proposes that duplicate column names are created automatically, which is technically possible in base R data frames, but dplyr explicitly guards against this and will error before producing such output. A useful pattern to remember: dplyr::rename() always validates that the resulting column names will be unique before making any changes. If any name collision would occur — whether from renaming one column to match another, or from any other transformation — the function errors immediately rather than producing an ambiguous or corrupted result. When you see rename questions, always check whether the new name already exists elsewhere in the data frame.

Question 9

A data frame metrics has columns id, speed_mean, speed_sd, and height_mean. What are its column names after rename_with(metrics, toupper, ends_with("_mean"))?

  1. ID, SPEED_MEAN, SPEED_SD, HEIGHT_MEAN
  2. id, SPEED_MEAN, speed_sd, HEIGHT_MEAN (correct answer)
  3. id, SPEED, speed_sd, HEIGHT
  4. SPEED_MEAN, HEIGHT_MEAN; the unmatched columns are removed
Explanation: When working with dplyr's rename_with(), the key insight is that it applies a renaming function only to the columns selected by the third argument, leaving all other columns completely untouched. The function signature is rename_with(.data, .fn, .cols). Here, .fn = toupper converts strings to uppercase, and .cols = ends_with("_mean") selects only speed_mean and height_mean. Those two columns become SPEED_MEAN and HEIGHT_MEAN, while id and speed_sd — which don't match the selector — stay exactly as they are. This gives you id, SPEED_MEAN, speed_sd, HEIGHT_MEAN, confirming B as correct. A is wrong because it implies toupper was applied to all columns, including id and speed_sd. This would only happen if you omitted the .cols argument entirely (which defaults to everything()). C reflects a misunderstanding of what toupper does — it uppercases the whole column name string, not just part of it, so speed_mean becomes SPEED_MEAN, not SPEED. D suggests that unselected columns are dropped, which would make rename_with() behave like select() — a common confusion. Renaming functions never drop columns; they only rename the targeted ones. A good study tip: distinguish between selecting columns (which can exclude others) and renaming columns (which always preserves the full data frame). Whenever you see a _with variant in dplyr, ask yourself: "What does the selector target, and what happens to everything else?"

Question 10

A data frame named results has columns in this order: id, group, score, and note. What are the column names and order after running select(results, score, id, everything())?

  1. id, group, score, note
  2. score, id, group, note (correct answer)
  3. score, id, id, group, note
  4. score, id, note, group
Explanation: When working with dplyr's select(), you need to understand two things: columns are returned in the order you specify them, and helper functions like everything() fill in whatever columns haven't been mentioned yet — without duplicating them. In select(results, score, id, everything()), you're explicitly placing score first, then id second. The everything() helper then appends all remaining columns not yet selected — which are group and note, in their original order from the data frame. That gives you the final column order: score, id, group, note — making B the correct answer. A (id, group, score, note) reflects the original column order with no reordering, as if select() was never called or you had written select(results, everything()). It ignores that score and id were explicitly moved to the front. C (score, id, id, group, note) assumes that explicitly naming id before everything() and then having everything() encounter id again would duplicate it. It won't — everything() is smart enough to skip columns already selected. D (score, id, note, group) gets the prefix right but scrambles the tail end. everything() preserves the original order of remaining columns, so group still comes before note, not after. A useful tip: think of everything() as a "fill in the rest" operator that respects the data frame's original column order for anything not yet named. This pattern — select(df, col_to_front, everything()) — is a common idiom for reordering specific columns to the front.