EJB MT solutions of Niit Ques. 126 to 150

EJB MT solutions of Niit Ques. 126 to 150












SNo: 126
Ques: Which of the following is true regarding the Java EE security
Options:
  1, Contains reference to the real security infrastructure.
  2, Cannot use declarative or programmatic authorization controls
  3, Maps the security policy to the target security domain
  4, Does not provide end-to-end security
Answer: 3
Marks: 2

=============================================================

SNo: 127
Ques: Which of the following options can be authenticated by an authentication protocol in a security service, deployed in an enterprise
Options:
  1, Role
  2, Caller
  3, Principal
  4, Resources
Answer: 3
Marks: 2

=============================================================

SNo: 128
Ques: Which of the following statements is correct in reference to the principal identity
Options:
  1, A principal does not represent a user in the native security domain.
  2, A principal is an unauthenticated user in the Java EE security domain.
  3, A principal is identified using a principal name and authenticated using authentication data.
  4, A principal has predefined credential requirements associated with it.
Answer: 3
Marks: 2

=============================================================

SNo: 129
Ques: Which of the following properties of transaction management allows the data store to handle concurrent transactions and, in addition, ensures that the data integrity is maintained
Options:
  1, Isolation
  2, Durability
  3, Atomicity
  4, Consistency
Answer: 1
Marks: 2

=============================================================

SNo: 130
Ques: Which of the following transaction management properties ensures that the individual actions are bundled together and appear as one single unit of work
Options:
  1, Atomicity
  2, Durability
  3, Consistency
  4, Locking
Answer: 1
Marks: 2

=============================================================

SNo: 131
Ques: Which of the following options is correct in reference to the Fetch mode settings
Options:
  1, Fetch mode settings are instructions to the persistence provider.
  2, Fetch mode settings are used when the EntityManager API is invoked.
  3, Fetch mode settings is used to Set the value of the mappedBy attribute to the value of the relationship or property in the owning entity.
  4, Fetch mode settings can cause specific entity instance life-cycle events to flow across relationships.
Answer: 1
Marks: 2

=============================================================

SNo: 132
Ques: Which of the following mode settings can be defined as a hint to the persistence provider to defer the loading of the association target to the time association target is accessed
Options:
  1, EAGER
  2, REFRESH
  3, LAZY
  4, PERSIST
Answer: 3
Marks: 2

=============================================================

SNo: 133
Ques: Which of the following options requires that the columns that correspond to state specific to the subclasses are nullable
Options:
  1, Single table per class hierarchy strategy
  2, Table per class strategy
  3, Joined subclass strategy
  4, strategy attribute of the Inheritance annotation
Answer: 1
Marks: 2

=============================================================

SNo: 134
Ques: Which of the following options is true regarding table per class object/relational mapping strategy
Options:
  1, It provides good support for polymorphic relationships.
  2, It requires a common table to represent the root entity class in the hierarchy.
  3, It requires that one or more join operations be performed to instantiate instances of a subclass.
  4, It provides poor support for polymorphic relationships.
Answer: 4
Marks: 2

=============================================================

SNo: 135
Ques: Which of the following options is true regarding joined subclass object/relational mapping strategy
Options:
  1, It requires a common table to represent the root entity class in the hierarchy.
  2, It does not provide support for polymorphic relationships between entities.
  3, It requires a table for each concrete class in the hierarchy.
  4, It has a column for each unique persistence field in the hierarchy.
Answer: 1
Marks: 2

=============================================================

SNo: 136
Ques: You have been allocated a task to create entity beans for PERSON and PERSON_ASSIGNMENT tables. PERSON table is used to store the person information and PERSON_ASSIGNMENT table is used to store a person's work related information. The cardinality between PERSON and PERSON_ASSIGNMENT table is one-to-many. Apart from cardinality you want that as soon as the PERSON record is removed the corresponding PERSON_ASSIGNMENT record should also be removed. Which of the following options you will use to do so
Options:
  1,@OneToMany(cascade=PERSIST)
  2,@OneToOne(cascade=PERSIST)
  3,@ManyToOne(cascade=PERSIST)
  4,@OneToMany
Answer: 1
Marks: 3

=============================================================

