JavaScript-Developer-I Salesforce Certified JavaScript Developer (JS-Dev-101) Questions and Answers

Node.js provides two built-in modules for creating servers:

http → creates non-secure HTTP servers

https → creates secure HTTPS servers

A secure server requires:

SSL/TLS certificates (key and cert)

The built-in Node.js module designed to handle these: https

Syntax for a secure server:

const https = require( ' https ' );

const fs = require( ' fs ' );

const options = {

key: fs.readFileSync( ' key.pem ' ),

cert: fs.readFileSync( ' cert.pem ' )

};

https.createServer(options, (req, res) = > {

res.write( ' Secure Server ' );

res.end();

}).listen(443);

Evaluation of options:

A is incorrect: No built-in module named secure-server exists.

B is incorrect: tls provides low-level TLS sockets, not HTTP/HTTPS servers.

C is incorrect: http only creates an insecure server.

D is correct: https is the built-in module required for secure web servers.

JavaScript Knowledge References (text-only)

Node.js exposes built-in modules http and https for server creation.

Secure servers require the https module, which supports TLS/SSL.

The tls module is lower-level and not used for full HTTP servers.

==================================================

Currently:

sayHello expects a value name and prints it.

world is a function that returns ' World ' .

sayHello(world); passes the function object itself, not the result of calling it.

So name inside sayHello is a function, not the string " World " .

To keep the call sayHello(world) yet get " World " , sayHello must call the function parameter:

const sayHello = (name) = > {

console.log( ' Hello ' , name());

};

Now:

sayHello(world) passes the function.

Inside sayHello, name() calls world(), which returns " World " .

The console logs " Hello World " .

Why the others are wrong:

B: Changing line 7 to }(); would attempt to IIFE the function definition and break the declaration.

C: sayHello(world)() would try to call the return value of sayHello, which is undefined, causing an error.

D: Changing world to a function declaration does not change the fact that it is passed as a function reference; sayHello still prints the function object, not ' World ' .

In JavaScript server-side development using Node.js, dependency management is typically handled through package managers such as npm or yarn . These tools categorize installed packages into:

dependencies – required for running the application in any environment

devDependencies – required only during development (testing tools, build tools, documentation generators, etc.)

When a package is installed using:

yarn add < package > --dev

it is placed under the " devDependencies " section of package.json.

Behavior of Production Mode

Node.js uses the environment variable:

NODE_ENV=production

When this environment variable is set to production, both npm and Yarn follow the standard Node.js convention and skip installing devDependencies . This is done to optimize production builds and reduce deployment size. This is a known and documented behavior in Node.js package management tools.

Therefore, if:

The developer added the date-manipulation library as a dev dependency , and

Other team members execute yarn in an environment where NODE_ENV=production is set,

then Yarn will not install that dependency because devDependencies are intentionally excluded in production mode.

This explains the behavior described in the question.

Why the Other Options Are Incorrect

Option A:

" YARN_ENV is set to production " is incorrect because Yarn does not use the variable YARN_ENV for dependency installation behavior. Node.js tools use NODE_ENV , not YARN_ENV.

Option B:

This is incorrect because Yarn automatically writes dependencies into package.json. Unlike older npm versions, there is no need for the --save flag.

Option D:

There is no such option as --add. The correct syntax is simply:

yarn add < package >

Missing an option that does not exist cannot be the cause.

JavaScript Knowledge References

Node.js uses the environment variable NODE_ENV to determine production or development mode.

Package managers (npm and Yarn) follow the rule that when NODE_ENV=production , only " dependencies " are installed and " devDependencies " are skipped.

Yarn automatically persists installed packages to package.json without requiring --save.

Yarn uses the command yarn add to add dependencies; there is no --add flag.

Comprehensive and Detailed Explanation:

Assuming SaleItem inherits from Item via prototype (e.g. SaleItem.prototype = Object.create(Item.prototype)):

Lines 01–02: create regItem and saleItem.

Line 03: define Item.prototype.description.

Now both regItem and saleItem (via inheritance) have a description method from Item.prototype.

Line 04: regItem.description() → ' This is a Scarf ' .

Line 05: saleItem.description() → ' This is a Shirt ' (same method, but this.name is ' Shirt ' ).

Line 07: SaleItem.prototype.description = ... overrides description only for SaleItem instances going forward.

If we imagine calling regItem.description() and saleItem.description() again after line 07:

regItem.description() still uses Item.prototype.description → ' This is a Scarf ' .

saleItem.description() now uses SaleItem.prototype.description → ' This is a discounted Shirt ' .

Those four lines correspond to option B.

execute() returns a Promise that immediately calls reject(). So promise starts in a rejected state.

When a Promise is rejected and you chain .then() calls without rejection handlers, all those .then() callbacks are skipped until a .catch() is encountered:

promise

then(...) // skipped

then(...) // skipped

then(...) // skipped

catch(...) // executed

then(...); // executed after catch

Execution:

.then(() = > console.log( ' Resolved1 ' )) is skipped.

