Try 10 focused Java 17 1Z0-829 questions on Controlling Program Flow, with explanations, then continue with IT Mastery.
Open the matching IT Mastery practice page for timed mocks, topic drills, progress tracking, explanations, and full practice.
Try Java 17 1Z0-829 on Web View full Java 17 1Z0-829 practice page
| Field | Detail |
|---|---|
| Exam route | Java 17 1Z0-829 |
| Topic area | Controlling Program Flow |
| Blueprint weight | 6% |
| Page purpose | Focused sample questions before returning to mixed practice |
Use this page to isolate Controlling Program Flow for Java 17 1Z0-829. Work through the 10 questions first, then review the explanations and return to mixed practice in IT Mastery.
| Pass | What to do | What to record |
|---|---|---|
| First attempt | Answer without checking the explanation first. | The fact, rule, calculation, or judgment point that controlled your answer. |
| Review | Read the explanation even when you were correct. | Why the best answer is stronger than the closest distractor. |
| Repair | Repeat only missed or uncertain items after a short break. | The pattern behind misses, not the answer letter. |
| Transfer | Return to mixed practice once the topic feels stable. | Whether the same skill holds up when the topic is no longer obvious. |
Blueprint context: 6% of the practice outline. A focused topic score can overstate readiness if you recognize the pattern too quickly, so use it as repair work before timed mixed sets.
These questions are original IT Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.
Topic: Controlling Program Flow
A developer compiles the following Java 17 code. The compiler reports an error at continue scan; similar to not a loop label: scan. Which option best explains the cause?
public class Report {
public static void main(String[] args) {
int total = 0;
scan: {
for (int row = 0; row < 3; row++) {
if (row == 1) continue scan;
total += row;
}
}
System.out.println(total);
}
}
Options:
A. scan labels a block, not a loop.
B. Labels cannot be declared inside main.
C. A label requires a matching break.
D. total += row; is unreachable code.
Best answer: A
Explanation: The label scan is legal, but it labels a block statement. In Java, break can target a labeled block, but continue can target only a labeled loop. Since continue scan; targets a non-loop statement, the code fails to compile.
Java labels can be applied to many statements, including blocks and loops. However, a labeled continue has a stricter rule: its target label must identify an enclosing loop statement such as for, while, or do-while. Here, scan: is placed before a block, and the for loop is inside that block. The compiler therefore rejects continue scan; because there is no labeled loop named scan to continue.
To continue the for loop by label, place scan: directly before the for statement. To leave the labeled block instead, use break scan;.
total += row; can execute when row != 1.break.Topic: Controlling Program Flow
A shipping service compares routing for two orders. What is printed by this Java 17 code?
public class Routes {
static String route(boolean vip, boolean express, boolean overseas) {
if (vip) {
if (express && !overseas) {
return "FAST";
} else if (overseas) {
return "REVIEW";
}
return "PRIORITY";
} else if (express || overseas) {
return "QUEUE";
}
return "BULK";
}
public static void main(String[] args) {
System.out.print(route(true, true, true) + ":");
System.out.print(route(false, true, false));
}
}
Options:
A. QUEUE:QUEUE
B. REVIEW:QUEUE
C. REVIEW:PRIORITY
D. FAST:QUEUE
Best answer: B
Explanation: The key is tracing which if or else if chain is active after each exact boolean result. For route(true, true, true), the outer vip branch is entered, so the later outer else if is skipped. For route(false, true, false), the outer else if is evaluated and returns QUEUE.
In an if/else if chain, only the first matching branch in that chain runs. The first call has vip == true, so execution enters the nested block. Inside it, express && !overseas is true && false, which is false; then overseas is true, so REVIEW is returned. The second call has vip == false, so the nested block is skipped and the outer else if (express || overseas) is checked. That expression is true || false, so it returns QUEUE.
The important distinction is that the outer else if is not considered once the outer if (vip) branch has been selected.
FAST:QUEUE, but !overseas is false in the first call.REVIEW:PRIORITY, but the second call never enters the vip block.QUEUE:QUEUE, but the first call already matched if (vip).Topic: Controlling Program Flow
A developer is reviewing two versions of a feature flag check. Assume print() appends text without a newline. Which comparison is correct?
boolean ready = false;
boolean valid = false;
// Version 1
if (ready)
if (valid)
System.out.print("A");
else
System.out.print("B");
System.out.print("C");
// Version 2
if (ready) {
if (valid)
System.out.print("A");
} else
System.out.print("B");
System.out.print("C");
Options:
A. Version 1 prints BC; Version 2 prints C.
B. Neither version compiles because the indentation is ambiguous.
C. Version 1 prints BC; Version 2 prints BC.
D. Version 1 prints C; Version 2 prints BC.
Best answer: D
Explanation: Java does not use indentation to group statements. Without braces, an else is associated with the nearest preceding unmatched if. The braces in Version 2 change which if the else belongs to.
The core rule is the dangling else rule: an else pairs with the closest unmatched if in the same statement structure. In Version 1, the else belongs to if (valid), and that whole inner if/else is the statement controlled by if (ready). Since ready is false, the inner statement is skipped entirely, so only C is printed. In Version 2, the braces make the outer if body a block, so the following else pairs with if (ready). Since ready is false, B is printed before C. The key takeaway is that braces, not indentation, control grouping.
if owns an else.if is if (valid).else.Topic: Controlling Program Flow
No imports are needed. What is the result of running this Java 17 program?
public class Test {
public static void main(String[] args) {
int x = 4;
int y = 10;
if (x > 5)
if (y > 5)
System.out.print("A");
else
System.out.print("B");
System.out.print("C");
}
}
Options:
A. It prints AC.
B. It prints C.
C. It prints BC.
D. It does not compile.
Best answer: B
Explanation: Java pairs an else with the closest preceding unmatched if, regardless of indentation. Here, the else belongs to if (y > 5), but that inner if/else is reached only if x > 5 is true. Since x is 4, only C is printed.
This is the classic dangling else rule. Without braces, only the next statement belongs to an if; an else is associated with the nearest unmatched if. The code is parsed as if the inner if/else were the single statement controlled by if (x > 5). Because x > 5 is false, Java skips that entire nested statement, including both the inner if and its else. The final System.out.print("C") is outside the if structure, so it always runs. Indentation does not create statement grouping in Java; braces do.
else does not pair with if (x > 5).if (y > 5) is never evaluated when x > 5 is false.else form is syntactically valid Java.Topic: Controlling Program Flow
In Java 17, a developer is reading code with nested loops labeled outer and inner. Which rule about break and continue is correct?
Options:
A. An unlabeled break exits all enclosing labeled loops.
B. An unlabeled continue resumes the outermost enclosing loop.
C. break outer; is valid only if outer labels a loop.
D. continue outer; must target an enclosing labeled loop.
Best answer: D
Explanation: A labeled continue must refer to an enclosing loop, and control proceeds with that loop’s next iteration. This differs from labeled break, which can target an enclosing labeled statement, not necessarily only a loop.
The core rule is that continue is loop-specific. An unlabeled continue applies to the innermost enclosing loop, while a labeled continue must name an enclosing labeled loop. A labeled break also requires an enclosing matching label, but the labeled statement does not have to be a loop; it could be a labeled block. In nested loops, labels let you direct control to an outer loop, but only within these target restrictions.
break label; can target an enclosing labeled non-loop statement.break exits only the innermost loop or switch.Topic: Controlling Program Flow
While troubleshooting a unit test, a developer expects audit(false, true) to print inactive done, but it prints done. What is the best cause or next fix?
public class Audit {
static void audit(boolean active, boolean paid) {
if (active)
if (paid)
System.out.print("paid ");
else
System.out.print("inactive ");
System.out.print("done");
}
public static void main(String[] args) {
audit(false, true);
}
}
Options:
A. paid is evaluated before active; swap the condition order.
B. Java follows indentation; align the else under if (active).
C. The nested if without braces is a compile-time error.
D. The else binds to if (paid); add braces around the outer if body.
Best answer: D
Explanation: This is dangling else behavior. In Java, an else associates with the nearest unmatched if, regardless of indentation. Here, the else belongs to if (paid), and that inner if statement is skipped entirely when active is false.
A Java if without braces controls exactly one statement. A nested if/else can be that one statement, and an else is matched with the closest preceding unmatched if. This code is effectively parsed as: if active is true, run the inner if (paid) ... else ...; then always print done. For active == false, the outer if body is skipped, so the inactive print is never reached. To make inactive the outer else, put braces around the outer if body before the else.
if owns an else.if/else structure is legal Java syntax.paid is tested only inside the branch where active is true.Topic: Controlling Program Flow
Assume required imports exist. A developer compares two enhanced for loops:
public class Demo {
public static void main(String[] args) {
int[] values = {1, 2, 3};
for (int v : values) {
if (v == 2) values[0] = 9;
}
System.out.print(values[0] + ":");
var list = new ArrayList<>(List.of(1, 2, 3));
for (Integer v : list) {
if (v == 2) list.add(4);
}
System.out.print(list.size());
}
}
What is the result?
Options:
A. It prints 9:3.
B. It throws ConcurrentModificationException before printing anything.
C. It prints 9:4.
D. It prints 9: and then throws ConcurrentModificationException.
Best answer: D
Explanation: The array loop completes and changes values[0] to 9, so 9: is printed. The collection loop uses an Iterator behind the enhanced for; adding to the ArrayList directly during that iteration is a structural modification detected by the iterator.
An enhanced for loop over an array is essentially index-based, so assigning a new value to an existing array element is allowed. It does not change the array length or invalidate the loop. An enhanced for loop over an ArrayList uses an iterator. Calling list.add(4) directly changes the list structurally after the iterator has been created. When the loop tries to continue, the iterator detects the modification and throws ConcurrentModificationException. The final System.out.print(list.size()) is not reached.
9:4 ignores the fail-fast iterator behavior of ArrayList.Topic: Controlling Program Flow
No imports are required for this code. What is the result of compiling and running it?
public class LoopDemo {
public static void main(String[] args) {
int total = 0;
for (int i = 5; i < 5; i++)
total += 10;
for (int j = 0; ; j++) {
if (j == 3) break;
total += j;
}
System.out.print(total);
}
}
Options:
A. It runs forever.
B. It prints 3.
C. It prints 13.
D. It does not compile.
Best answer: B
Explanation: A for loop body runs only when its condition is true before an iteration starts. The first loop is skipped because 5 < 5 is false. The second loop omits its condition, which is legal and means the loop would be infinite unless exited by break.
The core concept is how for loop conditions control execution. In the first loop, i starts at 5, so i < 5 is false immediately and total += 10 never runs. In the second loop, the middle expression is omitted, which is valid Java syntax and acts like an always-true condition. However, the loop checks if (j == 3) break; before adding j, so it adds 0, 1, and 2, then exits when j becomes 3. The total is therefore 3, not an infinite loop or a compile-time error.
10 because the first loop condition is false before its first iteration.for condition is legal.break exits the second loop when j == 3.Topic: Controlling Program Flow
A developer is reviewing four proposed bodies for this method. Each body would replace the comment inside the same switch expression, and each body is tested separately.
enum Level { LOW, MEDIUM, HIGH }
static int score(Level level) {
return switch (level) {
// proposed body goes here
};
}
// Body R
case LOW -> { yield 1; System.out.println(); }
case MEDIUM -> 2;
case HIGH -> 3;
// Body S
case LOW, LOW -> 1;
case MEDIUM -> 2;
case HIGH -> 3;
// Body T
case LOW -> 1;
case MEDIUM -> 2;
// Body U
case 1 -> 1;
case LOW -> 1;
case MEDIUM -> 2;
case HIGH -> 3;
Which proposed body is correctly described?
Options:
A. Body T fails because LOW is incompatible with Level.
B. Body S fails because it has a duplicate case label.
C. Body U compiles because all enum constants are covered.
D. Body R fails because the switch expression is not exhaustive.
Best answer: B
Explanation: Body S is the correctly described body because repeating the same enum constant in a switch label list is illegal. The other bodies fail for different reasons: unreachable code after yield, non-exhaustiveness, or an incompatible case label.
Switch expressions are checked more strictly than simple switch statements because they must produce a value. For an enum selector, each case label must be compatible with the enum type, labels cannot be duplicated, and the expression must cover all possible enum constants or include default. In Body S, LOW is listed twice in case LOW, LOW, so the duplicate label rule is violated.
Body R covers all enum constants but has an unreachable statement after yield. Body T is missing HIGH, making the switch expression non-exhaustive. Body U covers the enum constants, but case 1 is not compatible with selector type Level.
Body R covers every enum constant, but the statement after yield cannot be reached.Body T uses compatible enum labels, but leaves HIGH uncovered in a switch expression.Body U covers the enum constants, but case 1 is incompatible with selector type Level.Topic: Controlling Program Flow
The code uses only java.lang classes; no imports are required. What is the result of running this Java 17 program?
public class Routing {
public static void main(String[] args) {
int stock = 12, reserved = 4;
boolean rush = false;
if (stock - reserved > 10) {
System.out.print("ship");
} else if (stock - reserved == 8) {
System.out.print("hold");
if (rush && reserved > 0) {
System.out.print("-rush");
} else if (!rush || stock < 10) {
System.out.print("-review");
} else {
System.out.print("-wait");
}
} else {
System.out.print("order");
}
}
}
Options:
A. order
B. ship
C. hold-rush
D. hold-review
Best answer: D
Explanation: The program compiles and enters the outer else if because stock - reserved equals 8. Inside that block, the first nested condition is false, but the nested else if is true because rush is false.
Conditional chains are evaluated top to bottom, and only the first matching branch in an if/else if/else chain runs. Here, stock - reserved is 12 - 4, which is 8. The first outer condition, 8 > 10, is false, so execution checks the next condition, 8 == 8, which is true and prints hold. In the nested chain, rush && reserved > 0 is false because rush is false. The next condition, !rush || stock < 10, is true because !rush is true. Therefore the nested branch prints -review. The final else branches are skipped once a matching branch has executed.
stock - reserved is 8, not greater than 10.rush && reserved > 0 is false when rush is false.else if prevents the final else from running.Use the Java 17 1Z0-829 Practice Test page for the full IT Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.
Try Java 17 1Z0-829 on Web View Java 17 1Z0-829 Practice Test
Read the Java 17 1Z0-829 Cheat Sheet on Tech Exam Lexicon, then return to IT Mastery for timed practice.