SNo: 137
Ques: You have been allocated a task to create entity beans for EMPLOYEE and EMPLOYEE_ASSIGNMENT tables. EMPLOYEE table is used to store the employee information and EMPLOYEE_ASSIGNMENT table is used to store the employee's work related information. The cardinality between EMPLOYEE and EMPLOYEE_ASSIGNMENT table is one-to-many. You want to create Employee and EmployeeAssignment entity beans in such a way that they will follow the cardinality and the related employee assignments are available in the employee entity and vice-versa. What of the following options you will use for this
Options:
  1,Provide OneToMany annotation in the Employee entity bean and ManyToOne annotation in the Employee_Assignment entity bean.
  2,Provide ManyToOne annotation in the Employee entity bean and OneToMany annotation in the Employee_Assignment entity bean.
  3,Provide OneToMany annotation in the Employee entity.
  4,Provide ManyToOne annotation in the Employee_Assignment entity bean.
Answer: 1
Marks: 3

=============================================================

SNo: 138
Ques: You have been given the task of creating Person, Employee and ContractEmployee entity beans for a Human Resource Management System's site. Employee and ContractEmployee bean inherits the Person bean. Person records get stored to PERSON table, Employee records get stored to EMPLOYEE table and ContractEmployee record get stored to CONTRACT_EMPLOYEE table in the database. EMPLOYEE and CONTRACT_EMPLOYEE tables store only the extra information which is not present in the PERSON table. Which of the following strategy can be used for implementing the inheritance between these entity beans


Options:
  1,Single table per class hierarchy strategy.
  2,Table per class strategy.
  3,Joined subclass strategy.
  4,Inheritance is not possible in these entity beans.
Answer: 3
Marks: 3

=============================================================

SNo: 139
Ques: You have been given the task of creating Person and Employee entity beans for a Human Resource Management System's site. Employee bean class inherits the Person bean class.. Both Person and Employee records get stored to the same table in the database named as PERSON. Which of the following strategy can be used for implementing the inheritance between these entity beans
Options:
  1,Single table per class hierarchy strategy.
  2,Table per class strategy.
  3,Joined subclass strategy.
  4,Inheritance is not possible in these entity beans.
Answer: 1
Marks: 3

=============================================================

SNo: 140
Ques: You have been given the task of upgrading an existing Human Resource Management System's (HRMS) site using Java EE architecture. Legacy system was using concrete class Employee for employee information that extends an abstract class Person. You are creating an Employee entity bean for table EMPLOYEE to store the employee information. Employee bean will be a table-based entity. Most of the code is already present in the old Person class and you do not want to redo the job and still want to use the abstract class Person. Identify whether it is possible for an entity bean to extend an abstract class Give a reason.


Options:
  1,No, this is not possible because an entity bean cannot inherit an abstract class.
  2,Yes, it is possible but the Person class should be defined as a MappedSuperclass so that the Employee bean can extend it.
  3,Yes, it is possible but the Person class should also be created as an entity bean and then only the Employee bean can inherit it.
  4,No, this is not possible because entity beans cannot extend any class. Therefore, the Employee bean too cannot extend Person class.
Answer: 2
Marks: 3

=============================================================

SNo: 141
Ques: Mary is implementing a banking site for which she has created a stateless session bean namely, the AccountBean. The following code snippet displays the partial code of deployment descriptor file:

<security-role-ref>
  <description> Role for creating account. </description>
  <role-name>SYSTEM_ADMINISTRATOR</role-name>
  <role-link>SystemAdministrator</role-link>
</security-role-ref>

<security-role>
  <description>Allows access to createAccount. </description>
  <role-name>SystemAdministrator</role-name>
</security-role>

<method-permission>
  <role-name>SystemAdministrator</role-name>
  <method>
    <ejb-name>AccountBean</ejb-name>
    <method-name>createAccount</method-name>
  </method>
</method-permission>

In reference to the preceding code, which of the following statements are correct
Options:
  1,The code snippet does not enforce any security, instead annotations should be used.
  2,The code snippet is not well-formed and so it will give a run-time exception.
  3,The code snippet enables security such that the caller with role SYSTEM_ADMINISTRATOR can only execute the createAccount method of AccountBean.
  4,The code snippet enables security such that only the caller with role SystemAdministrator can execute the createAccount method of AccountBean.
Answer: 4
Marks: 3

=============================================================

SNo: 142
Ques: You have created a stateless bean namely, the EmployeeBean for a human resource management site. The EmployeeBean uses BMT and has a processPayroll method to process the payroll of the employees. You have a requirement that when the processPayroll method is called from a client's transaction, the method should not commit or rollback the transaction while returning. Is it possible for a stateless session bean to start a transaction and commit or rollback it before the method returns and how
Options:
  1,Yes, SUPPORTS can be used as a transaction attribute type annotation.
  2,Yes, REQUIRED can be used as a transaction attribute type annotation.
  3,Not possible as stateless session bean does not support this type of transaction policy.
  4,Yes, stateless session bean by default support this type of transaction policy.
