Docker containerization in NestJS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What happens when you run this Dockerfile for a NestJS app?

Consider this Dockerfile for a NestJS application:

FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build
EXPOSE 3000
CMD ["node", "dist/main.js"]

What will be the behavior when you build and run this container?

NestJS

FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build
EXPOSE 3000
CMD ["node", "dist/main.js"]

A The container will fail because node:18-alpine does not support npm.

B The container will fail because the build output is not copied to the container.

C The container will start but the app will listen on a random port, not 3000.

D The container will start the NestJS app listening on port 3000 as expected.

💡 Hint

Think about what the Dockerfile commands do step-by-step and what port the app listens on.

This Dockerfile installs dependencies, copies source code, builds the NestJS app, exposes port 3000, and runs the built app. The app listens on port 3000, so the container behaves as expected.

📝 Syntax

intermediate

Which Dockerfile command correctly copies only production dependencies for NestJS?

You want to create a smaller Docker image by installing only production dependencies for your NestJS app. Which Dockerfile snippet correctly does this?

A RUN npm ci --only=production

B RUN npm install --only=production

C RUN npm install --prod

D RUN npm install --production=true

💡 Hint

Check the official npm documentation for the correct flag to install only production dependencies.

The npm install --prod flag installs only production dependencies. It is the standard shorthand for --production.

🔧 Debug

advanced

Why does this NestJS Docker container fail to start?

Given this Dockerfile snippet:

FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build
EXPOSE 3000
CMD ["node", "main.js"]

When running the container, it fails with Cannot find module './main.js'. Why?

A The CMD should run <code>node dist/main.js</code> because the build output is in the dist folder.

B The package.json is missing, so npm install did not run correctly.

C The EXPOSE 3000 command is missing, so the app cannot start.

D The WORKDIR is incorrect; it should be /usr/src/app.

💡 Hint

Think about where the compiled JavaScript files are placed after npm run build.

By default, NestJS outputs compiled files to the dist folder. The CMD must point to dist/main.js, not main.js in the root.

❓ state_output

advanced

What is the value of NODE_ENV inside this NestJS Docker container?

Consider this Dockerfile snippet:

FROM node:18-alpine
WORKDIR /app
ENV NODE_ENV=production
COPY package*.json ./
RUN npm install --prod
COPY . .
RUN npm run build
EXPOSE 3000
CMD ["node", "dist/main.js"]

What will be the value of process.env.NODE_ENV inside the running NestJS app?

A "production"

B undefined

C "development"

D "test"

💡 Hint

Look at the ENV command in the Dockerfile and how environment variables are set.

The ENV NODE_ENV=production sets the environment variable inside the container, so process.env.NODE_ENV will be "production".

🧠 Conceptual

expert

Which Dockerfile layering strategy optimizes build speed for NestJS apps?

You want to optimize Docker build speed for your NestJS app during development. Which layering strategy is best?

A Run npm install first, then copy package.json and source code, then build.

B Copy package.json and package-lock.json, run npm install, then copy source code and build.

C Copy all source code first, then package.json, then run npm install and build.

D Copy source code and package.json together, then run npm install and build.

💡 Hint

Think about which files change frequently and which do not, to leverage Docker cache.

Copying package.json and package-lock.json first and running npm install allows Docker to cache dependencies. Then copying source code and building means changes to source code don't rerun npm install, speeding up builds.