A developer needs to debug a Node.js web server because a runtime error keeps occurring at one of the endpoints.
The developer wants to test the endpoint on a local machine and make the request against a local server to look at the behavior. In the source code, the server.js file will start the server. The developer wants to debug the Node.js server only using the terminal.
Which command can the developer use to open the CLI debugger in their current terminal window?
(With corrected typing errors: node_inspect node inspect, node_start_inspect node start inspect.)
Answer : B
Node.js includes a built-in command-line (CLI) debugger. To use it directly in the terminal, the standard command is:
node inspect server.js
This:
Starts server.js under the Node.js inspector.
Opens the CLI debugger right in the terminal window where you ran the command.
Lets you interactively:
Step through code
Set breakpoints
Inspect variables
Continue execution, etc.
Why B is correct:
Option B (corrected to node inspect server.js) is exactly the standard Node.js command to run a script under the CLI debugger in the current terminal.
It does not rely on any external GUI tools.
You stay entirely in the terminal to debug.
Why the other options are incorrect:
A . node start inspect server.js
There is no start subcommand like this in standard Node.js CLI.
This is not a valid Node.js debugging command.
C . node server.js --inspect
This starts Node.js with the Inspector protocol enabled and is typically used to connect external tools like Chrome DevTools or VS Code.
It does not open the CLI debugger in the current terminal. Instead, it opens a debugging port that other tools attach to.
The question specifically says ''only using the terminal'' and ''open the CLI debugger in their current terminal window'', which points to node inspect, not --inspect.
D . node -i server.js
-i starts Node in interactive REPL mode, optionally after running a script.
This is for an interactive shell, not the Node debugger.
It does not provide breakpoint/step/next/continue debugging features like the CLI debugger.
Therefore, the only option that opens the Node.js CLI debugger in the current terminal is:
Answe r: B
JavaScript / Node.js knowledge / Study Guide references (concept names only, no links):
Node.js CLI debugger: node inspect <script>
Node.js inspector protocol: node --inspect
Difference between CLI debugger and DevTools-based debugging
Node.js command-line options and subcommands
HTML:
The current status of an Order: In Progress
Which JavaScript statement changes 'In Progress' to 'Completed'?
Answer : C
To select an element by ID, JavaScript uses:
document.getElementById('status')
The ID must be passed without any selector prefixes (no dot, no hash).
Then, to update the text inside:
element.innerHTML = 'Completed';
Why the others are wrong:
A uses '.status' which would match a CSS class, not an ID.
B incorrectly prepends #, which is used in CSS selectors but not in getElementById.
D attempts to use .Value with capital V, which is incorrect for DOM text; .value only applies to form elements.
Thus, option C is correct.
JavaScript Knowledge Reference (text-only)
getElementById takes a raw ID string with no prefixes.
innerHTML updates an element's displayed HTML content.
==================================================
Refer to the code below (assuming Promise.race is intended):
let cat3 = new Promise(resolve =>
setTimeout(resolve, 3000, "Cat 3 completes")
);
Promise.race([cat1, cat2, cat3])
.then(value => {
let result = `${value} the race.`;
})
.catch(err => {
console.log("Race is cancelled:", err);
});
(Assuming cat1 and cat2 are similar to earlier examples: cat2 resolves fastest.)
What is the value of result when Promise.race executes?
Answer : A
From earlier pattern (cars/cats race):
One promise resolves the fastest with 'Car 2 completed' (or analogous 'Cat 2 completes').
Promise.race resolves with the first settled promise's value.
In .then, value is 'Car 2 completed' and:
let result = `${value} the race.`;
// 'Car 2 completed the race.'
Thus result is 'Car 2 completed the race.' option A.
A developer publishes a new version of a package with new features that do not break backward compatibility. The previous version number was 1.1.3.
Following semantic versioning formats, what should the new package version number be?
Answer : D
The correct answer is D.
Semantic versioning usually follows this format:
MAJOR.MINOR.PATCH
For the version:
1.1.3
The parts are:
1 = MAJOR
1 = MINOR
3 = PATCH
A package version should be updated based on the type of change:
MAJOR version changes when there are breaking changes.
MINOR version changes when new features are added in a backward-compatible way.
PATCH version changes when backward-compatible bug fixes are added.
The question says the developer added new features that do not break backward compatibility. That means the minor version should increase.
Starting version:
1.1.3
Increase the minor version from 1 to 2, and reset the patch version to 0:
1.2.0
Why the other options are incorrect:
A . 1.2.3 is incorrect because when the minor version increases, the patch version should reset to 0.
B . 1.1.4 is incorrect because that would represent a patch update, usually for bug fixes, not new features.
C . 2.0.0 is incorrect because that would represent a major version update, usually for breaking changes.
D . 1.2.0 is correct because it represents a backward-compatible feature release.
Therefore, the verified answe r is D.
Refer to the code below:
01 function myFunction(reassign) {
02 let x = 1;
03 var y = 1;
04
05 if (reassign) {
06 let x = 2;
07 var y = 2;
08 console.log(x);
09 console.log(y);
10 }
11
12 console.log(x);
13 console.log(y);
14 }
What is displayed when myFunction(true) is called?
Answer : B
This question tests understanding of let (block scope) and var (function scope) in JavaScript.
Initial declarations in the function:
let x = 1; // line 2
var y = 1; // line 3
Here:
x is declared with let, so it is block-scoped to the function body.
y is declared with var, so it is function-scoped to the entire function.
Inside the if (reassign) block (and since reassign is true, we enter it):
if (reassign) {
let x = 2; // line 6
var y = 2; // line 7
console.log(x); // line 8
console.log(y); // line 9
}
Detailed behavior:
let x = 2; on line 6 creates a new block-scoped variable x that exists only inside the if block. It does not change the outer x declared on line 2.
var y = 2; on line 7 declares y with var again, but var is function-scoped. This effectively reassigns the same y defined on line 3 for the entire function. After this line, y is 2 everywhere in the function.
Now, inside the if block:
console.log(x); (line 8) logs the inner block-scoped x, which is 2.
console.log(y); (line 9) logs y, which is the function-scoped y that was set to 2.
So the first two outputs are:
2
2
After the if block, execution continues:
console.log(x); // line 12
console.log(y); // line 13
Outside the if block:
The block-scoped let x = 2; no longer exists; it was only visible inside the if block.
The outer let x = 1; (line 2) is still in scope and has not been changed.
Thus:
console.log(x); (line 12) logs the outer x, which is still 1.
console.log(y); (line 13) logs y which, due to var y = 2; inside the if, is now 2 for the whole function.
Therefore, when myFunction(true) is called, the output in order is:
2 (inner x in if)
2 (function-scoped y after reassignment)
1 (outer x after if)
2 (function-scoped y remains 2)
This corresponds to:
Answer : B (2 2 1 2)
JavaScript knowledge / study guide reference concepts:
let declarations and block scope
var declarations and function scope
Shadowing of variables with let inside a block
Re-declaration and reassignment of var within a function
Execution order of statements and console output
Given the code below:
01 const delay = async delay => {
02 return new Promise((resolve, reject) => {
03 console.log(1);
04 setTimeout(resolve, delay);
05 });
06 };
07
08 const callDelay = async () => {
09 console.log(2);
10 const yup = await delay(1000);
11 console.log(3);
12 };
13
14 console.log(4);
15 callDelay();
16 console.log(5);
What is logged to the console?
Answer : A
Execution order:
Top-level code runs synchronously:
Line 14: console.log(4); logs 4.
Line 15: callDelay(); is called.
Inside callDelay:
Line 9: console.log(2); logs 2.
Line 10: await delay(1000);:
Calls delay(1000).
Inside delay(1000):
Line 3: console.log(1); logs 1.
Line 4: setTimeout(resolve, delay); schedules resolve in 1000 ms.
delay returns a pending Promise. await pauses callDelay here and returns control to the event loop.
Back to top-level:
Line 16: console.log(5); logs 5.
So synchronous log sequence is: 4, 2, 1, 5.
After ~1000 ms:
The setTimeout in delay resolves the Promise.
The await in callDelay resumes.
Line 11: console.log(3); logs 3.
Final log order: 4 2 1 5 3.
Both A and B show the same sequence; one must be chosen, so A is correct.
Concepts: async/await flow, Promise resolution timing, event loop, and ordering of synchronous vs timer callbacks.
Refer to the code below:
01 let country = {
02 get capital() {
03 let city = Number("London");
04
05 return {
06 cityString: city.toString(),
07 }
08 }
09 }
Which value can a developer expect when referencing country.capital.cityString?
Answer : B
In the getter:
let city = Number('London');
The Number() constructor attempts to convert the string 'London' into a numeric value.
'London' is not a valid numeric string.
When JavaScript attempts numeric conversion of a non-numeric string:
Number('London') NaN
Next line:
city.toString()
When city is NaN, calling .toString() yields:
NaN.toString() 'NaN'
The getter returns:
{
cityString: 'NaN'
}
The question asks:
Which value can a developer expect?
The multiple-choice options include NaN, but not 'NaN'.
Given the available choices, the intended correct answer is B (NaN) because the root cause is the Number('London') conversion returning NaN.
JavaScript Knowledge Reference (text-only)
Number(nonNumericString) returns NaN.
NaN.toString() produces 'NaN'.
Getters compute and return their values each time the property is accessed.
==================================================