This question tests your ability to translate real-world limitations into mathematical constraints (equations and inequalities) and determine whether potential solutions are viable—meaning they satisfy all constraints and make sense in context. A constraint is a limitation or requirement: 'budget at most $500' becomes cost ≤ 500, 'need at least 10 units' becomes quantity ≥ 10. The system of ALL constraints defines the feasible region—the set of all solutions that work. A solution is viable if it lies in this feasible region (satisfies every single inequality/equation) AND makes real-world sense (no negative quantities, whole units when needed, etc.). Even one violation makes it nonviable! The constraints are perimeter 2L + 2W ≤ 40 (at most 40 inches), area LW ≥ 84 (at least 84 sq in), and L > 0, W > 0 (positive dimensions). Choice A correctly represents all constraints with the full perimeter formula and ≥ for area. A distractor like Choice C uses L + W ≤ 40, which is only half the perimeter—remember perimeter is 2(L + W), so include the 2! Constraint identification from context: (1) list every limitation mentioned ('budget $X,' 'time ≤ Y hours,' 'need ≥ Z units'), (2) translate using key phrases: 'at most' → ≤, 'at least' → ≥, 'exactly' → =, 'more than' → >, 'less than' → <, (3) don't forget implicit constraints like x ≥ 0, y ≥ 0 (can't be negative) or x, y integers (if discrete), (4) write the complete system. Missing even one constraint can make you accept infeasible solutions! The viability checklist: Make a table with one row per constraint. For each constraint, substitute your point and mark whether it's satisfied (✓) or violated (✗). If all checks pass AND context is reasonable, mark VIABLE. If even one ✗ appears OR context is violated (like negative values or fractional items), mark NONVIABLE and note which constraint failed. This organized approach prevents missing checks and makes your reasoning clear. Thorough constraint checking is what separates good modeling from sloppy work!

This question tests your ability to translate real-world limitations into mathematical constraints (equations and inequalities) and determine whether potential solutions are viable—meaning they satisfy all constraints and make sense in context. A constraint is a limitation or requirement: 'budget at most $500' becomes cost $ \le 500$, 'need at least 10 units' becomes quantity $ \ge 10$. The system of ALL constraints defines the feasible region—the set of all solutions that work. A solution is viable if it lies in this feasible region (satisfies every single inequality/equation) AND makes real-world sense (no negative quantities, whole units when needed, etc.). Even one violation makes it nonviable! The constraints are cost $24x + 18y \le 180$ (no more than $180), serving $8x + 6y \ge 60$ (at least 60 people), and $x \ge 0$, $y \ge 0$ with integers (nonnegative whole trays). Choice A correctly represents all constraints with $ \le $ for cost and $ \ge $ for serving, including nonnegativity and integers. A distractor like Choice B flips cost to $ \ge 180$, which means spending at least $180, but the limit is at most—remember to match 'no more than' to $ \le $! Constraint identification from context: (1) list every limitation mentioned ('budget $X,$ 'time $ \le $ Y hours,' 'need $ \ge $ Z units'), (2) translate using key phrases: 'at most' $ \to \le $, 'at least' $ \to \ge $, 'exactly' $ \to =$, 'more than' $ \to >$, 'less than' $ \to <$, (3) don't forget implicit constraints like $x \ge 0$, $y \ge 0$ (can't be negative) or $x, y$ integers (if discrete), (4) write the complete system. Missing even one constraint can make you accept infeasible solutions! The viability checklist: Make a table with one row per constraint. For each constraint, substitute your point and mark whether it's satisfied (✓) or violated (✗). If all checks pass AND context is reasonable, mark VIABLE. If even one ✗ appears OR context is violated (like negative values or fractional items), mark NONVIABLE and note which constraint failed. This organized approach prevents missing checks and makes your reasoning clear. Thorough constraint checking is what separates good modeling from sloppy work!

This question tests your ability to translate real-world limitations into mathematical constraints (equations and inequalities) and determine whether potential solutions are viable—meaning they satisfy all constraints and make sense in context. Checking viability is systematic: (1) write out each constraint, (2) substitute the proposed solution into each one, (3) verify each is satisfied (inequality holds, equation balances), (4) check context reasonableness (non-negative? integers if needed?). If everything passes, it's viable. If anything fails, it's nonviable—and you should identify WHICH constraint was violated. Complete checking means checking ALL constraints, not just some! Checking each: $(2,4)$ $2(2)+4=8 \le 12$ (✓), $2+2(4)=10 \le 14$ (✓); $(4,2)$ $2(4)+2=10 \le 12$ (✓), $4+2(2)=8 \le 14$ (✓); $(5,4)$ $2(5)+4=14>12$ (✗); $(0,7)$ $0+7=7 \le 12$ (✓), $0+2(7)=14 \le 14$ (✓)—only $(5,4)$ fails. Choice C correctly identifies the nonviable point with complete checking showing it violates $2x + y \le 12$. Choice A gently, but $(2,4)$ satisfies both inequalities, so it's viable—check substitutions carefully. Constraint identification from context: (1) list every limitation mentioned ('budget $X,$ 'time ≤ Y hours,' 'need ≥ Z units'), (2) translate using key phrases: 'at most' → ≤, 'at least' → ≥, 'exactly' → =, 'more than' → >, 'less than' → <, (3) don't forget implicit constraints like $x \ge 0$, $y \ge 0$ (can't be negative) or x, y integers (if discrete), (4) write the complete system. Missing even one constraint can make you accept infeasible solutions! The viability checklist: Make a table with one row per constraint. For each constraint, substitute your point and mark whether it's satisfied (✓) or violated (✗). If all checks pass AND context is reasonable, mark VIABLE. If even one ✗ appears OR context is violated (like negative values or fractional items), mark NONVIABLE and note which constraint failed. This organized approach prevents missing checks and makes your reasoning clear. Thorough constraint checking is what separates good modeling from sloppy work!