.then(() = > console.log( ' Resolved2 ' )) is skipped.

.then(() = > console.log( ' Resolved3 ' )) is skipped.

.catch(() = > console.log( ' Rejected ' )) runs and logs Rejected.

The .catch() returns a resolved Promise (no explicit return, so undefined), so the next .then() runs:

.then(() = > console.log( ' Resolved4 ' )) logs Resolved4.

Final output:

Rejected

Resolved4

This matches option D.

Arrow functions have two defining characteristics:

Implicit return when written as a single expression:

const fn = () = > 5; // returns 5 automatically

This is unique to arrow functions → A is correct.

Lexical this binding : Arrow functions do not create their own this. Instead, they use the this value from the surrounding scope → B is correct.

Incorrect options:

C is false: There is no special argument called parentThis.

D is the opposite of arrow function behavior: Normal functions create their own this; arrow functions do not.

JavaScript Knowledge References (text-only)

Arrow functions have lexical this binding.

Arrow functions support implicit return for single expressions.

==================================================

JavaScript has one numeric data type for all real numbers, whether integers or decimals.

This type is simply called:

Number

It follows the IEEE 754 double-precision floating-point standard internally,

but JavaScript does not expose separate types like float, double, or decimal.

Therefore:

It is not Float → JavaScript does not have float primitives.

It is not Double → this refers to the underlying IEEE 754 representation, but JavaScript ' s type is still just “Number.”

It is not Decimal → JavaScript has no built-in decimal type.

The correct answer is Number .

JavaScript Knowledge References (text-only)

JavaScript has a single numeric type: Number.

All numbers—integers, fractions, floating point—use the Number type.

==================================================

When async is added to a function:

async function example() {}

JavaScript guarantees:

The function always returns a Promise , regardless of what is returned inside.

Inside the function, await pauses execution until a Promise resolves.

Code appears synchronous even though it uses asynchronous behavior.

Analysis of each option:

A incorrect: Not " sometimes " —an async function always returns a Promise.

B incorrect: Async functions can be called just like normal functions.

C incorrect: Async/await has nothing to do with classes specifically.

D correct: This is the standard description: “Async functions behave asynchronously but allow writing code that looks synchronous.”

JavaScript Knowledge References (text-only)

async functions always return Promises.

await pauses execution of the async function.

Async/await syntax creates synchronous-looking code on top of asynchronous operations.

The verified answer is A .

This constructor function runs when new Person() is called:

function Person() {

this.firstName = " John " ;

}

So this line:

const myFather = new Person();

creates an object like this:

{

firstName: " John "

}

Then the prototype is assigned a method named job:

Person.prototype = {

job: x = > " Developer "

};

Because myFather is created from Person, it can access properties and methods from Person.prototype.

So:

myFather.firstName

returns:

" John "

And:

myFather.job()

returns:

" Developer "

Therefore:

const result = myFather.firstName + " " + myFather.job();

becomes:

const result = " John " + " " + " Developer " ;

Final value:

" John Developer "

Option B is incorrect because job() returns " Developer " , not undefined.

Option C is incorrect because job exists on Person.prototype, so it is callable.

Option D is incorrect because firstName is assigned inside the constructor.

Therefore, the verified answer is A .

We want to guarantee that the result is of type string regardless of what var1 and var2 are (numbers, booleans, etc.).

Option A:

String(var1).concat(var2)

String(var1) converts var1 explicitly to a string.

.concat(var2) calls String.prototype.concat, which:

Converts var2 to string if needed.

Returns a new string that is the concatenation of the two.

Result is always a string. So A is valid.

Option B:

String.concat(var1 + var2)

String.concat (as a static method) does not exist. concat is an instance method on string objects, not on the String constructor.

var1 + var2 might be a number (if both numeric) and used incorrectly here. So B is invalid.

Option C:

var1 + var2

+ can mean:

String concatenation (if at least one operand is a string).

Numeric addition (if both operands are numbers).

If var1 and var2 are both numbers, var1 + var2 will be a number, not a string.

This does not ensure the result is always a string. So C is not guaranteed to satisfy the requirement.

Option D:

var1.toString() + var2.toString()

var1.toString() converts var1 to a string (for most primitive/object types).

var2.toString() does the same.

Now both operands of + are strings, so the result is string concatenation.

Result is guaranteed to be a string. So D is valid.

Therefore, the two valid ways are A and D.

Study Guide / Concept References (no links):

String() conversion vs .toString()

String.prototype.concat

+ operator overload: numeric addition vs string concatenation

Type coercion rules for primitives

In JavaScript, NaN has some special properties:

NaN is not equal to anything, including itself.

Equality operators (==, ===) do not work for detecting NaN.

Check each option:

A. value === Number.NaN

Number.NaN is just NaN.

But NaN === NaN is always false.

So this expression is never true and cannot be used to detect NaN.

B. value == NaN

Same issue. NaN == NaN is always false.

So this also never detects NaN.

C. Object.is(value, NaN)

Object.is is a more precise equality comparison method.

