Docker deployment for Deno - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What is the output when running this Deno Docker container?

Consider this Dockerfile for a simple Deno app:

FROM denoland/deno:alpine-1.35.3
WORKDIR /app
COPY . .
RUN deno cache main.ts
CMD ["run", "--allow-net", "main.ts"]

The main.ts file contains:

console.log("Hello from Deno in Docker!");

What will you see in the container logs after running docker run?

Deno

FROM denoland/deno:alpine-1.35.3
WORKDIR /app
COPY . .
RUN deno cache main.ts
CMD ["run", "--allow-net", "main.ts"]

// main.ts
console.log("Hello from Deno in Docker!");

A Hello from Deno in Docker!

B Error: Permission denied for network access

C No output, container exits silently

D SyntaxError: Unexpected token

💡 Hint

Think about what console.log does and the permissions given.

The --allow-net flag allows network access but is not required for console.log. The app prints the message and exits normally.

📝 Syntax

intermediate

Which Dockerfile command correctly caches dependencies for a Deno app?

You want to cache dependencies to speed up builds. Which RUN command is correct?

A RUN deno run main.ts

B RUN deno cache main.ts

C RUN deno install main.ts

D RUN deno compile main.ts

💡 Hint

Think about which command downloads and caches dependencies without running the app.

deno cache downloads and caches dependencies without executing the script, which helps speed up subsequent builds.

🔧 Debug

advanced

Why does this Deno Docker container fail to start?

Given this Dockerfile snippet:

FROM denoland/deno:alpine-1.35.3
WORKDIR /app
COPY . .
CMD ["run", "main.ts"]

The container fails with a permission error. What is the cause?

A The base image does not support Deno

B The WORKDIR is not set correctly

C The COPY command did not copy main.ts

D Missing permission flags like --allow-net or --allow-read

💡 Hint

Deno requires explicit permission flags to access resources.

By default, Deno denies all permissions. Without flags like --allow-net or --allow-read, the app cannot run if it needs those permissions.

❓ lifecycle

advanced

What happens if you omit the RUN deno cache step in your Dockerfile?

Consider this Dockerfile without caching:

FROM denoland/deno:alpine-1.35.3
WORKDIR /app
COPY . .
CMD ["run", "--allow-net", "main.ts"]

What is the impact on the build and container startup?

A Builds are slower because dependencies are downloaded every time

B The container will fail to start due to missing cache

C The container will start faster because caching is skipped

D The app will run without network permissions

💡 Hint

Think about what caching does during build time.

Without caching, dependencies are fetched on every build, slowing down the process. The container still starts fine but build time increases.

🧠 Conceptual

expert

Which Dockerfile setup best follows best practices for deploying a Deno app securely and efficiently?

Choose the Dockerfile that minimizes image size, caches dependencies, and limits permissions at runtime.

A

FROM denoland/deno:alpine-1.35.3
WORKDIR /app
COPY . .
CMD ["run", "main.ts"]

B

FROM denoland/deno:alpine-1.35.3
WORKDIR /app
COPY . .
RUN deno cache main.ts
CMD ["run", "--allow-net", "main.ts"]

C

FROM denoland/deno:alpine-1.35.3
WORKDIR /app
COPY . .
RUN deno cache main.ts
RUN deno compile --allow-net main.ts
CMD ["./main"]

D

FROM denoland/deno:latest
WORKDIR /app
COPY . .
RUN deno cache main.ts
CMD ["run", "--allow-all", "main.ts"]

💡 Hint

Consider image size, caching, and permission scope.

Option C caches dependencies, compiles the app to a binary (smaller image, faster startup), and runs the binary with minimal permissions. This is best practice.

Practice

1. What is the main purpose of using Docker for deploying a Deno application?

easy

A. To replace the Deno runtime

B. To write Deno code faster

C. To package the app so it runs the same on any machine

D. To debug Deno code inside the browser

Solution

1. Step 1: Understand Docker's role

   Docker packages apps with all dependencies so they run consistently anywhere.

2. Step 2: Relate to Deno deployment

   Using Docker for Deno ensures the app runs the same on any machine without setup issues.

3. Final Answer:

   To package the app so it runs the same on any machine -> Option C

4. Quick Check:

   Docker packages apps = To package the app so it runs the same on any machine [OK]

Hint: Docker ensures consistent app environment everywhere [OK]

Common Mistakes:

• Thinking Docker speeds up coding
• Confusing Docker with Deno runtime
• Assuming Docker is for debugging only

