Compound Boolean Conditions - Java

Which Java condition correctly determines whether x is accepted?
Answer: x >= 0 && x < 10 && (x < 4 || x > 7) When combining multiple conditions in Java, you need to carefully translate English rules into boolean logic — especially when you have both "include" and "exclude" clauses. The rule here has two parts: x must be in [0, 10), AND x must NOT be in [4, 7]. That second clause means x must be either less than 4 or greater than 7. Put together, the correct condition is x >= 0 && x < 10 && (x < 4 || x > 7), which is C. A is close but has a boundary error on the upper range: x <= 10 allows 10 itself, which should be rejected since the rule says "less than 10." Also, x > 7 paired with x <= 10 forms a valid upper band, but the inclusion of 10 makes it wrong. B uses x <= 4 || x >= 7 instead of x < 4 || x > 7. This incorrectly accepts 4 (via x <= 4) and 7 (via x >= 7), but both 4 and 7 should be rejected since the exclusion range is 4 through 7 inclusive. D has an operator precedence problem. Without correct parenthesization, the || splits the expression so that x < 10 alone could satisfy the condition — meaning negative numbers or values like -5 could pass through. A good strategy: always test boundary values mentally — plug in 0, 3, 4, 7, 8, and 10. If even one boundary fails, eliminate that choice. Boundary errors are the most common trap in range-checking questions.
Which Java condition is true exactly when the three values are ordered as described?
Answer: (a b && b > c) When evaluating compound boolean conditions, your goal is to translate the plain-English definition precisely into logic. Here, "ordered" means either strictly increasing (a b > c). Both chains require the middle value b to fall between a and c. Answer D captures this perfectly: (a b && b > c). The first clause checks the full increasing chain, and the second checks the full decreasing chain. If either is true, the three values form an ordered sequence — exactly matching the definition. Here's why the other choices fail: A — (a c) || (a > b && b < c) — this actually checks the opposite: that b is either a peak (greater than both) or a valley (less than both). It detects when values are not ordered through the middle. B — (a b || b > c) — this mixes OR and AND in a way that can return true for non-ordered arrangements. For example, a=1, b=3, c=2 satisfies it even though the values aren't strictly ordered. C — (a b && a > c) — this only checks whether a is the smallest or largest of the three, but says nothing about the relationship between b and c. The sequence a=1, c=3, b=5 would fail this condition even if you relabeled correctly. As a study tip: when translating ordered sequences into code, always write out the full chain of inequalities rather than checking just one endpoint — chained comparisons like a < b && b < c are clearer and less error-prone than partial checks.
Which Java condition implements the qualification rule?
Answer: (admin || (active && points >= 100)) && !banned When translating word problems into boolean logic, your first step should always be to identify the absolute constraints before anything else. Here, the passage contains a hard override: banned users must never qualify — no exceptions, not even admins. That !banned condition must wrap the entire expression. Option A, (admin || (active && points >= 100)) && !banned, correctly handles this. The parentheses ensure that the "qualify" logic — either being an admin, or being active with enough points — is evaluated first, and then the entire result is blocked if the user is banned. This matches the passage exactly. Option B, admin || (active && points >= 100 && !banned), is the most tempting trap. It looks complete, but !banned only applies to the non-admin path. An administrator who is banned still qualifies here, which directly violates the rule. This is a classic scope error — the condition doesn't cover all cases. Option C, (admin || active) && points >= 100 && !banned, incorrectly requires every user — including admins — to have at least 100 points to qualify. An admin with 50 points would be rejected, which contradicts the passage. Option D, admin || (active && (points >= 100 || !banned)), is logically broken in two ways: admins bypass the banned check entirely, and the !banned condition is mixed into the points check rather than acting as a global gate. The key strategy here: when a rule says something "must *never*" happen, that condition should sit outside all other logic using &&, applying universally. Scope your absolute constraints last, not inside branches.
Which condition safely tests whether index identifies an element whose value begins with "A", without risking an exception?
Answer: index >= 0 && index < names.length && names[index] != null && names[index].startsWith("A") When working with arrays in Java, you need to guard against two types of exceptions: ArrayIndexOutOfBoundsException and NullPointerException. The key concept here is short-circuit evaluation — in a && chain, Java stops evaluating as soon as any condition is false. This means the order of your conditions matters enormously. Answer A is correct because it layers the checks in the right sequence. First, it confirms index >= 0 (no negative indices), then index < names.length (no out-of-bounds access), then names[index] != null (element exists), and finally calls .startsWith("A") only when it's safe to do so. Each check protects the next one. Answer B fails because names[index] != null appears before the bounds checks. If index is negative or larger than the array, Java will throw an ArrayIndexOutOfBoundsException before it even reaches the bounds validation — the null check can't protect you if you're already out of bounds. Answer C has a subtle off-by-one error: it uses index <= names.length instead of index < names.length. Since arrays are zero-indexed, the last valid index is names.length - 1. Allowing index == names.length would cause an ArrayIndexOutOfBoundsException. Answer D calls names[index].startsWith("A") before checking names[index] != null. If the element is null, this throws a NullPointerException — the null check on the right side is too late to help. The study tip to remember: always order your guards from broadest to most specific — bounds first, null second, method call last.
Which Java condition is true exactly when the configuration is valid?
Answer: (email && !text && !push) || (!email && text && !push) || (!email && !text && push) When a question asks you to encode a precise logical constraint in Java, the safest strategy is to translate the English requirement directly into boolean logic. Here, "exactly one method is selected" means one variable is true and the other two are false — so you need to enumerate every valid combination explicitly. That's exactly what C does: (email && !text && !push) || (!email && text && !push) || (!email && !text && push). Each clause represents one of the three valid configurations, and the overall expression is true only when exactly one of them holds. This is the most precise, airtight translation of the requirement. A (email ^ text ^ push) is a common trap. XOR chains in Java don't mean "exactly one is true" — they mean "an odd number are true." So if all three variables are true, the expression still evaluates to true (1 XOR 1 XOR 1 = 1), which incorrectly validates a three-method selection. B rules out any pair being simultaneously true: no two methods together. This works correctly, but only if you also guarantee at least one is selected — and B does include (email || text || push). Interestingly, B is actually logically equivalent to C, but it's wordier and harder to verify at a glance, making it a less clean solution and a distractor designed to test your patience. D only excludes the case where all three are selected. It happily accepts two methods being chosen simultaneously (e.g., email && text), so it fails the "exactly one" requirement. When you see "exactly one," enumerate the valid cases explicitly like C does — it's longer but unambiguous.
Which condition is logically equivalent to !(age >= 18 && (member || hasPass)) for every possible set of values?
Answer: age < 18 || (!member && !hasPass) When you see a negation applied to a compound expression like this, you need De Morgan's Laws: !(A && B) becomes !A || !B, and !(A || B) becomes !A && !B. This question tests whether you can apply that rule across a nested expression. Start by breaking down !(age >= 18 && (member || hasPass)). Applying De Morgan's outer layer first: !(age >= 18) becomes age < 18, and !(member || hasPass) becomes !member && !hasPass. The && connecting them flips to ||. That gives you age < 18 || (!member && !hasPass) — which is answer B. Here's why the others fail. A is wrong because it uses && instead of || to join the two parts — it negates the outer && incorrectly by keeping it as && rather than flipping it to ||. C is wrong in two ways: it keeps age >= 18 un-negated (should be age < 18) and uses || between the main parts — a doubly flawed application. D is tempting but incorrect: it correctly gets age < 18 ||, but then writes (!member || !hasPass) instead of (!member && !hasPass), misapplying De Morgan's inner negation — !(member || hasPass) requires &&, not ||. A reliable tip: write De Morgan's Laws on your scratch paper before diving in — !(A && B) = !A || !B and !(A || B) = !A && !B. The most common trap is forgetting to flip the operator (AND↔OR) when distributing the negation.
Which Java condition implements all parts of the access rule?
Answer: active && !locked && (correctPassword || (validToken && !expired)) When translating a word problem into a logical condition, break the passage into its atomic rules first. Here, the passage states three requirements: (1) the account must be active, (2) it must be unlocked, and (3) the user must authenticate — either via correct password or via a reset token that is both valid and not expired. That third requirement is the critical nested structure: correctPassword || (validToken && !expired). Answer D — active && !locked && (correctPassword || (validToken && !expired)) — captures all three rules precisely. The && between the first two conditions enforces that both must be true simultaneously, and the parenthesized OR handles the two authentication paths correctly, requiring both validToken and !expired together when using a token. Answer A fails because it writes correctPassword && (validToken || !expired), meaning both a correct password and token conditions are required simultaneously — that's an AND where an OR is needed for the authentication choice. Answer B is structurally broken from the start: (!locked || correctPassword) lets an unlocked account substitute for a correct password, which the passage never allows. It also requires validToken && !expired unconditionally, ignoring the password path entirely. Answer C uses a top-level OR — (active && !locked && correctPassword) || (validToken && !expired) — which means someone with only a valid, unexpired token (but no active or unlocked account) could gain access. The passage says account status is always required. When you see compound access rules, underline each logical connector word — "in addition," "either/or," "and" — and map them directly to &&, ||, and parentheses before evaluating any answer choice.
Which Java condition correctly assigns the leap-year rule for every integer value of year?
Answer: year % 400 == 0 || (year % 4 == 0 && year % 100 != 0) When translating a multi-part rule into a Boolean expression, your job is to map each "or/and/not" in plain English directly to ||, &&, and != in Java — and get the grouping right. The leap-year rule has two conditions joined by "or": (1) divisible by 400, (2) divisible by 4 but NOT by 100. In Java, that translates precisely to year % 400 == 0 || (year % 4 == 0 && year % 100 != 0) — which is A. Test it mentally: year = 2000 → divisible by 400, true ✓. Year = 1900 → divisible by 4, but also by 100, and not by 400, so false ✓. Year = 2024 → divisible by 4, not by 100, so true ✓. B is wrong because it uses && between the two main branches instead of ||, meaning both conditions must hold simultaneously — but a year divisible by 400 doesn't also need to pass the "divisible by 4 but not 100" test. This makes the condition far too restrictive. C rearranges the terms in a way that breaks the logic: year % 4 == 0 || (year % 100 != 0 && year % 400 == 0). A year like 1900 (divisible by 4) would incorrectly evaluate to true because the first clause fires before the "not 100" guard can exclude it. D is essentially inverted nonsense — it flags years that are not divisible by 400, which captures almost every year incorrectly. A reliable strategy: convert each English clause to code one piece at a time, then check boundary cases (multiples of 400, 100, and plain 4) before finalizing your expression.
Which condition should be used in the while statement?
Answer: index < items.length && !found && !cancelled When writing a search loop with multiple stopping conditions, you need to translate plain English into precise boolean logic. The key phrase here is "continue only while another element remains, the target has not been found, and the user has not cancelled." Every single one of those three conditions must be true simultaneously for the loop to keep running — that's the job of the && (AND) operator. Answer B, index < items.length && !found && !cancelled, correctly chains all three requirements with AND. The loop proceeds only when there are more elements to check (index < items.length), the item hasn't been found (!found), and the search hasn't been cancelled (!cancelled). The moment any one condition fails, the loop exits — exactly the behavior you want. Answer A uses (!found || !cancelled), which means the loop continues as long as either found is false or cancelled is false. This means even if the target is found, the loop could continue as long as the user hasn't cancelled — a logic error that defeats the purpose of searching. Answer C has two problems: index <= items.length causes an off-by-one error (arrays are zero-indexed, so the last valid index is length - 1), and !(found && cancelled) only stops when both conditions are true simultaneously, allowing the loop to run when either one alone is true. Answer D uses || (OR) between the boundary check and the flag conditions, meaning the loop could continue even after running out of elements, risking an ArrayIndexOutOfBoundsException. Tip: Whenever you translate "stop if X or Y," the loop condition becomes !X && !Y (De Morgan's Law). Keeping this transformation in mind prevents you from mixing up AND and OR in boolean loop guards.
Which Java condition correctly determines whether the test result is accepted?
Answer: score >= 0 && score <= 100 && score != 50 && attempts < 3 When translating a word problem into a Java boolean condition, your job is to map every constraint precisely — inclusive ranges, exclusions, and comparisons all need the right operators. The problem gives you three requirements that must all be true simultaneously: score is between 0 and 100 inclusive, score is not 50, and attempts is less than 3. Because every condition must hold at once, you join them all with && (logical AND). That makes A the correct answer: score >= 0 && score <= 100 && score != 50 && attempts < 3. Notice the use of >= and <= because the range is inclusive of 0 and 100, and < 3 because attempts must be strictly less than 3. B fails on two counts: score > 0 excludes 0 (the range starts at 0, not above it), and attempts <= 3 allows 3 attempts when only values less than 3 are valid. C introduces a subtle logical error by using || inside parentheses: (score != 50 || attempts < 3). This means the result is accepted even when score == 50, as long as attempts < 3 — which directly violates the rule that score 50 is always rejected. D uses || at the top level, which breaks the entire condition. Because of operator precedence, && binds tighter than ||, so this reads as score >= 0 OR (everything else) — a score of -5 alone would satisfy it. A good strategy: translate each word constraint one-to-one before combining them, and use && when all conditions must hold simultaneously.

Start this quiz