It treats NaN as equal to NaN: Object.is(NaN, NaN) is true.

So Object.is(value, NaN) is a valid way to detect NaN.

D. value !== value

Because NaN is the only JavaScript value that is not equal to itself , value !== value is true only when value is NaN.

This is a classic trick for NaN detection.

E. Number.isNaN(value)

Number.isNaN is the recommended modern way to check if a value is NaN without coercion .

It returns true only if value is actually the number NaN.

Therefore, the three correct ways are:

Object.is(value, NaN)

value !== value

Number.isNaN(value)

Node.js event-based modules use the EventEmitter pattern.

The correct syntax for listening to events is:

emitter.on( ' eventName ' , callback)

The server library emits an ' error ' event, which must be listened to using .on.

Option analysis:

A: .catch is for Promises, not EventEmitters.

B: .error is not an EventEmitter method.

C: Correct. Listens to the ' error ' event.

D: try...catch only captures synchronous errors, not event-based asynchronous errors.

Therefore, the correct answer is option C .

JavaScript Knowledge References (text-only)

The EventEmitter API uses on(event, handler) to listen for events.

Errors emitted asynchronously cannot be caught with try...catch.

The ' error ' event is standard for Node.js modules to signal operational errors.

To schedule a function for later execution in JavaScript, the standard built-in method is:

setTimeout(functionReference, delayInMilliseconds)

Characteristics of setTimeout():

Executes only once .

Delay is specified in milliseconds.

Requires passing the function reference , not calling the function.

Two minutes is:

2 minutes = 120 seconds = 120,000 milliseconds

Now evaluate each option:

Option A: delay(sayHello, 120000);

Incorrect.

There is no built-in delay() function in JavaScript.

Option B: setTimeout(sayHello, 120000);

Correct.

sayHello is passed as a function reference , so it will execute once after 120,000 ms.

Option C: setTimeout(sayHello(), 120000);

Incorrect.

sayHello() calls the function immediately , and the return value (undefined) is passed to setTimeout.

This executes the function right away instead of after two minutes.

Option D: setInterval(sayHello, 120000);

Incorrect.

setInterval() repeats execution every 120,000 ms.

The question requires executing the function once , so this cannot be correct.

JavaScript Knowledge References (text-only)

setTimeout() schedules a function to run once after a specified delay.

Passing functionName gives a reference; passing functionName() invokes it immediately.

setInterval() repeats indefinitely, unlike setTimeout().

==========================================

ES Modules follow these rules:

Default exports are imported using:

import anyName from ' module '

The name chosen in the import does NOT need to match the exported name.

If a module exports:

export default function printDate() {}

then consuming code should import the function directly:

import printDate from ' /path/DatePrettyPrint.js ' ;

To execute it:

printDate();

Option analysis:

A incorrect: import DatePrettyPrint() is invalid syntax. Also calling printDate() without importing it is incorrect.

B incorrect: A default export imported as DatePrettyPrint gives the function itself, not an object containing methods. You cannot call DatePrettyPrint.printDate().

C incorrect: Imports printDate but then calls DatePrettyPrint.printDate(), which does not exist.

D correct: Correct import of a default-exported function. Correct direct invocation.

JavaScript Knowledge References (text-only)

Default export → imported without braces.

Importing default functions gives a callable function, not an object.

Correct syntax: import identifier from " module " .

==================================================

The verified answer is C .

This object has two properties:

let obj = {

foo: 1,

bar: 2

};

The property names are:

foo

bar

The property values are:

1

2

The loop used here is a for...in loop:

for (let something in obj) {

output.push(something);

}

A for...in loop iterates over the property keys of an object, not the property values.

So during the first iteration:

something === " foo "

The code pushes " foo " into the array.

During the second iteration:

something === " bar "

The code pushes " bar " into the array.

The final value of output is:

[ " foo " , " bar " ]

That is why:

console.log(output);

prints:

[ " foo " , " bar " ]

Option B would be correct only if the code pushed the values, for example:

output.push(obj[something]);

Option D would require building formatted strings manually, such as:

output.push(`${something}:${obj[something]}`);

But the given code only pushes the property names.

Therefore, the verified answer is C .

The answer is B because JavaScript uses lexical scope .

When a function is created inside another function, the inner function can access variables from the outer function where it was defined.

For example:

function first() {

let a = 10;

function second() {

console.log(a);

}

second();

}

Here, a belongs to the outer function first(). The inner function second() can access it because JavaScript looks for variables through the scope chain.

The lookup works like this:

1. Look inside second()

2. If not found, look inside first()

3. If not found, look in the global scope

Since a is found in the outer function’s scope, second() can use it.

This is also the basis of a closure . A closure allows an inner function to remember and access variables from its outer lexical environment.

Why the other options are incorrect:

A is not the best answer because a is not declared inside second() itself.

C is incorrect because the prototype chain is used for object property lookup, not local variable scope lookup.

D is incorrect because hoisting explains how declarations are moved during compilation, but it does not explain why an inner function can access an outer function’s variable.