2. Which Dockerfile instruction correctly sets the command to run a Deno script named app.ts with all permissions?

easy

A. CMD ["deno", "run", "--allow-all", "app.ts"]

B. RUN deno run --allow-all app.ts

C. ENTRYPOINT deno app.ts

D. CMD deno start app.ts

Solution

1. Step 1: Identify correct Dockerfile command syntax

   CMD with JSON array syntax is preferred for commands with arguments.

2. Step 2: Match Deno run command with permissions

   "deno run --allow-all app.ts" runs the script with all permissions; CMD array syntax is correct.

3. Final Answer:

   CMD ["deno", "run", "--allow-all", "app.ts"] -> Option A

4. Quick Check:

   Use CMD with JSON array for run command [OK]

Hint: Use CMD with JSON array for Deno run commands [OK]

Common Mistakes:

• Using RUN instead of CMD for runtime command
• Omitting --allow-all permission flag
• Using ENTRYPOINT without arguments array

3. Given this Dockerfile snippet:

FROM denoland/deno:latest
WORKDIR /app
COPY . .
RUN deno cache app.ts
CMD ["deno", "run", "--allow-net", "app.ts"]

What happens when you build and run this container?

medium

A. The app runs with network access allowed

B. The app runs but without network access

C. The container build fails due to missing permissions

D. The app runs but caching is skipped

Solution

1. Step 1: Analyze Dockerfile commands

   The Dockerfile caches dependencies with "deno cache app.ts" and runs the app with "--allow-net" permission.

2. Step 2: Understand runtime behavior

   CMD runs the app allowing network access, so the app can use network features.

3. Final Answer:

   The app runs with network access allowed -> Option A

4. Quick Check:

   --allow-net enables network access = The app runs with network access allowed [OK]

Hint: Check permission flags in CMD to know app access [OK]

Common Mistakes:

• Confusing cache step with runtime permissions
• Assuming build fails without --allow-all
• Ignoring the effect of --allow-net flag

4. You wrote this Dockerfile:

FROM denoland/deno:latest
WORKDIR /app
COPY . .
CMD ["deno", "run", "app.ts"]

But when running the container, the app crashes with permission errors. What is the fix?

medium

A. Remove COPY command

B. Change WORKDIR to /usr/src/app

C. Use RUN instead of CMD for deno run

D. Add permission flags like --allow-net to the CMD

Solution

1. Step 1: Identify cause of permission errors

   Deno requires explicit permission flags to access resources like network or file system.

2. Step 2: Fix Dockerfile CMD to include permissions

   Add flags like --allow-net or --allow-read to CMD so app has needed permissions at runtime.

3. Final Answer:

   Add permission flags like --allow-net to the CMD -> Option D

4. Quick Check:

   Permission errors need flags in CMD [OK]

Hint: Add needed --allow-* flags to CMD to fix permission errors [OK]

Common Mistakes:

• Changing WORKDIR without cause
• Removing COPY which copies app files
• Using RUN instead of CMD for runtime command

5. You want to optimize your Deno Docker image by caching dependencies to speed up builds. Which Dockerfile sequence achieves this best?

hard

A. COPY . .
RUN deno cache app.ts
CMD ["deno", "run", "--allow-all", "app.ts"]

B. COPY deps.ts ./
RUN deno cache deps.ts
COPY . .
CMD ["deno", "run", "--allow-all", "app.ts"]

C. RUN deno cache app.ts
COPY . .
CMD ["deno", "run", "app.ts"]

D. COPY app.ts ./
CMD ["deno", "run", "app.ts"]

Solution

1. Step 1: Understand Docker layer caching

   Docker caches layers; caching dependencies separately avoids re-downloading on code changes.

2. Step 2: Analyze COPY deps.ts ./ RUN deno cache deps.ts COPY . . CMD ["deno", "run", "--allow-all", "app.ts"]

   Copying only deps.ts and caching it first means dependencies are cached unless deps.ts changes, then copying rest avoids rebuilding cache.

3. Step 3: Compare other options

   Options A and C copy all files before caching, so cache invalidates on any file change; D lacks caching step.

4. Final Answer:

   COPY deps.ts ./ RUN deno cache deps.ts COPY . . CMD ["deno", "run", "--allow-all", "app.ts"] -> Option B

5. Quick Check:

   Cache deps separately for faster rebuilds [OK]

Hint: Cache dependencies before copying app code to speed builds [OK]

Common Mistakes:

• Copying all files before caching dependencies
• Skipping deno cache step
• Not using permission flags in CMD