Evaluate the technical feasibility of an application design concept.

• Evaluate the proof of concept.
• Recommend the best technologies for the features and goals of the application.
• Weigh implementation considerations.
• Investigate existing solutions for similar business problems.

Create a proof-of-concept prototype.

• Evaluate the risks associated with the proposed technology or implementation.
• Validate that the proposed technology can be used in the application.
• Demonstrate to stakeholders that the proposed solution will address their needs.

Evaluate the technical specifications for an application to ensure that the business requirements are met.

• Translate the functional specification into developer terminology, such as pseudo code and UML diagrams.
• Suggest component type and layer.

Evaluate the logical design of an application.

• Evaluate the logical design for performance.
• Evaluate the logical design for maintainability.
• Evaluate the logical design for extensibility.
• Evaluate the logical design for scalability.
• Evaluate the logical design for security.
• Evaluate the logical design against use cases.
• Evaluate the logical design for recoverability.
• Evaluate the logical design for data integrity.

Evaluate the physical design of an application. Considerations include the design of the project structure, the number of files, the number of assemblies, and the location of these resources on the server.

• Evaluate the physical design for performance.
• Evaluate the physical design for maintainability.
• Evaluate how the physical location of files affects the extensibility of the application.
• Evaluate the physical design for scalability.
• Evaluate the physical design for security.
• Evaluate the physical design for recoverability.
• Evaluate the physical design for data integrity.

Choose an appropriate layout for the visual interface.

• Decide the content flow within the application.
• Evaluate user navigation needs.
• Identify the goal of the UI.
• Ensure the congruency and consistency of the user experience throughout the application.
• Choose techniques to control the layout.

Evaluate a strategy for implementing a common layout throughout the UI.

• Suggest an applicable UI standard based on the application specification. Considerations include MDI, SDI, control grouping, and so on.

Choose an appropriate control based on design specifications.

• Evaluate the type of data that must be captured or displayed.
• Evaluate available controls. Considerations include standard .NET Framework controls and custom, internally developed, and third-party controls.
• Evaluate the manner in which available controls are implemented in previous and ongoing projects or applications.
• Evaluate the user demographic.
• Evaluate the user environment.

Choose an appropriate data validation method at the UI layer.

• Choose a validation method based on the data type provided.
• Decide how to report the feedback. Considerations include callbacks, exceptions, and writing to an event log.
• Identify the source of invalid data.
• Identify the cause of an invalid entry.
• Evaluate whether invalid data can be prevented.
• Evaluate whether an exception must be thrown.
• Evaluate whether an exception must be logged.
• Evaluate whether visual feedback, such as a message box or color, is required.

Choose appropriate user assistance and application status feedback techniques.

• Design a user assistance mechanism.
• Choose an appropriate application status feedback technique based on available control types.
• Choose an appropriate application status feedback technique to support accessibility.
• Design an application status feedback mechanism.

Establish the required characteristics of a component.

• Decide when to create a single component or multiple components.
• Decide in which tier of the application a component should be located.
• Decide which type of object to build.

Create the high-level design of a component.

• Establish the life cycle of a component.
• Decide whether to use established design patterns for the component.
• Decide whether to create a prototype for the component.
• Document the design of a component by using pseudo code, class diagrams, sequence diagrams, activity diagrams, and state diagrams.
• Evaluate tradeoff decisions. Considerations include security vs. performance, performance vs. maintainability, and so on.

Develop the public API of a component.

• Decide the types of clients that can consume a component.
• Establish the required component interfaces.
• Decide whether to require constructor input.

Develop the features of a component.

• Decide whether existing functionality can be implemented or inherited.
• Decide how to handle unmanaged and managed resources.
• Decide which extensibility features are required.
• Decide whether a component must be multithreaded.
• Decide which functions to implement in the base class, abstract class, or sealed class.

Develop an exception handling mechanism.

• Decide when it is appropriate to raise an exception.
• Decide how a component will handle exceptions. Considerations include catching and throwing a new exception; catching, wrapping, and throwing the wrapped exception; catching and terminating, and so on.

Develop the data access and data handling features of a component.

• Analyze data relationships.
• Analyze the data handling requirements of a component.

Develop a component to include profiling requirements.

• Identify potential issues, such as resource leaks and performance gaps, by profiling a component.
• Decide when to stop profiling on a component.
• Decide whether to redesign a component after analyzing the profiling results.

Consume a reusable software component.

• Identify a reusable software component from available components to meet the requirements.
• Identify whether the reusable software component needs to be extended.
• Identify whether the reusable software component needs to be wrapped.
• Identify whether any existing functionality needs to be hidden.
• Test the identified component based on the requirements.

Choose an appropriate exception handling mechanism.

• Evaluate the current exception handling mechanism.
• Design a new exception handling technique.

Choose an appropriate implementation approach for the application design logic.

• Choose an appropriate data storage mechanism.
• Choose an appropriate data flow structure.
• Choose an appropriate decision flow structure.

Choose an appropriate event logging method for the application.

• Decide whether to log data. Considerations include policies, security, requirements, and debugging.
• Choose a storage mechanism for logged events. For example, database, flat file, event log, or XML file.
• Choose a systemwide event logging method. For example, centralized logging, distributed logging, and so on.
• Decide logging levels based upon severity and priority.

Evaluate the application configuration architecture.

• Decide which configuration attributes to store.
• Choose the physical storage location for the configuration attributes.
• Decide in which format to store the configuration attributes.

Perform a code review.

Evaluate the testing strategy.

• Create the unit testing strategy.
• Evaluate the integration testing strategy.
• Evaluate the stress testing strategy.
• Evaluate the performance testing strategy.
• Evaluate the test environment specification.

Design a unit test.

• Describe the testing scenarios.
• Decide coverage requirements.
• Evaluate when to use boundary condition testing.
• Decide the type of assertion tests to conduct.

Perform integration testing.

• Determine if the component works as intended in the target environment.
• Identify component interactions and dependencies.
• Verify results.

Resolve a bug.

• Investigate a reported bug.
• Reproduce a bug.
• Evaluate the impact of the bug and the associated cost and timeline for fixing the bug.
• Fix a bug.

Evaluate the performance of an application based on the performance analysis strategy.

• Identify performance spikes.
• Analyze performance trends.
• Track logon times.

Analyze the data received when monitoring an application.

• Monitor and analyze resource usage.
• Monitor and analyze security aspects.
• Track bugs that result from customer activity.

Evaluate the deployment plan.

• Identify component-level deployment dependencies.
• Identify scripting requirements for deployment. Considerations include database scripting.
• Evaluate available deployment methods.

Validate the production configuration environment.

• Verify networking settings
• Verify the deployment environment.
• Verify the deployment environment.

This is nice.  If you can do all this, you should be able to call yourself a developer.  There's no amount of studying that can help you.  These bullet items are seeing if you can solve a problem using Microsoft technlogies and juggle different needs of your customers.  It will be interesting to see how they can test for this using a series of multiple choice questions.

In order to cover all of this material sufficiently, I'd have to write a book.  Also, I'm about to take the test in 2 hours, so I need to start reviewing the preivous material.  After I take the test, I suspect I'll no longer be able to publicly comment on this test.