Therefore, the verified answer is B .

1. Getter Functions in JavaScript

In JavaScript, when an object uses the get keyword, it defines a getter method . Accessing a getter property executes the function and returns its value. Thus:

o.js

does not return the getter function; instead, it executes the function located at:

get js() { ... }

and returns the object inside the return block.

2. Behavior of String() and toLowerCase()

Inside the getter:

let city1 = String( ' St. Louis ' );

let city2 = String( ' New York ' );

String() creates a string value.

Then, the returned object is constructed as:

{

firstCity: city1.toLowerCase(),

secondCity: city2.toLowerCase(),

}

The method toLowerCase() is a standard JavaScript string method that returns a new string with all alphabetic characters converted to lowercase .

Therefore:

city2.toLowerCase()

returns:

' new york '

3. Referencing the Property

When the developer writes:

o.js.secondCity

the following happens:

The getter js runs and returns an object.

The returned object includes the property:

secondCity: ' new york '

Accessing .secondCity retrieves the lowercase string ' new york ' .

Therefore, the correct value is ' new york ' .

Why the Other Options Are Incorrect

A. undefined – incorrect because the property secondCity clearly exists in the returned object.

B. An error – incorrect because no invalid operations occur; all methods and properties are valid.

C. ' New York ' – incorrect because toLowerCase() transforms the string to lowercase.

JavaScript Knowledge References (Text-Based)

Getter methods using the get keyword return computed values when accessed.

JavaScript String values support the toLowerCase() method, which returns a lowercase version of the original string.

Accessing nested properties like o.js.secondCity triggers the getter, returning the constructed object.

Browsers often cache JavaScript, CSS, and HTML. This means:

The developer may be running with the latest version (often with cache disabled in DevTools).

The tester may still be loading an older, cached version of the page where the background-change logic does not exist.

To ensure they are actually testing the latest deployed code:

Disabling cache (A) in the tester’s browser (usually via DevTools → Network → “Disable cache”) forces fresh loading of all resources on each refresh.

Clearing cache (C) removes older resources from the browser so the next load fetches fresh files from the server.

Options B and D do not directly help verify the tester is using the latest code:

B checks the developer’s own browser, which is not the environment showing the problem.

D suggests reworking the code before confirming whether the tester is actually loading the correct version, which is premature.

So the two actions that help produce accurate testing results are A and C.

Definitions:

False negative → The test reports a failure even though the feature actually works.

False positive → The test reports success when it should not.

True positive → Correctly identifies something is working.

True negative → Correctly identifies something is not working.

In this scenario:

The checkout button does exist , so the feature works.

The test fails incorrectly , because it is checking for the wrong selector.

That is the definition of a false negative .

JavaScript Knowledge References (text-only)

Test outcome classification: false negative = feature works but test fails.

==================================================

Inside setCurrentUrl, url is assigned without var, let, or const :

url = window.location.href;

In non–strict mode, this implicitly creates a global variable url on window.

Execution order:

setCurrentUrl(); creates/sets global url to window.location.href.

console.log( " The current URL is: " + url); has access to url in global scope and prints correctly.

Thus:

url has global scope.

Line 02 runs without error and logs a valid string.

So B is correct.

Initial array:

[1, 2, 3, 4, 4, 5, 4, 4]

The loop removes every value equal to 4:

array.splice(i, 1) removes the element at index i and shifts all later elements left.

i-- ensures the next index is checked correctly after the shift, preventing skipping elements.

Step-by-step removal:

Remove the first 4 → array becomes [1,2,3,4,5,4,4]

Remove next 4 → [1,2,3,5,4,4]

Remove next 4 → [1,2,3,5,4]

Remove last 4 → [1,2,3,5]

Final result:

[1,2,3,5]

Option B is correct.

JavaScript Knowledge References (text-only)

splice(index, deleteCount) removes elements and shifts remaining items.

Adjusting the loop index when deleting prevents skipping items.

Arrays update length dynamically after splice().

document.querySelector( ' #row-as ' ) returns the single element with id row-as.

That element has a classList property with add, remove, etc.

Correct usage:

document.querySelector( ' #row-as ' ).classList.add( ' priority-account ' );

Why others are wrong:

A: querySelectorAll returns a NodeList, not a single element, so it does not have a classList property.

C: DOM elements do not have a classes array or push; they have classList.

D: document.getElementById( ' row-as ' ) is fine to get the element, but there is no addClass method in standard DOM; that’s a jQuery-style API, not vanilla JS.

Facts about JavaScript Promises:

runParallel() is declared async, which means it always returns a Promise .

Promises are consumed using .then(), .catch(), and .finally().

There is no .done() method in native JavaScript Promises.

The async keyword cannot be placed before a function call (option A is invalid syntax).

Analysis of each option:

A. async runParallel().then(data);

Invalid syntax. async cannot prefix an expression.

B. Valid. Calls the function and attaches a .then() handler.

C. Invalid. .done() is not part of JavaScript Promise API.

D. Valid. Calls runParallel() and chains .then().