This question tests your ability to translate real-world limitations into mathematical constraints (equations and inequalities) and determine whether potential solutions are viable—meaning they satisfy all constraints and make sense in context. A constraint is a limitation or requirement: 'budget at most $500' becomes cost ≤ 500, 'need at least 10 units' becomes quantity ≥ 10. The system of ALL constraints defines the feasible region—the set of all solutions that work. A solution is viable if it lies in this feasible region (satisfies every single inequality/equation) AND makes real-world sense (no negative quantities, whole units when needed, etc.). Even one violation makes it nonviable! Let's translate each constraint: (1) Budget constraint: 8x + 20y ≤ 400 (at most $400), (2) Total items: x + y ≥ 30 (at least 30), (3) Minimum hoodies: y ≥ 10 (at least 10), (4) Non-negativity: x ≥ 0, y ≥ 0. Choice A correctly represents all constraints with the proper inequality directions matching the problem's language. Choice B incorrectly uses 8x + 20y ≥ 400, which would mean spending at least $400 rather than at most $400. Constraint identification from context: (1) list every limitation mentioned ('budget $X,' 'time ≤ Y hours,' 'need ≥ Z units'), (2) translate using key phrases: 'at most' → ≤, 'at least' → ≥, 'exactly' → =, 'more than' → >, 'less than' → <, (3) don't forget implicit constraints like x ≥ 0, y ≥ 0 (can't be negative) or x, y integers (if discrete), (4) write the complete system. Missing even one constraint can make you accept infeasible solutions!

This question tests your ability to translate real-world limitations into mathematical constraints (equations and inequalities) and determine whether potential solutions are viable—meaning they satisfy all constraints and make sense in context. Checking viability is systematic: (1) write out each constraint, (2) substitute the proposed solution into each one, (3) verify each is satisfied (inequality holds, equation balances), (4) check context reasonableness (non-negative? integers if needed?). If everything passes, it's viable. If anything fails, it's nonviable—and you should identify WHICH constraint was violated. Complete checking means checking ALL constraints, not just some! Let's check each option: For A (26,12): x + 2y = 26 + 2(12) = 26 + 24 = 50 ≤ 50 ✓, x + y = 26 + 12 = 38 ≥ 30 ✓, y = 12 ≥ 12 ✓. For B (10,20): x + 2y = 10 + 2(20) = 10 + 40 = 50 ≤ 50 ✓, x + y = 10 + 20 = 30 ≥ 30 ✓, y = 20 ≥ 12 ✓. For C (6,12): x + 2y = 6 + 2(12) = 6 + 24 = 30 ≤ 50 ✓, x + y = 6 + 12 = 18 < 30 ✗ (violates minimum total). For D (24,13): x + 2y = 24 + 2(13) = 24 + 26 = 50 ≤ 50 ✓, x + y = 24 + 13 = 37 ≥ 30 ✓, y = 13 ≥ 12 ✓. Choice C correctly identifies (6,12) as nonviable because it violates the constraint x + y ≥ 30, with only 18 total items instead of the required 30. The viability checklist: Make a table with one row per constraint. For each constraint, substitute your point and mark whether it's satisfied (✓) or violated (✗). If all checks pass AND context is reasonable, mark VIABLE. If even one ✗ appears OR context is violated (like negative values or fractional items), mark NONVIABLE and note which constraint failed. Thorough constraint checking is what separates good modeling from sloppy work!

