Browse Certification Practice Tests by Exam Family

Java 17 1Z0-829: Controlling Program Flow

Try 10 focused Java 17 1Z0-829 questions on Controlling Program Flow, with explanations, then continue with IT Mastery.

On this page

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

Topic snapshot

FieldDetail
Exam routeJava 17 1Z0-829
Topic areaControlling Program Flow
Blueprint weight6%
Page purposeFocused sample questions before returning to mixed practice

How to use this topic drill

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.

PassWhat to doWhat to record
First attemptAnswer without checking the explanation first.The fact, rule, calculation, or judgment point that controlled your answer.
ReviewRead the explanation even when you were correct.Why the best answer is stronger than the closest distractor.
RepairRepeat only missed or uncertain items after a short break.The pattern behind misses, not the answer letter.
TransferReturn 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.

Sample questions

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.

Question 1

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;.

  • Unreachable code does not apply because total += row; can execute when row != 1.
  • Labels in methods are allowed; the problem is the kind of statement being targeted.
  • Matching break is not required for a label; labels are valid even without any break.

Question 2

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.

  • Ignoring negation leads to FAST:QUEUE, but !overseas is false in the first call.
  • Staying in nested branch leads to REVIEW:PRIORITY, but the second call never enters the vip block.
  • Using outer branch too early leads to QUEUE:QUEUE, but the first call already matched if (vip).

Question 3

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.

  • Indentation grouping fails because Java ignores indentation when deciding which if owns an else.
  • Outer else assumption fails for Version 1 because the nearest unmatched if is if (valid).
  • Compilation ambiguity fails because both versions are legal Java; the grammar resolves the dangling else.

Question 4

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.

  • Outer else assumption fails because the else does not pair with if (x > 5).
  • Inner condition output fails because if (y > 5) is never evaluated when x > 5 is false.
  • Compilation error fails because this dangling else form is syntactically valid Java.

Question 5

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.

  • Labeled break limit fails because break label; can target an enclosing labeled non-loop statement.
  • Unlabeled break scope fails because an unlabeled break exits only the innermost loop or switch.
  • Unlabeled continue target fails because it continues the innermost enclosing loop, not the outermost loop.

Question 6

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.

  • Indentation grouping fails because Java ignores indentation when deciding which if owns an else.
  • Compile error fails because this nested unbraced if/else structure is legal Java syntax.
  • Condition order fails because paid is tested only inside the branch where active is true.

Question 7

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.

  • Full output assumption fails because 9:4 ignores the fail-fast iterator behavior of ArrayList.
  • Original list size fails because the exception occurs before the later size print can run.
  • Array failure first fails because changing an existing array element during iteration is allowed.

Question 8

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.

  • Skipped first body fails to add 10 because the first loop condition is false before its first iteration.
  • Infinite syntax confusion treats the missing condition as invalid, but an omitted for condition is legal.
  • Forever assumption overlooks that break exits the second loop when j == 3.

Question 9

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.

  • Unreachable vs exhaustive: Body R covers every enum constant, but the statement after yield cannot be reached.
  • Missing enum constant: Body T uses compatible enum labels, but leaves HIGH uncovered in a switch expression.
  • Coverage is not enough: Body U covers the enum constants, but case 1 is incompatible with selector type Level.

Question 10

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.

  • Outer first branch fails because stock - reserved is 8, not greater than 10.
  • Nested rush branch fails because rush && reserved > 0 is false when rush is false.
  • Outer fallback fails because the matching outer else if prevents the final else from running.

Continue with full practice

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

Free review resource

Read the Java 17 1Z0-829 Cheat Sheet on Tech Exam Lexicon, then return to IT Mastery for timed practice.

Revised on Thursday, May 14, 2026