Answer: 1
Marks: 3

=============================================================

SNo: 143
Ques: You have created a stateful bean EmployeeBean for a human resource management site. The EmployeeBean uses BMT and has a processPayroll method to process the payroll of the employee. You want that the processPayroll method should always be executed in a new transaction and the method should not commit or rollback the transaction while returning. Identify whether this is possible and give a reason.
Options:
  1,Yes, it is possible transaction type annotation SUPPORTS can be used for this requirement.
  2,Yes, it is possible transaction type annotation REQUIRED can be used for this requirement.
  3,No, it is not possible as stateful session bean does not support this type of transaction policy.
  4,Yes, it is possible as stateful session bean by default supports this type of transaction policy.
Answer: 4
Marks: 3

=============================================================

SNo: 144
Ques: Billy is implementing a social networking site. He has created all the necessary enterprise beans and their configurations. Now he is implementing security for the site. He has been told that there will be following four types roles for this site:

1.guest: who can only view and explore the site.
2. user: who can view, explore and modify the site content.
3.manager: who can modify the site's behavior.
4. system_admin: who will do the configuration steps.

He is been asked to create 3 users one with only guest responsibility, one with user and manager responsibilities, and one with system_admin responsibility. How many principals and roles do you think he needs to create
Options:
  1,4 principals and 3 roles
  2,3 principals and 4 roles
  3,3 principals and 3 roles
  4,12 principals and 12 roles
Answer: 2
Marks: 3

=============================================================

SNo: 145
Ques: You are implementing a banking site for which you have created a SavingAccount entity bean for manipulating the saving bank accounts. You have created three methods in the bean, the createAccount for creating an account, the closeAccount for closing an account and the updateAccount for updating an account. All the three methods can be called from SysAdmin and Manager roles. Which of the following annotations is best suited for securing SavingAccount bean
Options:
  1,@Stateless public class SavingAccountBean implements SavingAccount{
@PermitAll
public void createAccount{..}
@PermitAll
public void closeAccount{..}
@PermitAll
public void updateAccount{..}
}
  2,@Stateless
@PermitAll
 public class SavingAccountBean implements SavingAccount{
public void createAccount{..}
public void closeAccount{..}
public void updateAccount{..}
}
  3,@Stateless
@RolesAllowed({"SysAdmin","Manager"})
public class SavingAccountBean implements SavingAccount{
public void createAccount{..}
public void closeAccount{..}
public void updateAccount{..}
}
  4,@Stateless
public class SavingAccountBean implements SavingAccount{
@RolesAllowed({"SysAdmin","Manager"})
public void createAccount{..}
public void closeAccount{..}
public void updateAccount{..}
}
Answer: 3
Marks: 3

=============================================================

SNo: 146
Ques: Samuel is implementing a banking site. He has created a stateless session bean namely, the AccountBean, and added a debitAccount method to process debit on an account. He is using BMT for implementing transactions. The following code snippet displays the partial code of the debitAccount method:

 @Stateless @TransactionManagement(BEAN)
