Service Organization Control (SOC) reports are audit reports that provide information about the internal controls and processes of a service organization, such as a cloud provider, a data center, or a payroll service.
There are three types of SOC reports: SOC 1, SOC 2, and SOC 3. SOC 1 reports focus on the controls that affect the financial reporting of the user entities (the clients of the service organization). SOC 2 reports focus on the controls that affect the security, availability, confidentiality, and privacy of the user entities' data and systems, as well as the processing integrity of the service organization. SOC 3 reports are similar to SOC 2 reports, but they are less detailed and more accessible to the general public. Each SOC report can be either Type 1 or Type 2. Type 1 reports describe the design and implementation of the controls at a specific point in time. Type 2 reports describe the operating effectiveness of the controls over a period of time, usually six to twelve months. When conducting a third-party risk assessment of a new supplier, the best report to review to confirm the operating effectiveness of the security, availability, confidentiality, and privacy trust principles is the SOC 2, Type 2 report. This report provides assurance that the service organization has implemented and maintained the controls that are relevant to the protection of the user entities' data and systems, and that the controls have been tested and verified by an independent auditor. International Organization for Standardization (ISO) 27001 and ISO 27002 are not audit reports, but rather standards for information security management systems (ISMS). ISO 27001 specifies the requirements for establishing, implementing, maintaining, and improving an ISMS. ISO 27002 provides guidelines and best practices for implementing the controls of the ISMS. While these standards can be used as a reference for evaluating the security posture of a service organization, they do not provide the same level of assurance and evidence as a SOC 2, Type 2 report.
References: CISSP All-in-One Exam Guide, Eighth Edition, Chapter 1: Security and Risk Management, p.
66-67. Official (ISC)2 CISSP CBK Reference, Fifth Edition, Domain 1: Security and Risk Management, p.
103-104.

In link encryption, each entity has keys in common with its two neighboring nodes in the transmission chain.
Thus, a node receives the encrypted message from its predecessor, decrypts it, and then re-encrypts it with a new key, common to the successor node. Obviously, this mode does not provide protection if anyone of the nodes along the transmission path is compromised.
Encryption can be performed at different communication levels, each with different types of protection and implications. Two general modes of encryption implementation are link encryption and end-to-end encryption.
Link encryption encrypts all the data along a specific communication path, as in a satellite link, T3
line, or telephone circuit. Not only is the user information encrypted, but the header, trailers,
addresses, and routing data that are part of the packets are also encrypted. The only traffic not
encrypted in this technology is the data link control messaging information, which includes
instructions and parameters that the different link devices use to synchronize communication
methods. Link encryption provides protection against packet sniffers and eavesdroppers.
In end-to-end encryption, the headers, addresses, routing, and trailer information are not
encrypted, enabling attackers to learn more about a captured packet and where it is headed.
Reference(s) used for this question:
Harris, Shon (2012-10-25). CISSP All-in-One Exam Guide, 6th Edition (pp. 845-846). McGraw-Hill.
And:
KRUTZ, Ronald L. & VINES, Russel D., The CISSP Prep Guide: Mastering the Ten Domains of
Computer Security, John Wiley & Sons, 2001, Chapter 4: Cryptography (page 132).

Common Criteria 15408 generally outlines assurance and functional requirements through a security evaluation process concept of Protection Profile (PP), Target of Evaluation (TOE), and Security Target (ST) for Evaluated Assurance Levels (EALs) to certify a product or system.
This lists the correct sequential order of these applied concepts to formally conducts tests that evaluate a product or system for the certification for federal global information systems. Common Criteria evaluations are performed on computer security products and systems. There are many terms related to Common Criteria and you must be familiar with them.
Target Of Evaluation (TOE) - the product or system that is the subject of the evaluation. The evaluation serves to validate claims made about the target. To be of practical use, the evaluation must verify the target's security features. This is done through the following: Protection Profile (PP) - a document, typically created by a user or user community, which identifies security requirements for a class of security devices (for example, smart cards used to provide digital signatures, or network firewalls) relevant to that user for a particular purpose. Product vendors can choose to implement products that comply with one or more PPs, and have their products evaluated against those PPs. In such a case, a PP may serve as a template for the product's ST (Security Target, as defined below), or the authors of the ST will at least ensure that all requirements in relevant PPs also appear in the target's ST document. Customers looking for particular types of products can focus on those certified against the PP that meets their requirements.
Security Target (ST) - the document that identifies the security properties of the target of evaluation. It is what the vendor claim the product can do. It may refer to one or more PPs. The TOE is evaluated against the SFRs (see below) established in its ST, no more and no less. This allows vendors to tailor the evaluation to accurately match the intended capabilities of their product. This means that a network firewall does not have to meet the same functional requirements as a database management system, and that different firewalls may in fact be evaluated against completely different lists of requirements. The ST is usually published so that potential customers may determine the specific security features that have been certified by the evaluation The evaluation process also tries to establish the level of confidence that may be placed in the product's security features through quality assurance processes: Security Assurance Requirements (SARs) - descriptions of the measures taken during development and evaluation of the product to assure compliance with the claimed security functionality. For example, an evaluation may require that all source code is kept in a change management system, or that full functional testing is performed. The Common Criteria provides a catalogue of these, and the requirements may vary from one evaluation to the next. The requirements for particular targets or types of products are documented in the ST and PP, respectively.
Evaluation Assurance Level (EAL) - the numerical rating describing the depth and rigor of an evaluation. Each EAL corresponds to a package of security assurance requirements (SARs, see above) which covers the complete development of a product, with a given level of strictness. Common Criteria lists seven levels, with EAL 1 being the most basic (and therefore cheapest to implement and evaluate) and EAL 7 being the most stringent (and most expensive). Normally, an ST or PP author will not select assurance requirements individually but choose one of these packages, possibly 'augmenting' requirements in a few areas with requirements from a higher level. Higher EALs do not necessarily imply "better security", they only mean that the claimed security assurance of the TOE has been more extensively verified.
Security Functional Requirements (SFRs) - specify individual security functions which may be provided by a product. The Common Criteria presents a standard catalogue of such functions. For example, a SFR may state how a user acting a particular role might be authenticated. The list of SFRs can vary from one evaluation to the next, even if two targets are the same type of product. Although Common Criteria does not prescribe any SFRs to be included in an ST, it identifies dependencies where the correct operation of one function (such as the ability to limit access according to roles) is dependent on another (such as the ability to identify individual roles).
So far, most PPs and most evaluated STs/certified products have been for IT components (e.g., firewalls, operating systems, smart cards). Common Criteria certification is sometimes specified for IT procurement. Other standards containing, e.g., interoperation, system management, user training, supplement CC and other product standards. Examples include the ISO/IEC 17799 (Or more properly BS 7799-1, which is now ISO/IEC 27002) or the German IT-Grundschutzhandbuch.
Details of cryptographic implementation within the TOE are outside the scope of the CC. Instead, national standards, like FIPS 140-2 give the specifications for cryptographic modules, and various standards specify the cryptographic algorithms in use.
More recently, PP authors are including cryptographic requirements for CC evaluations that would typically be covered by FIPS 140-2 evaluations, broadening the bounds of the CC through scheme-specific interpretations.
The following answers are incorrect:
1.Protection Profile, Security Target, Target of Evaluation
2.SFR, Protection Profile, Security Target, Target of Evaluation
4. SFR, Security Target, Protection Profile, Target of Evaluation
The following reference(s) were/was used to create this question: ISO/IEC 15408 Common Criteria for IT Security Evaluations and http://en.wikipedia.org/wiki/Common_Criteria