Main configuration file (nginx.conf) - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

What is the output of this nginx configuration test command?

You have an nginx configuration file with a syntax error. You run the command nginx -t to test the configuration. What output will you see?

Nginx

nginx: [emerg] unknown directive "serve_static" in /etc/nginx/nginx.conf:12
nginx: configuration file /etc/nginx/nginx.conf test failed

A nginx: configuration file /etc/nginx/nginx.conf syntax is ok\nnginx: configuration file /etc/nginx/nginx.conf test is successful

B nginx: [emerg] unknown directive "serve_static" in /etc/nginx/nginx.conf:12\nnginx: configuration file /etc/nginx/nginx.conf test failed

C nginx: [warn] deprecated directive used in /etc/nginx/nginx.conf:12\nnginx: configuration file /etc/nginx/nginx.conf test failed

D nginx: error: could not open configuration file /etc/nginx/nginx.conf

💡 Hint

Look for the exact error message when nginx finds an unknown directive.

When nginx encounters an unknown directive in the configuration file, it reports an emergency level error with the line number and states that the configuration test failed.

🧠 Conceptual

intermediate

Which directive in nginx.conf sets the maximum number of worker processes?

In the main nginx configuration file, which directive controls how many worker processes nginx will start to handle requests?

A worker_processes

B worker_connections

C max_clients

D process_limit

💡 Hint

Think about the directive that defines how many separate workers run.

The worker_processes directive sets the number of worker processes nginx will spawn. Each worker handles connections.

❓ Configuration

advanced

Identify the error in this nginx.conf snippet

Look at this snippet from an nginx.conf file. What is the error that will cause nginx to fail to start?

Nginx

http {
    server {
        listen 80;
        server_name example.com;
        location / {
            root /var/www/html;
            index index.html index.htm;
        }
    }
    worker_processes 4;
}

A The directive 'worker_processes' is inside the 'http' block, which is invalid.

B The 'root' directive must be inside the 'server' block, not 'location'.

C The 'listen' directive must be outside the 'server' block.

D The 'index' directive cannot have multiple files listed.

💡 Hint

Check where 'worker_processes' is allowed in nginx.conf.

The 'worker_processes' directive must be in the main context, not inside 'http' or 'server' blocks. Placing it inside 'http' causes a configuration error.

❓ Troubleshoot

advanced

Why does nginx fail to reload with this configuration?

You updated nginx.conf and ran nginx -s reload. The reload failed with this error: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use). What is the most likely cause?

A The firewall is blocking port 80.

B The nginx user does not have permission to bind to port 80.

C The configuration file has a syntax error on the listen directive.

D Another process is already using port 80, so nginx cannot bind to it.

💡 Hint

The error says 'Address already in use'. What does that mean?

The error means some other process is already listening on port 80, so nginx cannot bind to it again. This is often caused by another web server or an existing nginx instance.

🔀 Workflow

expert

Order the steps to safely update nginx.conf and reload nginx without downtime

Put these steps in the correct order to update nginx configuration safely and reload nginx without downtime.

A 4,2,1,3

B 1,4,2,3

C 4,1,2,3

D 2,4,1,3

💡 Hint

Think about protecting the current config before editing and verifying before reloading.

First backup the current config to restore if needed. Then edit the file. Next test syntax to catch errors. Finally reload nginx to apply changes without downtime.

Practice

1. What is the primary purpose of the nginx.conf file in NGINX?

easy

A. To manage user accounts and permissions

B. To store website content like HTML and images

C. To log errors and access information

D. To configure how NGINX handles web requests and server behavior

Solution

1. Step 1: Understand the role of nginx.conf

   The nginx.conf file is the main configuration file that controls how NGINX behaves and processes requests.

2. Step 2: Differentiate from other files

   Files like logs store errors or access info, and website content files hold HTML/images, but nginx.conf sets server rules.

3. Final Answer:

   To configure how NGINX handles web requests and server behavior -> Option D

4. Quick Check:

   Main config file = server behavior [OK]

Hint: Remember: nginx.conf sets server rules, not content or logs [OK]

Common Mistakes:

• Confusing nginx.conf with website files
• Thinking nginx.conf stores logs
• Assuming nginx.conf manages users

2. Which of the following is the correct syntax to include another configuration file inside nginx.conf?

easy

