CCNA Java I/O API and Securing Applications Questions — Page 2 of 2

MCQhard

Refer to the exhibit. What is the most likely cause of this exception?

A.The serialized object is corrupted.

B.The JVM versions are incompatible.

C.The file contains data that is not a serialized object.

D.The class definition has changed and the serialVersionUID is not explicitly defined.

AnswerD

Without an explicit UID, the JVM computes one from the class definition, which changes when the class is modified.

Why this answer

When a class definition changes (e.g., adding/removing fields) and the class does not explicitly declare a `serialVersionUID`, the JVM computes one automatically based on the class structure. After deserialization, if the computed UID differs from the UID stored in the serialized stream, an `InvalidClassException` is thrown. This is the most common cause of deserialization failures in practice.

Exam trap

Oracle often tests the misconception that any deserialization failure is due to file corruption or JVM version mismatch, when in fact the most common cause is an implicit `serialVersionUID` mismatch after a class definition change.

How to eliminate wrong answers

Option A is wrong because a corrupted serialized object typically causes a `StreamCorruptedException` or `EOFException`, not an `InvalidClassException`. Option B is wrong because incompatible JVM versions may cause class loading issues or `UnsupportedClassVersionError`, but the `InvalidClassException` is specifically about mismatched `serialVersionUID` values, not JVM version incompatibility. Option C is wrong because if the file contains data that is not a serialized object, the deserialization attempt would throw a `StreamCorruptedException` or `ClassNotFoundException`, not an `InvalidClassException`.

Practice this question →

MCQmedium

To generate a cryptographically secure random number for a key generation algorithm, which class should be used?

A.ThreadLocalRandom

B.Math.random()

C.Random

D.SecureRandom

AnswerD

SecureRandom is specifically designed for cryptographic use.

Why this answer

D is correct because `SecureRandom` is specifically designed to produce cryptographically strong random numbers suitable for key generation, using algorithms like SHA1PRNG or NativePRNG that meet FIPS 140-2 standards. Unlike other random number generators, it ensures unpredictability and resistance to reverse engineering, which is critical for security-sensitive operations.

Exam trap

The trap here is that candidates often confuse general-purpose random number generators (like `Random` or `ThreadLocalRandom`) with cryptographically secure ones, assuming any 'random' class suffices for security, but the exam specifically tests the distinction that only `SecureRandom` meets the cryptographic strength required for key generation.

How to eliminate wrong answers

Option A is wrong because `ThreadLocalRandom` is optimized for concurrent access but uses a non-cryptographic PRNG (based on a linear congruential generator) and is not suitable for secure key generation. Option B is wrong because `Math.random()` internally uses `Random` and produces predictable sequences that can be reverse-engineered, making it insecure for cryptographic use. Option C is wrong because `Random` uses a 48-bit seed with a linear congruential formula, which is deterministic and predictable if the seed is known, failing to meet cryptographic randomness requirements.

Practice this question →

MCQhard

A developer is designing a service that processes multiple files concurrently. To avoid resource leaks, which practice is essential?

A.Ensure each thread has its own copy of the file handle

B.Use try-with-resources for each AutoCloseable resource

C.Call close() on each stream in a separate try-catch block

D.Use FileLock to prevent concurrent access

AnswerB

try-with-resources guarantees closure of each resource in the correct order, even with exceptions.

Why this answer

Try-with-resources guarantees that each AutoCloseable resource is closed automatically at the end of the statement, even if an exception occurs. This is essential when processing multiple files concurrently, as it prevents resource leaks without requiring explicit close() calls in finally blocks.

Exam trap

The trap here is that candidates may think explicit close() calls in separate try-catch blocks are safer, but they overlook that try-with-resources handles suppression and automatic closure more reliably, especially in concurrent scenarios where resource leaks are harder to detect.

How to eliminate wrong answers