This question tests your ability to translate real-world limitations into mathematical constraints (equations and inequalities) and determine whether potential solutions are viable—meaning they satisfy all constraints and make sense in context. Checking viability is systematic: (1) write out each constraint, (2) substitute the proposed solution into each one, (3) verify each is satisfied (inequality holds, equation balances), (4) check context reasonableness (non-negative? integers if needed?). If everything passes, it's viable. If anything fails, it's nonviable—and you should identify WHICH constraint was violated. Complete checking means checking ALL constraints, not just some! Let's check (x,y) = (6,7) against each constraint: (1) Fruit cups: x + 2y = 6 + 2(7) = 6 + 14 = 20. We need 20 ≤ 18, but 20 > 18 ✗ (violates fruit constraint). (2) Protein scoops: y = 7 ≤ 7 ✓. (3) Total smoothies: x + y = 6 + 7 = 13 ≥ 10 ✓. (4) Non-negativity: 6 ≥ 0 ✓ and 7 ≥ 0 ✓. Choice B correctly identifies that the point violates x + 2y ≤ 18, as 20 > 18. Even though all other constraints are satisfied, this single violation makes the solution nonviable. The viability checklist: Make a table with one row per constraint. For each constraint, substitute your point and mark whether it's satisfied (✓) or violated (✗). If all checks pass AND context is reasonable, mark VIABLE. If even one ✗ appears OR context is violated (like negative values or fractional items), mark NONVIABLE and note which constraint failed. This organized approach prevents missing checks and makes your reasoning clear. Thorough constraint checking is what separates good modeling from sloppy work!

This question tests your ability to translate real-world limitations into mathematical constraints (equations and inequalities) and determine whether potential solutions are viable—meaning they satisfy all constraints and make sense in context. A constraint is a limitation or requirement: 'budget at most $500' becomes cost ≤ 500, 'need at least 10 units' becomes quantity ≥ 10. The system of ALL constraints defines the feasible region—the set of all solutions that work. A solution is viable if it lies in this feasible region (satisfies every single inequality/equation) AND makes real-world sense (no negative quantities, whole units when needed, etc.). Even one violation makes it nonviable! The constraints are cost 40x + 90y ≤ 900 (at most $900), total ads x + y ≥ 8 (at least 8), radio limit y ≤ 6, and nonnegativity x ≥ 0, y ≥ 0. Choice A correctly represents all constraints with the complete system, using the right directions for each. Choice D incorrectly uses y ≥ 6 for radio, but 'at most' is ≤, not requiring more. Constraint identification from context: (1) list every limitation mentioned ('budget $X,' 'time ≤ Y hours,' 'need ≥ Z units'), (2) translate using key phrases: 'at most' → ≤, 'at least' → ≥, 'exactly' → =, 'more than' → >, 'less than' → <, (3) don't forget implicit constraints like x ≥ 0, y ≥ 0 (can't be negative) or x, y integers (if discrete), (4) write the complete system. Missing even one constraint can make you accept infeasible solutions! The viability checklist: Make a table with one row per constraint. For each constraint, substitute your point and mark whether it's satisfied (✓) or violated (✗). If all checks pass AND context is reasonable, mark VIABLE. If even one ✗ appears OR context is violated (like negative values or fractional items), mark NONVIABLE and note which constraint failed. This organized approach prevents missing checks and makes your reasoning clear. Thorough constraint checking is what separates good modeling from sloppy work!

This question tests your ability to translate real-world limitations into mathematical constraints (equations and inequalities) and determine whether potential solutions are viable—meaning they satisfy all constraints and make sense in context. A constraint is a limitation or requirement: 'budget at most $500' becomes cost ≤ 500, 'need at least 10 units' becomes quantity ≥ 10. The system of ALL constraints defines the feasible region—the set of all solutions that work. A solution is viable if it lies in this feasible region (satisfies every single inequality/equation) AND makes real-world sense (no negative quantities, whole units when needed, etc.). Even one violation makes it nonviable! The constraints are perimeter 2L + 2W ≤ 40 (at most 40), area LW ≥ 75 (at least 75), and positivity L > 0, W > 0. Choice B correctly represents all constraints with the complete system, using ≤ for perimeter and ≥ for area. Choice A incorrectly uses ≥ for perimeter, but 'at most' means ≤, which would require too large a perimeter. Constraint identification from context: (1) list every limitation mentioned ('budget $X,' 'time ≤ Y hours,' 'need ≥ Z units'), (2) translate using key phrases: 'at most' → ≤, 'at least' → ≥, 'exactly' → =, 'more than' → >, 'less than' → <, (3) don't forget implicit constraints like x ≥ 0, y ≥ 0 (can't be negative) or x, y integers (if discrete), (4) write the complete system. Missing even one constraint can make you accept infeasible solutions! The viability checklist: Make a table with one row per constraint. For each constraint, substitute your point and mark whether it's satisfied (✓) or violated (✗). If all checks pass AND context is reasonable, mark VIABLE. If even one ✗ appears OR context is violated (like negative values or fractional items), mark NONVIABLE and note which constraint failed. This organized approach prevents missing checks and makes your reasoning clear. Thorough constraint checking is what separates good modeling from sloppy work!