Therefore the correct answers are B and D.

JavaScript Knowledge References (text-only)

async functions return Promises.

Promises use .then() to retrieve resolved values.

.done() is not part of the standard Promise interface.

==================================================

The correct answer is C .

The typing errors in the options should be corrected as follows:

event.stopPropagation();

The stopPropagation() method is used to stop an event from continuing through the DOM event propagation path.

A click event normally goes through these phases:

Capturing phase → Target phase → Bubbling phase

Because the event listener is attached to the button:

el.addEventListener( " click " , printMessage, false);

the function printMessage receives the click event when the button is clicked. To stop the event from bubbling up to parent elements, the event object should be accepted as a parameter and stopPropagation() should be called inside the event handler.

Corrected code:

< html >

< body >

< div id= " logo " > Hello Logo! < /div >

< button id= " test " > Click me < /button >

< /body >

< script >

function printMessage(event) {

event.stopPropagation();

console.log( ' This is a test message ' );

}

let el = document.getElementById( ' test ' );

el.addEventListener( " click " , printMessage, false);

< /script >

< /html >

Why this is correct:

event.stopPropagation();

prevents the click event from moving upward to ancestor elements after the button’s handler runs.

Why the other options are incorrect:

A and B are incorrect because removeEventListener() is used to remove a previously registered event listener. It does not stop event bubbling for the current event.

D is incorrect because stopPropagation() should be called inside the active event handler that receives the event object. In this case, that function is:

printMessage(event)

Therefore, the verified answer is C .

The correct answer is C , after correcting the option text to match the actual code.

The object is created here:

let student = new GraduateStudent( " Jane " );

Because GraduateStudent extends Student, its constructor runs:

constructor(name) {

super(name);

this._name = " Graduate Student " + name;

}

The call to:

super(name);

runs the parent Student constructor first and temporarily sets:

this._name = " Jane " ;

Then this line in the child constructor overwrites that value:

this._name = " Graduate Student " + name;

So the final value of this._name becomes:

" Graduate Student Jane "

Next, this line executes:

student.displayGrade();

Since student is an instance of GraduateStudent, JavaScript uses the overridden displayGrade() method from GraduateStudent, not the parent method from Student.

The executed method is:

displayGrade() {

console.log(`${this._name} got 100% on test.`);

}

Therefore, the console output is:

Graduate Student Jane got 100% on test.

Important correction: the original option C said something like " Better student Jackie got 100% on test. " , but the actual code uses " Graduate Student " and the name " Jane " . The verified corrected answer remains C .

The verified corrected answers are C, D, and E .

This function is a normal function, not a curried function:

function sum(num1, num2, num3) {

if (num3 === undefined) {

num3 = 0;

}

return num1 + num2 + num3;

}

It expects values to be passed in the same function call:

sum(num1, num2, num3);

Now check the valid corrected options.

Option C:

sum(5, 5, 0);

Calculation:

5 + 5 + 0

Result:

10

So C is correct .

Option D:

sum(10, 0);

Here, num3 is not provided, so it is undefined.

The function checks:

if (num3 === undefined) {

num3 = 0;

}

So the calculation becomes:

10 + 0 + 0

Result:

10

So D is correct .

Option E:

sum(5, 2, 3);

Calculation:

5 + 2 + 3

Result:

10

So E is correct .

Why A and B are incorrect as originally written:

sum(5)(5);

This calls sum(5) first. Since num2 is missing, the result becomes NaN. Then JavaScript tries to call that returned value as a function, which causes a TypeError.

sum()(10);

This also calls sum() first, producing NaN, and then attempts to call NaN as a function.

Those styles would only work if sum were written as a curried function, but the given implementation is not curried.

Therefore, the verified corrected answers are C, D, and E .

We want to convert the number 1982 to a string.

Check each option:

A. numValue.toText()

There is no standard toText() method on numbers.

This will result in TypeError: numValue.toText is not a function.

B. String(numValue);

String() as a function converts its argument to a string.

String(1982) returns " 1982 " .

This is correct.

C. ' ' + numValue;

' ' is a string; + with a string operand performs string concatenation.

' ' + 1982 → " 1982 " .

This is a common shorthand for number-to-string conversion.

D. numValue.toString();

Number.prototype.toString() converts the number to its string representation.

1982..toString() or (1982).toString() returns " 1982 " .

For the variable, numValue.toString() is valid: " 1982 " .

E. (String)numValue;

This is not valid JavaScript casting syntax; it is more like a C/Java-style cast.

In JavaScript, that is parsed as a grouping expression (String) and then numValue; it does not convert numValue to a string.

Thus the correct answers are:

B. String(numValue);

C. ' ' + numValue;

D. numValue.toString();

Relevant concepts: primitive type conversion, String() casting, .toString(), coercion via + with strings.

In ES6 class syntax, the special method used to initialize a new instance is called constructor.

A class definition syntax:

class ClassName {

constructor(param1, param2) {

this.prop1 = param1;

this.prop2 = param2;

}

}

The constructor method:

Is called automatically when you create a new instance with new ClassName(...).

Receives the arguments passed in the new expression.

Assigns values to this to set instance properties.

Applying this to Story

We want to be able to write:

const article = new Story( ' Some body ' , ' Author Name ' , 100);

and have:

article.body === ' Some body '

article.author === ' Author Name '

article.viewCount === 100

To achieve this, the class must have:

class Story {

constructor(body, author, viewCount) {

this.body = body;

this.author = author;

this.viewCount = viewCount;

}

}

So the correct line 02 is:

constructor(body, author, viewCount) {

Why the other options are incorrect

A. constructor() {

This defines a constructor with no parameters.

The lines inside the constructor use body, author, and viewCount, which would be undefined unless they exist in an outer scope (they normally do not).

This would lead to the instance properties being set to undefined in normal usage.

B. super(body, author, viewCount) {

super(...) is used inside a constructor of a subclass to call the parent class constructor.

You cannot use super(...) { as a method definition; this is invalid syntax in a class body.

Additionally, Story as given is not shown extending any class, so super is inappropriate here.

C. function Story(body, author, viewCount) {

Inside a class definition, you do not use the function keyword to define methods.

function Story(...) here would be invalid syntax in a class body.

Even if it were allowed, the special constructor method for a class is named constructor, not the class name.

Therefore, only:

constructor(body, author, viewCount) {

correctly declares the constructor for the Story class and ensures instances created with new Story(body, author, viewCount) have all three properties populated.

References / Study Guide concepts (no links):

ES6 class syntax

constructor method in classes

this and instance properties in classes

Difference between class constructors and regular functions

Invalid use of super and function inside class bodies

userInformation is a plain JavaScript object:

{

id: " user-01 " ,

email: " user01@universalcontainers.demo " ,

age: 25

}

You can access object properties in two standard ways:

Dot notation : object.propertyName

Bracket notation : object[ ' propertyName ' ]

Apply to each option:

A. userInformation.email

Correct dot notation; accesses " user01@universalcontainers.demo " .

B. userInformation.get( " email " )

.get() is a method on Map instances, not on plain objects.

A regular object does not have a .get method; this would be TypeError.

C. userInformation[ " email " ]

Correct bracket notation; string " email " is used as the property key.

Returns " user01@universalcontainers.demo " .

D. userInformation[email]

Here email is treated as a variable, not a string literal.

Unless there is a variable named email defined with a value matching a property key, this will either:

Throw a ReferenceError (if email is not defined), or

Use the value of email as a computed key (not what is intended here).

It is not the correct way to access the " email " property literal.

Therefore, the correct ways are:

Answer: A, C

Relevant concepts: object property access (. vs []), plain objects vs Map, literal property names vs computed property names.

We have an array of plain objects:

[

{ name: ' John ' , email: ' john@email.com ' },

{ name: ' Jane ' , email: ' jane@email.com ' },

{ name: ' Emily ' , email: ' emily@email.com ' }

]

We want:

A “visual representation” of the list.

Ability to sort by name or email in DevTools.

console.table:

console.table(data) renders data as a table in most browser devtools and Node consoles that support it.

Each object becomes a row; properties (name, email) become columns.

Many DevTools UIs allow:

Clicking column headers to sort by that column.

Filtering / viewing in a structured way.

So:

console.table(usersList);

Displays a sortable table of users by name or email. This matches the requirement exactly.

Other options:

console.group(usersList);

Starts a console group. The argument is just logged as a line label.

It does not create a table or sortable view; it just groups subsequent logs.

console.groupCollapsed(usersList);

Same grouping behavior, but collapsed by default.

Again, no table or sortable columns.

console.info(usersList);

Logs the array in the console, but as a standard log/info.

You can expand objects, but there is no table view or built-in column sorting.

Therefore, the correct method is:

Answer: A

Study Guide / Concept References (no links):

console.table for tabular logging

console.group and console.groupCollapsed for grouped logs

console.log / console.info standard logging behavior

DevTools UI support for sorting columns in console.table

In JavaScript, when calling a constructor function without new:

const m = Monster();

the following happens:

The function executes as a normal function , not as a constructor.

Inside a regular function (in non-strict mode), this refers to the global object :

In a browser: window

So the line:

this.name = ' hello ' ;

becomes:

window.name = ' hello ' ;

Since Monster() does not return anything, its return value is undefined:

const m = undefined;

Therefore:

m is undefined

window.name becomes " hello "

This matches option B .

JavaScript Knowledge References (text-only)

Calling a function without new uses the global object as this in non-strict mode.

Constructor functions must use new to create a new object.

Functions without an explicit return return undefined.

The browser console (Developer Tools → Console) allows:

Running code unrelated to the page Developers can type arbitrary JavaScript not tied to the page’s logic. This is allowed → A is correct.

Viewing and modifying JavaScript code execution Using the Sources tab and console, developers can:

Inspect variables

Modify code at runtime

Set breakpoints Therefore → D is correct.

Viewing and manipulating the DOM From the console, developers can:

Query DOM nodes using selectors

Modify element properties and attributes

Insert or remove elements Therefore → E is correct.

Why the other options are incorrect:

B (security cookies) Many cookies have flags such as HttpOnly and Secure. Cookies with the HttpOnly flag cannot be viewed or modified via JavaScript or console. Therefore this is not guaranteed → incorrect.

C (performance report) The console itself does not provide a performance report. The Performance or Lighthouse tabs provide this, not the console. Therefore incorrect.

JavaScript Knowledge References (text-only)

Developer console can execute arbitrary JavaScript.

Console allows DOM inspection and manipulation.

Security cookies (HttpOnly) cannot be accessed via JavaScript.

==================================================

Behavior of non-strict global code The script does not begin with a ' use strict ' directive at the top level, so the global code (outside any function) runs in non-strict (sloppy) mode.

Line 01: x = 3.14; In non-strict mode, assigning to an undeclared identifier (no var, let, or const) creates an implicit global variable. So after line 01, x exists and equals 3.14.

Line 08: z = x; This also runs in non-strict mode. Since x is already defined (from line 01), z is set to 3.14. Therefore, statement B is correct: z is equal to 3.14.

Scope of ' use strict ' inside a function The line:

' use strict ' ;

inside myFunction is a directive prologue for that function, not for the entire file. This means:

Strict mode applies only within the body of myFunction , from the directive to the end of that function.

It does not retroactively affect code before the function or code outside of it.

Therefore:

Statement A is incorrect: ' use strict ' is not “hoisted” to affect the whole file. It only affects the function body.

Statement C is incorrect: strict mode does not apply from line 04 to the end of the file; it only applies within myFunction, not to global lines like 01, 08, or 09.

Execution of myFunction in strict mode When myFunction is called on line 09:

function myFunction() {

' use strict ' ;

y = x;

}

Within this function:

Strict mode is active for its body.

In strict mode, assigning to an undeclared variable (like y here) is not allowed and results in a ReferenceError at runtime.

So line 05:

y = x;

throws a ReferenceError because y is not declared with var, let, or const.

Therefore, statement E is correct: line 05 throws an error.

Why statement D is considered correct Statement D says: ' use strict ' has an effect only on line 05.

In terms of execution in this specific code:

The only executable statement in myFunction that is affected by strict mode is the assignment on line 05.

The directive itself on line 04 is not a “normal” runtime operation; it is a directive that sets the mode.

There are no other statements inside the function that behave differently under strict mode; only the line that assigns to the undeclared variable shows a strict-mode effect.

So, describing the practical execution behavior of this snippet, strict mode manifests its effect only on line 05, making statement D correct in this context.

Summary of each option:

A: Incorrect – strict does not apply to all lines in the file.

B: Correct – z becomes 3.14 in non-strict global code.

C: Incorrect – strict does not affect code outside the function.

D: Correct – in this code, the only behavioral effect of strict mode is on line 05.

E: Correct – line 05 throws a ReferenceError due to assignment to undeclared y under strict mode.

JavaScript knowledge references (descriptive, no links):

In non-strict (sloppy) mode, assigning to an undeclared identifier creates a global variable.

' use strict ' inside a function body enables strict mode for that function only.

In strict mode, assigning to an undeclared variable results in a ReferenceError.

Directive prologues ( ' use strict ' ) affect only their containing function or script, not other scopes.

==================================================

The correct answers are B and D .

A strong test case checks whether the actual output matches the expected behavior of the function.

For Option B :

let res = fizzbuzz(15);

console.assert(res === ' fizzbuzz ' );

The number 15 is divisible by both 3 and 5:

15 % 3 === 0

15 % 5 === 0

So the correct return value is:

' fizzbuzz '

That makes option B a valid test.

For Option D :

let res = fizzbuzz(Infinity);

console.assert(res === ' ' );

Infinity is not a normal finite divisible number. In JavaScript:

Infinity % 3

Infinity % 5

produce NaN, and comparisons such as:

Infinity % 3 === 0

are false.

So a typical fizzbuzz implementation would not treat Infinity as divisible by 3 or 5, meaning it should return:

' '

That makes option D a valid test for the “neither divisible by 3 nor 5” path.

Now compare the incorrect options:

Option A is wrong because:

fizzbuzz(3)

should return:

' fizz '

not:

' buzz '

Option C is wrong because the function specification says the function returns strings such as ' fizz ' , ' buzz ' , ' fizzbuzz ' , or ' ' . It does not say the function returns numeric NaN.

So this assertion is not appropriate:

console.assert(isNaN(res));

Therefore, the verified answers are B and D .

Key points:

Function declarations are hoisted (their definitions are available before the line where they appear).

Function expressions assigned to const or let are not hoisted as callable functions, but here anotherFlag is only used after it is defined.

Step-by-step:

flag(); at the top:

flag is a function declaration defined later; due to hoisting, it is available.

It logs ' flag ' .

The declaration:

function flag() {

console.log( ' flag ' );

}

is already in effect (hoisted before execution).

const anotherFlag = () = > { console.log( ' another flag ' ); } defines anotherFlag as an arrow function.

anotherFlag(); is called after its definition; this is valid and logs ' another flag ' .

No errors occur. The console output is:

flag

another flag

So option D is correct.

Concepts: function hoisting, difference between function declarations and function expressions, execution order.

The correct answer is A .

JavaScript evaluates the expression from left to right:

true + 3 + ' 100 ' + null

Step 1:

true + 3

In numeric addition, true is converted to:

1

So:

true + 3

becomes:

1 + 3

Result:

4

Step 2:

4 + ' 100 '

Because one operand is a string, JavaScript performs string concatenation instead of numeric addition.

So:

4 + ' 100 '

becomes:

" 4100 "

Step 3:

" 4100 " + null

Again, because one operand is already a string, JavaScript converts null into the string:

" null "

So the final result is:

" 4100null "

Execution summary:

true + 3 + ' 100 ' + null

// 1 + 3 + ' 100 ' + null

// 4 + ' 100 ' + null

// " 4100 " + null

// " 4100null "

Therefore, the verified answer is A .

We want mechanisms that persist data between page loads (i.e., after refresh or navigation), in the browser.

A. localStorage

Part of the Web Storage API.

Data persists across page reloads and browser restarts (until explicitly cleared).

Scoped per origin (protocol + host + port).

This is a correct persistent storage API.

B. indexedDB

A low-level, client-side NoSQL database in the browser.

Stores large amounts of structured data and persists across reloads and sessions.

This is also a correct persistent API.

C. cookies

Small key/value pairs stored by the browser and often sent with HTTP requests.

Can have expiration dates and persist across page loads and sessions.

They are a traditional persistence mechanism in browsers.

So cookies also qualify.

D. global variables

Global JS variables exist only for the life of the current page context.

When the page is refreshed or navigated away, they are lost.

They do not persist between page loads.

E. IIFEs (Immediately Invoked Function Expressions)

A pattern for creating a new scope, not a persistence mechanism.

Variables inside an IIFE are still lost when the page reloads.

Thus, the three persistent browser APIs are:

localStorage

indexedDB

cookies

We have a ternary:

account.style.display = accountName.includes(parsedSearchString)

? /* if true */

/* if false */;

Requirement:

If the account matches the search string → show it.

If it does not match → hide it.

For display:

Show: ' block ' (or similar visible value).

Hide: ' none ' .

So we want:

account.style.display = accountName.includes(parsedSearchString)

? ' block '

' none ' ;

That corresponds to option A.

Why others are wrong:

B, C use values suitable for visibility, not display.

D ( ' none ' : ' block ' ) inverts the logic, hiding matches and showing non-matches.

Expression:

true + ' 13 ' + NaN

The + operator is left-associative, so evaluation order:

true + ' 13 '

When one operand is a string, + performs string concatenation.

true is converted to string ' true ' .

' true ' + ' 13 ' → ' true13 ' .

Result from step 1 with NaN:

' true13 ' + NaN

Again, one operand is a string, so concatenation.

NaN is converted to string ' NaN ' .

' true13 ' + ' NaN ' → ' true13NaN ' .

Final value: ' true13NaN ' .

So A is correct.

Why others are wrong:

B: ' 113NaN ' would require true to coerce to 1 first and no string to be present, which is not the case because ' 13 ' forces string concatenation.

C: 14 would require pure numeric addition, which is not the case once a string is involved.

D: ' true13 ' ignores the final + NaN part.

Concepts: type coercion with +, boolean to string, NaN to string, left-associative evaluation.

The correct answer is C .

The browser provides the History API through:

window.history

To add a new entry to the browser’s session history without refreshing the page, JavaScript uses:

window.history.pushState(state, title, url);

So the valid statement is:

window.history.pushState(newStateObject, ' ' , null);

This updates the browser history stack without forcing a full page reload. It is commonly used in single-page applications when changing views or routes dynamically.

The method accepts three arguments:

window.history.pushState(stateObject, title, url);

stateObject stores custom data associated with the history entry.

title is usually passed as an empty string because many browsers ignore it.

url optionally changes the displayed URL. Passing null means no new URL is provided.

Option A is incorrect because:

window.customHistory

is not the standard browser History API object.

Option B is incorrect because:

createState()

is not a valid History API method.

Option D is incorrect because:

updateState()

is not a valid History API method.

The correct browser API method is:

window.history.pushState()

Therefore, the verified answer is C .

JSON.stringify(john) converts the john object into a JSON string.

When you JSON.parse that string back, you get a plain object :

Only data that can be represented in JSON is preserved (numbers, strings, booleans, arrays, plain objects).

Functions are not preserved and are dropped.

So dan is a plain object with properties firstName and lastName, but no name method .

Therefore, dan.name is undefined, and dan.name() throws:

TypeError: dan.name is not a function

The literal string interpolation inside console.log( ' Hello ${...} ' ) is also wrong (single quotes), but the code never reaches that line.