I have listed down the Basic questions which you must know, before landing into any of the CQ5/ AEM related interview. They are a big MUST and you should be definitely aware of them. Interviewers might ask these questions directly, or they might twist them in some or other manner.

The most beautiful approach to tackle a difficult question is start explaining the Basics of that topic and then jump into the question been asked. This way you will give an impression that , at least you are aware of the basics and can struggle when the problem becomes complex. On flip side , if you know the answer to a question correctly, just tell the answer briefly without the basics description. Saves time and shows that you are intelligent enough to deal with the difficult questions.

Q1.) What is RESTful

REST (REpresentational State Transfer) is an architectural style, and an approach to communications that is often used in the development of Web services. The use of REST is often preferred over the more heavyweight SOAP(Simple Object Access Protocol) style because REST does not leverage as much bandwidth, which makes it a better fit for use over the Internet. The SOAP approach requires writing or using a provided server program (to serve data) and a client program (to request data).

REST’S decoupled architecture, and lighter weight communications between producer and consumer, make REST a popular building style for cloud-based APIs

The REST architectural style describes six architectural constraints:

1. Uniform Interface 
   The uniform interface constraint defines the interface between clients and servers. It simplifies and decouples the architecture, which enables each part to evolve independently. The four guiding principles of the uniform interface are:

   Resource-Based

   Individual resources are identified in requests using URIs as resource identifiers. The resources themselves are conceptually separate from the representations that are returned to the client. For example, the server does not send its database, but rather, some HTML, XML or JSON that represents some database records expressed, for instance, in Finnish and encoded in UTF-8, depending on the details of the request and the server implementation.

   Manipulation of Resources Through Representations

   When a client holds a representation of a resource, including any metadata attached, it has enough information to modify or delete the resource on the server, provided it has permission to do so.

   Self-descriptive Messages

   Each message includes enough information to describe how to process the message. For example, which parser to invoke may be specified by an Internet media type (previously known as a MIME type). Responses also explicitly indicate their cache-ability.

   Hypermedia as the Engine of Application State (HATEOAS)

   Clients deliver state via body contents, query-string parameters, request headers and the requested URI (the resource name). Services deliver state to clients via body content, response codes, and response headers. This is technically referred-to as hypermedia (or hyperlinks within hypertext).

   Aside from the description above, HATEOS also means that, where necessary, links are contained in the returned body (or headers) to supply the URI for retrieval of the object itself or related objects. We’ll talk about this in more detail later.

   The uniform interface that any REST services must provide is fundamental to its design

2. Stateless

   As REST is an acronym for REpresentational State Transfer, statelessness is key. Essentially, what this means is that the necessary state to handle the request is contained within the request itself, whether as part of the URI, query-string parameters, body, or headers. The URI uniquely identifies the resource and the body contains the state (or state change) of that resource. Then after the server does it’s processing, the appropriate state, or the piece(s) of state that matter, are communicated back to the client via headers, status and response body.Most of us who have been in the industry for a while are accustomed to programming within a container which provides us with the concept of “session” which maintains state across multiple HTTP requests. In REST, the client must include all information for the server to fulfill the request, resending state as necessary if that state must span multiple requests. Statelessness enables greater scalability since the server does not have to maintain, update or communicate that session state. Additionally, load balancers don’t have to worry about session affinity for stateless systems.

   So what’s the difference between state and a resource? State, or application state, is that which the server cares about to fulfill a request—data necessary for the current session or request. A resource, or resource state, is the data that defines the resource representation—the data stored in the database, for instance. Consider application state to be data that could vary by client, and per request. Resource state, on the other hand, is constant across every client who requests it.

   Ever had back-button issues with a web application where it went AWOL at a certain point because it expected you to do things in a certain order? That’s because it violated the statelessness principle. There are cases that don’t honor the statelessness principle, such as three-legged OAuth, API call rate limiting, etc. However, make every effort to ensure that application state doesn’t span multiple requests of your service(s).

3. Cacheable
   As on the World Wide Web, clients can cache responses. Responses must therefore, implicitly or explicitly, define themselves as cacheable, or not, to prevent clients reusing stale or inappropriate data in response to further requests. Well-managed caching partially or completely eliminates some client–server interactions, further improving scalability and performance.
4. Client-Server
    The uniform interface separates clients from servers. This separation of concerns means that, for example, clients are not concerned with data storage, which remains internal to each server, so that the portability of client code is improved. Servers are not concerned with the user interface or user state, so that servers can be simpler and more scalable. Servers and clients may also be replaced and developed independently, as long as the interface is not altered.
5. Layered System
   A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way. Intermediary servers may improve system scalability by enabling load-balancing and by providing shared caches. Layers may also enforce security policies.
6. Code on Demand (optional) Servers are able to temporarily extend or customize the functionality of a client by transferring logic to it that it can execute. Examples of this may include compiled components such as Java applets and client-side scripts such as JavaScript.Complying with these constraints, and thus conforming to the REST architectural style, will enable any kind of distributed hypermedia system to have desirable emergent properties, such as performance, scalability, simplicity, modifiability, visibility, portability and reliability.NOTE: The only optional constraint of REST architecture is code on demand. If a service violates any other constraint, it cannot strictly be referred to as RESTful.

Advantages over SOAP:

REST provides the following advantages, specifically advantages over leveraging SOAP:

• RESTful Web services are easy to leverage by most tools, including those that are free and inexpensive. REST is becoming the dial tone for systems interaction, including the use of RESTful Web services, which are, for the most part, the way cloud providers externalize their cloud services.
• SOAP services are much harder to scale than RESTful services. Thus, REST is often chosen as the architecture for services that are exposed via the Internet
• The learning curve seems to be reduced. Developers are able to make use of REST from within applications faster than they can with SOAP. This saves time, which saves money.
• REST uses a smaller message format than SOAP. SOAP uses XML for all messages, which makes the message size much larger, and thus less efficient. This means REST provides better performance, as well as lowers costs over time. Moreover, there is no intensive processing required, thus it’s much faster than traditional SOAP.
• REST is designed for use over the Open Internet/Web. This is a better choice for Web scale applications, and certainly for cloud-based platforms.

Q2.) What is Sling

Apache Sling is a web framework that uses a Java Content Repository, such as Apache Jackrabbit, to store and manage content.

Sling applications use either scripts or Java servlets, selected based on simple name conventions, to process HTTP requests in a RESTful way.

The embedded Apache Felix OSGi framework and console provide a dynamic runtime environment, where code and content bundles can be loaded, unloaded and reconfigured at runtime.

As the first web framework dedicated to JSR-170 Java Content Repositories, Sling makes it very simple to implement simple applications, while providing an enterprise-level framework for more complex applications.

The following is a short list of high-lights of Sling:

• OSGi — The Sling application is built as a series of OSGi bundles and makes heavy use of a number of OSGi core and compendium services.
• Sling API — To implement content based Web applications with Sling, an API has been defined, this extends the Servlet API and provides more functionality to work on the content.
• Request Processing — Sling takes a unique approach to handling requests in that a request URL is first resolved to a resource, then based on the resource (and only the resource) it selects the actual servlet or script to handle the request.
• Resources — The central mantra of Sling is the Resource, which represents the resource addressed by any request URL. It is the resource that is first resolved when handling a request. Based on the resource, a first servlet or script is then accessed to actually handle the request.
• Servlets and Scripts — Servlets and Scripts are handled uniformly in that they are represented as resources themselves and are accessible by a resource path.
• Launchpad — Sling uses a very thin launcher to integrate with an existing servlet container, launching Sling as a Web application or providing a main class to represent a standalone Java application.

http://sling.apache.org/documentation/the-sling-engine/architecture.html

Q3.) Describe Author  & Publisher environment

A CQ WCM installation usually comprises of multiple instances, used for different purposes. Content, including code and other resources held in the repository, can be replicated (copied from destination to source) using a HTTP, or HTTPS, connection.

A production environment often consists of two different types of instances:

author
This is the environment where you, and your colleagues, will input your content and administrate the system.

publish
This environment holds the content you have made available to visitors to your website; be it public, or within your intranet.

Defining a CQ instance (or environment) as “publish” or “author” depends primarily on where in the overall system structure the environment is located and what its tasks are.

The following diagram gives an overview of typical configurations possible for the various CQ WCM environment. It shows how content flows from the authoring environments until it is available to be accessed by visitors to your website. It also highlights the fact that to increase performance and availability it is common to combine several authoring and publishing environments to service a website.

Author
Author is usually located behind the internal firewall as it is the environment where you and your colleagues will:

• administrate the entire system
• input your content
• configure the layout and design of your content
• activate your content to the publish environment

The author environment of CQ WCM is accessed using the siteadmin. Access to the content and functionality is controlled by authorization permissions assigned to your user account.

Replication agents in the author environment(s) are used to publish (activate) content and functionality from the author to the publish instance:

• content to be published is packaged and placed in the replication queue (in the author environment)
• the content is transported to the publish environment
• the content is received and published

Publish
This holds the content which you have made available to visitors to your website and is usually located in the Demilitarized Zone (DMZ).

The content is dynamic, real-time and can be personalized for each individual user.

Reverse replication is necessary from the publish environment, to return user input from a publish instance to the author, and then to any other publish, instance(s). A reverse replication agent in the publish environment places the input into an outbox, which is matched with replication listeners in the author environment. The listeners poll the outboxes to collect any input made and then distribute it as necessary. This ensures that any traffic from the publish to the author environment is strictly controlled. Reverse replication is of particular significance for CQ Social Collaboration.

Static Web Server
For performance optimization it is possible to convert your dynamically published content (excluding any personalized parts) to static HTML, serviced by a static web server. Static web servers are very simple, but fast. Examples include Apache, and IIS.

The Dispatcher can then be used in conjunction with the web server to realize an environment that is both fast and dynamic and with moderate hardware requirements.

Dispatcher
The Dispatcher helps realize an environment that is both fast and dynamic. It works as part of a static HTML server, such as Apache, with the aim of:

storing (or “caching”) as much of the site content as is possible, in the form of a static website.

accessing the layout engine to retrieve dynamic content as and when necessary, but as little as possible.

Which means that:

• static content is handled with exactly the same speed and ease as on a static web server; additionally you can use the administration and security tools available for your static web server(s).
• dynamic content is generated as needed, without slowing the system down any more than absolutely necessary.

The Dispatcher contains mechanisms to generate, and update, static HTML based on the content of the dynamic site. You can specify in detail which documents are stored as static files and which are always generated dynamically.