This question tests your ability to translate real-world limitations into mathematical constraints (equations and inequalities) and determine whether potential solutions are viable—meaning they satisfy all constraints and make sense in context. A constraint is a limitation or requirement: 'budget at most $500' becomes cost ≤ 500, 'need at least 10 units' becomes quantity ≥ 10. The system of ALL constraints defines the feasible region—the set of all solutions that work. A solution is viable if it lies in this feasible region (satisfies every single inequality/equation) AND makes real-world sense (no negative quantities, whole units when needed, etc.). Even one violation makes it nonviable! The constraints are cost 12x + 5y ≤ 120 (at most $120), total items x + y ≥ 15 (at least 15), and nonnegativity x ≥ 0, y ≥ 0, forming the complete system. Choice B correctly represents all constraints with the complete system, including the correct direction for the budget inequality. Choice A incorrectly uses ≥ for the cost, but 'at most' translates to ≤, which would allow overspending. Constraint identification from context: (1) list every limitation mentioned ('budget $X,' 'time ≤ Y hours,' 'need ≥ Z units'), (2) translate using key phrases: 'at most' → ≤, 'at least' → ≥, 'exactly' → =, 'more than' → >, 'less than' → <, (3) don't forget implicit constraints like x ≥ 0, y ≥ 0 (can't be negative) or x, y integers (if discrete), (4) write the complete system. Missing even one constraint can make you accept infeasible solutions! The viability checklist: Make a table with one row per constraint. For each constraint, substitute your point and mark whether it's satisfied (✓) or violated (✗). If all checks pass AND context is reasonable, mark VIABLE. If even one ✗ appears OR context is violated (like negative values or fractional items), mark NONVIABLE and note which constraint failed. This organized approach prevents missing checks and makes your reasoning clear. Thorough constraint checking is what separates good modeling from sloppy work!

This question tests your ability to translate real-world limitations into mathematical constraints (equations and inequalities) and determine whether potential solutions are viable—meaning they satisfy all constraints and make sense in context. A constraint is a limitation or requirement: 'budget at most $500' becomes cost ≤ 500, 'need at least 10 units' becomes quantity ≥ 10. The system of ALL constraints defines the feasible region—the set of all solutions that work. A solution is viable if it lies in this feasible region (satisfies every single inequality/equation) AND makes real-world sense (no negative quantities, whole units when needed, etc.). Even one violation makes it nonviable! The constraints here are cost 1.2x + 0.8y ≤ 60 (at most $60), total items x + y ≥ 50 (at least 50), juice boxes y ≤ 40 (no more than 40), and x ≥ 0, y ≥ 0 with x, y integers (nonnegative whole numbers). Choice B correctly represents all constraints with the proper inequalities for cost (≤), total (≥), and juice (≤), including integer and nonnegative conditions. A common distractor like Choice A flips the cost to ≥, which would mean spending at least $60, but the situation requires at most $60—always double-check the direction of inequalities! Constraint identification from context: (1) list every limitation mentioned ('budget $X,' 'time ≤ Y hours,' 'need ≥ Z units'), (2) translate using key phrases: 'at most' → ≤, 'at least' → ≥, 'exactly' → =, 'more than' → >, 'less than' → <, (3) don't forget implicit constraints like x ≥ 0, y ≥ 0 (can't be negative) or x, y integers (if discrete), (4) write the complete system. Missing even one constraint can make you accept infeasible solutions! The viability checklist: Make a table with one row per constraint. For each constraint, substitute your point and mark whether it's satisfied (✓) or violated (✗). If all checks pass AND context is reasonable, mark VIABLE. If even one ✗ appears OR context is violated (like negative values or fractional items), mark NONVIABLE and note which constraint failed. This organized approach prevents missing checks and makes your reasoning clear. Thorough constraint checking is what separates good modeling from sloppy work!