A. include /etc/nginx/conf.d/*.conf;

B. import /etc/nginx/conf.d/*.conf;

C. load /etc/nginx/conf.d/*.conf;

D. attach /etc/nginx/conf.d/*.conf;

Solution

1. Step 1: Recall the directive for including files

   NGINX uses the include directive to add other config files inside nginx.conf.

2. Step 2: Check syntax correctness

   The correct syntax is include path; with a semicolon. Other words like import, load, attach are invalid in NGINX.

3. Final Answer:

   include /etc/nginx/conf.d/*.conf; -> Option A

4. Quick Check:

   Include directive = include [OK]

Hint: Use 'include' to add files, ends with semicolon [OK]

Common Mistakes:

• Using 'import' or 'load' instead of 'include'
• Forgetting the semicolon at the end
• Wrong directive names

3. Given this snippet from nginx.conf:

http {
    server {
        listen 80;
        server_name example.com;
        location / {
            root /var/www/html;
        }
    }
}

What will happen when a user visits http://example.com/?

medium

A. NGINX serves files from /var/www/html directory

B. NGINX returns a 404 error because root is missing a semicolon

C. NGINX redirects to HTTPS automatically

D. NGINX blocks the request due to missing listen directive

Solution

1. Step 1: Analyze the server block

   The server listens on port 80 and responds to requests for example.com. The location / block sets the root directory to /var/www/html.

2. Step 2: Understand the effect of root directive

   When a user visits the site root, NGINX serves files from /var/www/html. The semicolon is present, so syntax is correct.

3. Final Answer:

   NGINX serves files from /var/www/html directory -> Option A

4. Quick Check:

   Root directive sets file location = serve files [OK]

Hint: Root directive points to file folder served [OK]

Common Mistakes:

• Assuming missing semicolon causes error (it's present)
• Thinking HTTPS redirect happens automatically
• Ignoring listen directive presence

4. Identify the error in this nginx.conf snippet:

http {
    server {
        listen 80
        server_name mysite.com;
        location / {
            root /usr/share/nginx/html;
        }
    }
}

medium

A. root directive path is incorrect

B. server_name directive is invalid

C. Missing semicolon after listen 80

D. location block cannot be inside server block

Solution

1. Step 1: Check syntax of directives

   Each directive must end with a semicolon. The line listen 80 is missing a semicolon.

2. Step 2: Validate other directives

   The server_name and root directives are correctly written. The location block is correctly nested inside server.

3. Final Answer:

   Missing semicolon after listen 80 -> Option C

4. Quick Check:

   Every directive ends with semicolon [OK]

Hint: Check every directive ends with semicolon [OK]

Common Mistakes:

• Ignoring missing semicolon errors
• Thinking server_name syntax is wrong
• Misunderstanding block nesting rules

5. You want to serve two websites on the same NGINX server using nginx.conf. Which configuration correctly sets up two server blocks for site1.com and site2.com on port 80?

hard

A. http {
server {
listen 80;
server_name site1.com site2.com;
root /var/www/site1;
}
}

B. http {
server {
listen 80;
server_name site1.com;
root /var/www/site1;
}
server {
listen 80;
server_name site2.com;
root /var/www/site2;
}
}

C. http {
server {
listen 80;
server_name site1.com;
root /var/www/site1;
}
location /site2 {
root /var/www/site2;
}
}

D. http {
server {
listen 80;
server_name site1.com;
root /var/www/site1;
}
server {
listen 8080;
server_name site2.com;
root /var/www/site2;
}
}

Solution

1. Step 1: Understand multiple server blocks

   To serve two sites on the same port, create two separate server blocks each with its own server_name and root.

2. Step 2: Evaluate each option

   http {
       server {
           listen 80;
           server_name site1.com;
           root /var/www/site1;
       }
       server {
           listen 80;
           server_name site2.com;
           root /var/www/site2;
       }
   }

   correctly defines two server blocks both listening on port 80 with different server_name and root.

   http {
       server {
           listen 80;
           server_name site1.com site2.com;
           root /var/www/site1;
       }
   }

   combines names in one block, serving only one root.

   http {
       server {
           listen 80;
           server_name site1.com;
           root /var/www/site1;
       }
       location /site2 {
           root /var/www/site2;
       }
   }

   uses location incorrectly for separate site.

   http {
       server {
           listen 80;
           server_name site1.com;
           root /var/www/site1;
       }
       server {
           listen 8080;
           server_name site2.com;
           root /var/www/site2;
       }
   }

   uses different ports, not both on 80.

3. Final Answer:

   Two server blocks on port 80 with separate server_name and root -> Option B

4. Quick Check:

   Separate server blocks = separate sites [OK]

Hint: Use separate server blocks with unique server_name for each site [OK]

Common Mistakes:

• Combining multiple domains in one server block with one root
• Using location blocks instead of server blocks for separate sites
• Assigning different ports when same port is required