B. Custom BeanPostProcessors can be implemented for Spring applications.

This is true because the BeanPostProcessor interface defines callback methods that you can implement to provide your own (or override the container’s default) instantiation logic, dependency resolution logic, and so forth1. You can configure multiple BeanPostProcessor instances, and you can control the order in which these BeanPostProcessor instances run by setting the order property1. For example, in this tutorial, a custom BeanPostProcessor is implemented to integrate Guava’s EventBus with Spring beans.

D. BeanPostProcessors are called during the initialization phase of a bean life cycle.

This is true because the BeanPostProcessor interface consists of exactly two callback methods: postProcessBeforeInitialization and postProcessAfterInitialization. When such a class is registered as a post-processor with the container, for each bean instance that is created by the container, the post-processor gets a callback from the container both before container initialization methods (such as InitializingBean.afterPropertiesSet() or any declared init method) are called, and after any bean initialization callbacks1.