Option A is wrong because each thread having its own copy of the file handle does not prevent resource leaks; it merely avoids shared state issues, but the handles still need to be closed properly. Option C is wrong because calling close() on each stream in a separate try-catch block is error-prone and verbose; it does not guarantee closure if an exception occurs before reaching the close() call, and it can lead to suppressed exceptions being lost. Option D is wrong because FileLock is used for coordinating access to a file across processes, not for preventing resource leaks; it does not handle the automatic closing of file handles.

Practice this question →

MCQeasy

A developer needs to read all lines from a text file named "data.txt" that uses UTF-8 encoding. Which code correctly reads the file using the NIO.2 API?

A.Files.lines(Path.of("data.txt"), StandardCharsets.UTF_8).collect(Collectors.toList())

B.Files.readString(Path.of("data.txt"), StandardCharsets.UTF_8)

C.Files.readAllBytes(Path.of("data.txt")).toString()

D.Files.readAllLines(Path.of("data.txt"), StandardCharsets.UTF_8)

AnswerD

Files.readAllLines directly returns a List<String> with the specified charset, which is the simplest correct approach.

Why this answer

`Files.readAllLines()` reads all lines from a file into a `List<String>`, and it accepts a `Path` and a `Charset` (here `StandardCharsets.UTF_8`) to handle encoding. This method is part of the NIO.2 API and directly fulfills the requirement to read all lines from a UTF-8 encoded file.

Exam trap

The trap here is that candidates often confuse `Files.readString()` (which returns a single string) with `Files.readAllLines()` (which returns a list of lines), or they mistakenly think `Files.readAllBytes().toString()` will convert bytes to text, when in fact it returns the object reference string.

How to eliminate wrong answers

Option A is wrong because `Files.lines()` returns a `Stream<String>` that must be collected (e.g., via `collect(Collectors.toList())`) to get a list, but the question asks for reading 'all lines' and the option as written is syntactically incomplete (missing semicolon) and not the most direct NIO.2 method for this task. Option B is wrong because `Files.readString()` reads the entire file content as a single `String`, not as a list of lines, so it does not meet the requirement to read 'all lines'. Option C is wrong because `Files.readAllBytes()` returns a `byte[]`, and calling `.toString()` on a byte array returns a meaningless representation like `[B@hashcode`, not the file content as lines.

Practice this question →

MCQmedium

Which class from the java.nio.file package is most appropriate for efficiently transferring data between two channels on the same machine?

A.Files.copy(Path, Path)

B.RandomAccessFile.getChannel().write(ByteBuffer)

C.InputStream.transferTo(OutputStream)

D.FileChannel.transferTo(long, long, WritableByteChannel)

AnswerD

Zero-copy transfer between channels.

Why this answer

`FileChannel.transferTo()` (and its counterpart `transferFrom()`) uses the operating system's zero-copy mechanism (e.g., `sendfile()` on Linux or `TransmitFile()` on Windows) to move data directly between file system caches and the target channel without intermediate buffers or user-space copies. This makes it the most efficient approach for transferring data between two channels on the same machine, as it minimizes CPU overhead and memory bandwidth usage.

Exam trap

The trap here is that candidates often confuse high-level convenience methods like `Files.copy()` or `InputStream.transferTo()` with low-level channel operations, failing to recognize that the question specifically asks for 'most efficient' transfer between channels, which requires zero-copy via `FileChannel.transferTo()`.

How to eliminate wrong answers

Option A is wrong because `Files.copy(Path, Path)` is a high-level method that reads the source file into a buffer and writes it to the destination, involving multiple kernel-to-user-space copies, which is less efficient than zero-copy. Option B is wrong because `RandomAccessFile.getChannel().write(ByteBuffer)` requires manually managing a `ByteBuffer` and performing a read-then-write cycle, which adds overhead and does not leverage OS-level zero-copy optimization. Option C is wrong because `InputStream.transferTo(OutputStream)` operates at the stream level, reading bytes into an internal buffer and writing them out, which involves multiple data copies and is not channel-based, thus lacking the direct kernel-to-kernel transfer capability.

Practice this question →