public class AccountBean implements Account {
  public void debitAccount(int actNo, double amount) {
    try {  Connection con = dataSource.getConnection();
      userTransaction.begin();
      PreparedStatement pStmt = con.prepareStatement(
      "update ACCOUNT set balance = balance+ where account_number = ");
      prepStmt.setDouble(1, amount);
      prepStmt.setInt(2, actNo);
      int rowCount = pStmt.executeUpdate();
    } catch (Exception ex) {  }
}

Identify the error in the preceding code.
Options:
  1,In the code, TransactionManagement(CONTAINER) should be used as TransactionManagement(BEAN) is incorrect for BMT.
  2,In the code, any transaction started by a stateless session bean must commit or roll back before the method returns.
  3,In the code, there are compilation issues as default constructor is not provided in the bean.
  4,In the code, SQLException is not catched in the catch block so the code will throw a compilation error as SQLException is a checked exception.
Answer: 2
Marks: 4

=============================================================

SNo: 147
Ques: You are implementing a human resource site. You have created an Employee session bean whose createEmployee method calls createPerson method of the Person entity bean to create person record for an employee. You want that when the Employee bean is calling the Person bean's method it should call it using Manager role. For this you are using following code snippet in the deployment descriptor:
<enterprise-beans>
  <session>
  <ejb-name>Employee</ejb-name>
  ...
  <security-identity>
    <run-as>
        <role-name>Manager</role-name>
    </run-as>
    <use-caller-identity/>
  </security-identity>
 </session>
</enterprise-beans>

You now have created another method processPayroll in the Employee bean which calls the PayrollBean entity bean's runPayroll method. You expect that the runPayroll bean should not be called with Manager identity as you think that only the createPerson method of Person bean will be called with Manager identity. But unexpectedly the runPayroll method is also called with Manager identity. Identify the reason for this unexpected result
Options:
  1,Run-as identity is associated with a bean and not with its methods specifically, so if any of the bean's method executes another bean's method Manager identity is used.
  2,Use-caller-identity element is also specified in the security identity which enforces that all of the other bean's method should be called with the same identity.
  3,Security-identity element is used in deployment descriptor which can be attached only at bean level; instead RunAs annotation should have been used at method level to associate different identities.
  4,All the same type of bean calls are called using the same identity, here as Person and PayrollBean both are entity beans same identity is used.
Answer: 1
Marks: 4

=============================================================

SNo: 148
Ques: You are implementing a banking site for which you have created a SavingAccount entity bean for manipulating the saving bank accounts. You have created a method createAccount in the bean for creating account and closeAccount for closing account. createAccount can be called from SysAdmin and Manager roles. You are programmatically validating the roles of the logged in user using the following code snippet:

if(ctx.isCallerInRole("SysAdmin,Manager"){
  // allow auction to be deleted
}else {
  throw new Exception("The role is invalid");
}

But even though the logged in user has the correct roles 'The role is invalid' exception is thrown. Identify the reason for this unexpected result.
Options:
  1,isCallerInRole should be called only after calling getCallerPrinciple as calling getPrnciple initializes the ejb context.
  2,isCallerInRole accepts only a single role, it cannot be used to validate the roles from a list of comma-separated roles.
  3,isCallerInRole accepts an array of roles in the above code it treats it as a single role and fails.
  4,There is nothing wrong with the code; configuration of the application server must be invalid because of which this issue is happening.
Answer: 2
Marks: 4

=============================================================

SNo: 149
Ques: You are implementing a banking site for which you have created the SavingAccount entity bean for manipulating saving bank accounts. You have created three methods in the bean, the createAccount for creating account, the updateAccount for updating the account and the closeAccount for closing account. The createAccount and the updateAccount can be called from Manager role, but the closeAccount can only be called from SysAdmin role. You are using the following code.

@Stateless
@DeclareRoles({"Manager"})
public class BankingBean implements Banking{
    public void createAccount(){...}
    public void updateAccount(){...}
    @RolesAllowed({"SysAdmin"})
    public void closeAccount(){...}
}

While testing the bean you found that there was security vulnerability in the code, even users with Manager role were able to call the closeAccount method. Identify the reason for this unexpected behavior

Options:
  1,When both annotations i.e. DeclareRoles and RolesAllowed are used, the net effect is the aggregation of the roles, so closeAccount method allows both SysAdmin and Manager roles.
  2,RolesAllowed annotation is not a mandatory annotation some containers might not implement it, that's why the enforcing of RolesAllowed is not happening in the above code.
  3,RolesAllowed is introduced in EJB3.0 specifications, so for backward compatibility some containers do not respect this annotation.
  4,When DeclareRoles annotation is used the container neglects the RolesAllowed annotation.
Answer: 1
Marks: 4

=============================================================

SNo: 150
Ques: You are implementing a banking site for which you have created the SavingAccount entity bean for manipulating saving bank accounts. You have created three methods in the bean, the createAccount for creating account, the updateAccount for updating the account and the closeAccount for closing account. The createAccount and updateAccount can only be called from SysAdmin role, but closeAccount can also be called from Manager role. You are using the following code:

@Stateless
@RolesAllowed({"SysAdmin"})
public class BankingBean implements Banking{
    public void createAccount(){...}
    public void updateAccount(){...}
   @DeclareRoles({"Manager"})
    public void closeAccount(){...}
}

While compiling the bean you are getting a compilation error. Identify the reason in the preceding code.
Options:
  1,Both annotations i.e. DeclareRoles and RolesAllowed cannot be are used in the same bean.
  2,The bean does not define a default constructor.
  3,DeclareRoles annotation is not allowed at method level.
  4,RolesAllowed annotation is not allowed at class level.
Answer: 3
Marks: 4

=============================================================

Post a Comment

Previous Post Next Post