Magento Interview Questions and Answers

Find 100+ Magento interview questions and answers to assess candidates’ skills in eCommerce development, module customization, theme design, performance optimization, and integrations.
By
WeCP Team

As organizations scale eCommerce platforms to handle complex catalogs, high traffic, and global transactions, recruiters must identify Magento professionals who can build, customize, and maintain robust online stores. Magento (Adobe Commerce) is widely used for enterprise-grade eCommerce solutions requiring flexibility, performance, and scalability.

This resource, "100+ Magento Interview Questions and Answers," is tailored for recruiters to simplify the evaluation process. It covers a wide range of topics—from Magento fundamentals to advanced customization and performance optimization, including modules, themes, APIs, and security best practices.

Whether you're hiring Magento Developers, eCommerce Engineers, or Adobe Commerce Specialists, this guide enables you to assess a candidate’s:

  • Core Magento Knowledge: Magento architecture, product types, catalogs, pricing rules, CMS blocks/pages, and admin configuration.
  • Advanced Skills: Custom module development, theme customization, Magento REST/GraphQL APIs, checkout customization, performance optimization, and security hardening.
  • Real-World Proficiency: Building scalable eCommerce stores, integrating payment/shipping gateways, managing upgrades, handling multi-store setups, and optimizing site speed and conversions.

For a streamlined assessment process, consider platforms like WeCP, which allow you to:

  • Create customized Magento assessments tailored to eCommerce development and enterprise retail roles.
  • Include hands-on tasks such as module creation, theme customization, or debugging checkout and performance issues.
  • Proctor exams remotely while ensuring integrity.
  • Evaluate results with AI-driven analysis for faster, more accurate decision-making.

Save time, enhance your hiring process, and confidently hire Magento professionals who can build secure, scalable, and conversion-optimized eCommerce platforms from day one.

Magento Interview Questions

Magento – Beginner (1–40)

  1. What is Magento and what are its main features?
  2. Explain the architecture of Magento.
  3. What is the difference between Magento 1 and Magento 2?
  4. What is an extension in Magento?
  5. Explain modules in Magento.
  6. What is the role of Composer in Magento 2?
  7. What is the file structure of Magento 2?
  8. What is a theme in Magento?
  9. How do you create a new theme in Magento 2?
  10. What are layout XML files used for?
  11. What are blocks in Magento?
  12. What is dependency injection in Magento 2?
  13. What is the purpose of di.xml?
  14. Explain controllers in Magento.
  15. What is a route in Magento 2?
  16. Explain difference between frontend and adminhtml controllers.
  17. What is an observer in Magento?
  18. What is an event in Magento?
  19. Explain the purpose of events.xml.
  20. What is a plugin in Magento?
  21. What is the difference between plugins and observers?
  22. What is EAV in Magento?
  23. What are EAV attributes?
  24. What is the difference between EAV and flat tables?
  25. What is caching in Magento?
  26. Explain Magento’s different cache types.
  27. What is indexing in Magento?
  28. How do you reindex in Magento 2?
  29. What is command line usage in Magento 2?
  30. What is cron in Magento?
  31. What are store, store view, and website in Magento?
  32. What is the purpose of configuration in admin panel?
  33. Explain the concept of static content deployment.
  34. What is var directory used for?
  35. How do you enable or disable a module?
  36. What is Magento Marketplace?
  37. Explain product types in Magento.
  38. What is the difference between simple and configurable products?
  39. What is an attribute set?
  40. What is the role of MSI (Multi-Source Inventory)?

Magento – Intermediate (1–40)

  1. Explain the full request flow in Magento 2.
  2. What is service contracts architecture?
  3. What is the purpose of repositories in Magento 2?
  4. Explain dependency injection preference.
  5. What are virtual types in Magento?
  6. Explain factories in Magento.
  7. What is a data patch and schema patch?
  8. Difference between setup scripts and data patches.
  9. Explain the use of UI components.
  10. What is knockout.js role in Magento frontend?
  11. Explain requirejs-config.js in Magento.
  12. How do you override a controller in Magento 2?
  13. How do you override a model in Magento 2?
  14. How do you override a block or helper?
  15. What is an extension attribute?
  16. What is a custom attribute and how to add it?
  17. What is the purpose of etc/adminhtml/system.xml?
  18. How do you create custom admin configuration fields?
  19. Explain how Magento handles checkout flow.
  20. What is the role of quote and order objects?
  21. Explain Magento pricing architecture.
  22. What is storefront rendering process?
  23. Explain GraphQL implementation in Magento.
  24. What is the REST API in Magento and how do you authenticate?
  25. What is OAuth in Magento API?
  26. How to create custom API endpoints?
  27. What is the role of Varnish in Magento?
  28. How do you configure Redis in Magento?
  29. What is full page cache and how does it work?
  30. Explain Magento logging mechanism.
  31. How do you debug Magento issues?
  32. What is the purpose of xdebug in Magento development?
  33. How do you customize product pages?
  34. Explain how to add custom tab in product view.
  35. What are indexers and how do you create a custom indexer?
  36. Explain Magento observers vs plugins vs preferences.
  37. How to write a plugin for an existing method?
  38. How do you optimize performance in Magento?
  39. Explain security best practices for Magento stores.
  40. How do you migrate data from Magento 1 to Magento 2?

Magento – Experienced (1–40)

  1. Explain Magento 2 request lifecycle in detail.
  2. Describe Magento’s modular architecture at a deep level.
  3. How does Magento use dependency injection container internally?
  4. Explain Magento’s plugin execution order (before, around, after).
  5. How do you avoid plugin circular dependency issues?
  6. Explain advanced usage of service contracts.
  7. How do you create custom GraphQL resolvers?
  8. Explain how Magento handles asynchronous API.
  9. What is message queue system in Magento?
  10. How do you implement RabbitMQ in Magento?
  11. Explain MSI architecture in depth.
  12. How do you design complex inventory workflows in MSI?
  13. Explain advanced checkout customization patterns.
  14. How do you integrate Magento with third-party systems?
  15. Describe custom payment gateway implementation.
  16. How do you implement custom shipping carriers?
  17. Explain Magento cron architecture in depth.
  18. How do you debug deadlocks and race conditions in Magento?
  19. Explain Magento indexing internals.
  20. How do you write scalable custom indexers?
  21. What is Magento caching architecture behind the scenes?
  22. How do you write custom cache invalidation logic?
  23. Explain frontend performance optimization for high traffic sites.
  24. How do you optimize Magento for large catalogs (1M+ SKUs)?
  25. Explain EAV performance optimization techniques.
  26. Describe advanced MySQL tuning for Magento.
  27. How do you handle deployment for zero downtime?
  28. What is Magento Cloud architecture?
  29. Explain Blue-Green deployment in Magento Cloud.
  30. How do you handle multi-website, multi-store enterprise setups?
  31. Explain advanced ACL customization.
  32. How do you audit Magento for security?
  33. Explain custom module architecture for enterprise-level projects.
  34. How do you handle Magento scalability bottlenecks?
  35. Explain advanced Redis configuration for Magento.
  36. Explain how Varnish ESI works with Magento.
  37. Describe profiling Magento using Blackfire or similar tools.
  38. How do you ensure code quality using automated tests?
  39. Explain integration testing and unit testing in Magento.
  40. Describe strategies for high availability and failover in Magento.

Magento Interview Questions and Answers

Beginner (Q&A)

1. What is Magento and what are its main features?

Magento is a powerful, open-source eCommerce platform designed to help merchants build scalable, customizable online stores. Known for its flexibility and enterprise-grade capabilities, Magento allows developers to modify almost any aspect of the system—from product management and checkout to design and integrations.

Main Features of Magento:

  1. Modular Architecture:
    Magento is built on a module-driven structure, allowing developers to enable, disable, or replace features without affecting the entire system. This modular design makes Magento highly extensible.
  2. Advanced Product Management:
    Supports multiple product types—simple, configurable, bundled, virtual, downloadable, and grouped—allowing businesses to sell a wide range of items.
  3. Flexible Theming and Layout System:
    Magento uses a powerful theme layer that allows developers to change the look and feel without affecting the core code.
  4. Multi-Store and Multi-Language Support:
    Merchants can run multiple websites, stores, and store views from a single admin panel.
  5. SEO-Friendly Features:
    Clean URLs, metadata control, sitemaps, canonical tags, and optimized caching.
  6. Built-In Caching and Indexing:
    Magento's indexing and caching mechanisms significantly improve performance for large catalogs.
  7. Robust Security:
    Magento includes features such as CSRF protection, encryption, strong password hashing, and advanced ACL (Access Control List).
  8. Extensive API Support:
    REST, SOAP, and GraphQL interfaces allow Magento to integrate with external systems like ERP, CRM, and PIM.

Magento is widely used by mid-to-large businesses because of its scalability, extensibility, and professional feature set.

2. Explain the architecture of Magento.

Magento’s architecture is based on a modular, component-driven MVC (Model-View-Controller) pattern enriched with service contracts and dependency injection. It promotes separation of concerns and clean extensibility.

Key Architectural Components:

  1. Modules:
    Every feature in Magento exists as a module. Each module is self-contained, having its own configuration, logic, templates, and routes.
  2. MVC Layer:
    • Model: Handles business logic and interacts with the database.
    • View: Includes templates, layout XML, and UI components for the frontend.
    • Controller: Receives user requests and passes control to appropriate components.
  3. Service Contracts:
    Introduced in Magento 2, these are interfaces that define service behavior. They ensure backward compatibility and cleaner API integration.
  4. Dependency Injection (DI):
    Uses an XML-driven DI container to inject required classes, making the system more testable and flexible.
  5. Event-Observer System:
    Allows developers to hook into Magento processes without modifying core code.
  6. Plugins (Interceptors):
    Allow modification of methods before, after, or around execution.
  7. EAV (Entity-Attribute-Value) Model:
    Magento stores products, categories, and customer entities using EAV, enabling highly flexible data structures.
  8. File System Architecture:
    Divided into app, pub, vendor, generated, and var directories to separate code, public assets, auto-generated classes, and runtime cache.

Overall, Magento's architecture focuses on extensibility, modularity, and performance, making it suitable for enterprise-grade systems.

3. What is the difference between Magento 1 and Magento 2?

Magento 2 is a complete redesign of Magento 1, created to overcome performance limitations, enhance scalability, and modernize the development experience.

Major Differences:

  1. Performance Improvements:
    Magento 2 is significantly faster due to full-page caching, improved indexing, and optimized checkout. It can handle higher traffic and larger catalogs.
  2. Modern Technology Stack:
    • Magento 1 uses Prototype.js, outdated PHP versions, and older architecture.
    • Magento 2 uses PHP 7+, HTML5, CSS3, LESS, jQuery, Knockout.js, and modern coding standards.
  3. Streamlined Checkout:
    Two-step checkout in Magento 2 reduces cart abandonment and improves user experience.
  4. Dependency Injection:
    Magento 2 uses DI, eliminating reliance on Mage:: static calls used in Magento 1.
  5. Improved Admin Panel:
    The Magento 2 admin is fully responsive, customizable, and more user-friendly.
  6. Automatic Testing Framework:
    Magento 2 includes unit tests, integration tests, and performance tests, enabling better QA.
  7. Extension Management via Composer:
    Magento 2 integrates tightly with Composer, simplifying updates and dependency management.
  8. Better Security and Scalability:
    Magento 2 introduces ACL improvements, hashing upgrades, and enterprise-level scalability.

Magento 2 is a more modern, performance-optimized, and developer-friendly platform than Magento 1.

4. What is an extension in Magento?

A Magento extension is a package of code that adds new functionality or modifies existing functionality without changing core files. Extensions allow developers to expand Magento’s capabilities in a modular and safe manner.

Types of Extensions:

  1. Modules: Add backend logic, new features, workflows, and custom business logic.
  2. Themes: Modify frontend layout and design.
  3. Language Packs: Provide translations.
  4. Integrations: Connect Magento with third-party systems like payment gateways.

Purpose of Extensions:

  • Add new product types
  • Add payment or shipping methods
  • Customize checkout
  • Enhance admin features
  • Add API endpoints
  • Modify catalog or cart behavior

Magento extensions ensure modular development so that updates and maintenance remain manageable.

5. Explain modules in Magento.

A module is the basic functional unit in Magento. Each module represents a self-contained feature—such as checkout, catalog, customer, or custom business operations.

Key Characteristics of Magento Modules:

  1. Self-Contained Packages:
    Each module has its own configuration, controllers, models, views, and DI settings.
  2. Activation & Registration:
    Modules must be registered using registration.php and declared in module.xml.
  3. Configuration-Driven:
    Modules include configuration files (etc/*.xml) for routing, events, DI, ACL, system configuration, UI components, etc.
  4. Inter-Module Communication:
    Modules can interact through events, plugins, interfaces (service contracts), and repositories.
  5. Update and Versioning:
    Modules use setup scripts or patches to handle database changes and version upgrades.
  6. Enabling/Disabling:
    Modules can be enabled or disabled at command-line level using bin/magento module:enable or disable.

Modules make Magento highly extensible and maintainable by allowing new functionality to be added without modifying core code.

6. What is the role of Composer in Magento 2?

Composer is a dependency management tool for PHP, and in Magento 2 it plays a central role in managing modules, libraries, and updates.

Roles of Composer in Magento 2:

  1. Dependency Installation:
    Magento’s core code and third-party extensions rely on Composer packages. Composer automatically installs required versions.
  2. Version Control & Updates:
    You can update Magento and its modules simply by adjusting the composer.json requirements and running update commands.
  3. Autoloading:
    Composer autoloader handles class loading for Magento, improving performance and reducing custom autoloading logic.
  4. Extension Management:
    Install/remove marketplace extensions through Composer, making it easier to maintain compatibility.
  5. Environment Consistency:
    Ensures identical package versions across all environments (dev, staging, production).
  6. Vendor Isolation:
    All third-party libraries are placed inside the vendor directory, keeping Magento clean and modular.

Composer is essential for modern Magento development, deployment, and maintainability.

7. What is the file structure of Magento 2?

Magento 2 has a well-organized directory structure designed to separate core code, custom code, configuration, static assets, and runtime files.

Key Directories:

  1. app/
    Contains custom modules, themes, and configuration files.
  2. vendor/
    Contains Magento core code and third-party libraries installed via Composer.
  3. pub/
    Public-facing directory; includes static assets and the index.php bootstrap.
  4. generated/
    Contains auto-generated classes such as factories, proxies, and interceptors.
  5. var/
    Contains cache, logs, sessions, and temporary files.
  6. lib/
    Framework-specific libraries used by Magento core.
  7. setup/
    Contains installation scripts and setup utilities.

Purpose of Structured File Organization:

  • Enhances security by exposing only the pub directory
  • Separates runtime and generated files
  • Makes custom code easy to locate
  • Ensures maintainability

This structure ensures high scalability and proper separation of concerns.

8. What is a theme in Magento?

A theme is a collection of templates, styles, images, layouts, and configuration files that determine the appearance and user experience of a Magento storefront.

Key Aspects of Magento Themes:

  1. Presentation Layer:
    Themes define the visual layout, typography, colors, and UI structure.
  2. Components of a Theme:
    • HTML templates (PHTML files)
    • LESS/CSS styles
    • Layout XML files
    • Images and JS components
    • Theme configuration files (theme.xml, registration.php)
  3. Hierarchy:
    Magento supports parent-child theme inheritance, allowing developers to extend existing themes.
  4. Frontend Customization:
    Themes allow changing storefront design without touching backend logic or modules.

A well-built theme ensures responsive design, performance optimization, and ease of customization.

9. How do you create a new theme in Magento 2?

Creating a new theme in Magento 2 involves several steps:

  1. Create the Theme Directory:
app/design/frontend/VendorName/ThemeName/
  • Add theme.xml:
    Defines theme metadata and parent theme (if any).
  • Add registration.php:
    Registers the theme with Magento.
  • Add composer.json (optional):
    For distributing or versioning the theme.
  • Create subdirectories:
    • web/ for CSS, JS, images
    • templates/ for PHTML files
    • layout/ for XML layout customizations
    • etc/ for theme-specific config
  • Specify Parent Theme or Blank Theme:
    Themes usually extend Luma or blank theme.
  • Enable the Theme in Admin:
    Go to Content → Design → Configuration and apply the theme to a store view.
  • Deploy static content:
  • bin/magento setup:static-content:deploy
    

    This structured approach ensures a clean, modular theme that adheres to Magento standards.

    10. What are layout XML files used for?

    Layout XML files control the structure, layout, and UI composition of pages in Magento. They connect modules, templates, and blocks to create dynamic page structures.

    Primary Functions of Layout XML Files:

    1. Page Structure Definition:
      Define containers and blocks on the page (header, footer, content, sidebar).
    2. Adding or Removing Blocks:
      Developers can insert, move, or delete blocks.
    3. Template Binding:
      XML links templates (PHTML files) to blocks.
    4. Customization Per Route:
      Layout updates can target specific pages such as product view, category listing, or CMS pages.
    5. Event-Driven Layout Changes:
      Layouts can be updated via handles that trigger for specific requests.
    6. Dynamic Content Placement:
      Helps position components without modifying templates directly.

    Common layout XML locations include:

    • app/design/frontend/.../layout/
    • vendor/magento/module-*/view/frontend/layout/

    Layout XML is essential for frontend customization and is a major component of Magento’s view layer.

    11. What are blocks in Magento?

    Blocks in Magento represent the middle layer between controllers and templates. They are PHP classes responsible for preparing data that is rendered in the view layer. Blocks act as view models, enabling separation of logic and presentation.

    Key Characteristics of Blocks:

    1. Bridge Between Logic and Templates:
      Blocks take data from models or services and pass it to .phtml templates for rendering.
    2. Two Types of Blocks:
      • Standard Blocks: Used to control what data is displayed.
      • View Models (Block Classes): Provide business-specific logic to templates.
    3. Defined in Layout XML:
      Blocks are declared and positioned via layout XML files, telling Magento where and how they should appear.
    4. Template Rendering:
      Each block may be linked with a template file using the template attribute in layout XML.
    5. Reusability:
      Blocks can be used multiple times across different pages and themes.
    6. Block Methods:
      Blocks allow creating methods that the template can call, providing clean, structured data.

    Example Use Case:
    A product listing page block fetches product collection data, prepares it, and sends it to the template where it is rendered.

    Blocks ensure clean MVC separation, helping maintain a scalable frontend architecture.

    12. What is dependency injection in Magento 2?

    Dependency Injection (DI) is a design pattern that Magento 2 uses to manage class dependencies. Instead of a class creating its own dependencies, DI allows the system to inject required objects at runtime.

    Why DI is Important:

    1. Reduces Hard Dependencies:
      Classes don’t need to manually instantiate objects.
    2. Improves Testability:
      Mock objects can be injected during testing.
    3. Enhances Flexibility:
      Changing dependencies no longer requires modifying class code.
    4. Promotes Interface-Based Design:
      Magento encourages using interfaces, making code more stable and modular.

    Types of DI in Magento:

    1. Constructor Injection (Most Common): Dependencies passed through constructor.
    2. Method Injection: Dependencies passed via method parameters.
    3. Setter Injection: Dependencies passed via setter methods.

    DI Container:
    Magento uses a DI container that reads di.xml configuration and resolves class dependencies automatically.

    DI ensures Magento 2 code is modular, reusable, and easy to maintain.

    13. What is the purpose of di.xml?

    The di.xml file is the central configuration file for dependency injection in Magento. It defines how Magento should instantiate classes, which implementations to use, and how objects interact.

    Key Purposes of di.xml:

    1. Class Preferences:
      Define which class should be used when an interface is requested.
      Example: mapping an interface to a custom implementation.
    2. Virtual Types:
      Create class variations without writing a new PHP class.
    3. Plugins (Interceptors):
      Register plugins that modify method behavior.
    4. Arguments Injection:
      Override constructor arguments of classes.
    5. Shared / Non-Shared Instances:
      Define whether Magento should create a single instance or new instance every time.
    6. Factories, Proxies, and Custom Objects:
      Tell Magento how to generate and inject these special classes.

    There are different scopes of di.xml:

    • Global Level: app/code/*/*/etc/di.xml
    • Frontend Level: view/frontend/di.xml
    • Admin Level: view/adminhtml/di.xml

    di.xml is the backbone of Magento's object management system and plays a critical role in customizing system behavior.

    14. Explain controllers in Magento.

    Controllers in Magento are responsible for handling incoming HTTP requests and returning appropriate responses. They act as intermediaries between user actions and business logic.

    Key Characteristics of Magento Controllers:

    1. Routing Layer:
      When a user visits a URL, Magento identifies the controller/action responsible for processing it.
    2. Action Classes:
      Each controller action is a separate PHP class extending Action or its subclasses.
    3. Execute Method:
      The main method in every controller action is execute(), where business logic goes.
    4. Result Objects:
      Controllers return responses like:
      • Page result (HTML page)
      • JSON result
      • Redirect result
      • Raw result
    5. Frontend vs Admin Controllers:
      Different base classes and routing rules apply to each area.
    6. Purpose of Controllers:
      • Validate request
      • Call models or services
      • Prepare data
      • Pass data to blocks/views

    Controllers allow Magento to perform operations such as loading pages, submitting forms, updating cart data, or saving customer information.

    15. What is a route in Magento 2?

    A route in Magento determines how a URL maps to a controller. It is the first step in Magento’s request flow.

    Three Parts of a Route:

    1. Front Name:
      First part of the URL, defined in routes.xml.
    2. Controller Folder:
      Second part of the URL maps to a folder under Controller directory.
    3. Action Class:
      Final part maps to a controller action class.

    Example URL:
    example.com/blog/post/view

    Breakdown:

    • blog → front name
    • post → controller folder
    • view → action class

    Routes are defined via:

    etc/frontend/routes.xml
    etc/adminhtml/routes.xml
    

    Routes allow Magento to register URL patterns and map them to controllers, enabling structured, modular request handling.

    16. Explain difference between frontend and adminhtml controllers.

    Magento separates backend (admin) and storefront (frontend) functionality into two distinct controller areas.

    Frontend Controllers:

    • Located in: Controller/ under etc/frontend/routes.xml
    • Handle customer-facing pages like product listings, checkout, account pages.
    • Use base class: \Magento\Framework\App\Action\Action
    • Use layout XML in view/frontend/layout/

    Adminhtml Controllers:

    • Located in: Controller/Adminhtml/
    • Defined in: etc/adminhtml/routes.xml
    • Require ACL permissions for access control.
    • Use base class: \Magento\Backend\App\Action
    • Use layout XML in view/adminhtml/layout/

    Key Differences:

    FeatureFrontend ControllerAdminhtml ControllerAudienceCustomersAdmin usersSecurityLess strictRequires ACL permissionsBase ClassActionBackend ActionView FilesFrontend layout directoryAdminhtml layout directoryURL StructurePublic URLsSecured /admin URLs

    Admin controllers are strictly secured and permission-controlled, whereas frontend controllers focus on user experience.

    17. What is an observer in Magento?

    An observer is a class that listens for specific events in Magento and executes custom logic when those events occur.

    Key Characteristics:

    1. Triggered by Events:
      When an event dispatches, all registered observers run automatically.
    2. Loose Coupling:
      Observers allow adding functionality without modifying core code.
    3. Event-Driven Programming Pattern:
      Magento uses this pattern for extending or modifying workflows.
    4. Uses execute Method:
      Observer classes implement ObserverInterface and include an execute() method.

    Use Cases:

    • Logging actions
    • Modifying cart data
    • Sending custom emails
    • Updating product attributes automatically
    • Integration with third-party systems

    Observers help developers integrate business logic cleanly and efficiently.

    18. What is an event in Magento?

    Events are specific system triggers that Magento dispatches during workflow execution. They allow custom code to hook into the process.

    Examples of Events:

    • checkout_cart_add_product_complete
    • customer_login
    • catalog_product_save_before
    • sales_order_place_after

    Key Features:

    1. Dispatched via Event Manager:
      Magento fires events at defined points in core modules.
    2. Custom Events:
      Developers can dispatch custom events using:
    $this->_eventManager->dispatch('event_name', $data);
    
    1. Flexible Architecture:
      Allows adding or modifying functionality without extending classes.

    Events make Magento highly extensible by providing powerful integration points.

    19. Explain the purpose of events.xml.

    The events.xml file is used to register observers for specific events. It defines which observer classes should run when an event is dispatched.

    Where it's located:

    • etc/events.xml → global (both areas)
    • etc/frontend/events.xml → frontend only
    • etc/adminhtml/events.xml → admin only

    Structure:

    <event name="event_name">
        <observer name="observer_name" instance="Vendor\Module\Observer\Class" />
    </event>
    

    Purpose:

    1. Associates an event with its observer.
    2. Controls when and where the observer is triggered.
    3. Enables modular, decoupled customization.

    Magento reads all events.xml files and builds a runtime map of event → observer relationships.

    20. What is a plugin in Magento?

    A plugin (also known as an interceptor) allows a developer to modify the behavior of public methods in any class without overriding it.

    Plugins provide fine-grained control over method execution.

    Types of Plugins:

    1. Before Plugin:
      Runs before the original method.
    2. After Plugin:
      Runs after the original method returns.
    3. Around Plugin:
      Wraps the method and can completely replace or modify it.

    Advantages:

    1. Non-Intrusive Customization:
      No need to rewrite or override classes.
    2. More Control Than Observers:
      Can modify arguments and return values.
    3. Used for Custom Business Logic:
      Common for cart manipulation, product repository, price calculations, etc.

    Registered in:

    etc/di.xml
    

    Plugins are one of Magento’s most powerful customization mechanisms.

    21. What is the difference between plugins and observers?

    Both plugins and observers allow customization in Magento, but they serve different purposes and work at different levels of the system.

    Observers: Event-Based Customization

    Observers listen for events and run when those events are dispatched.

    Characteristics:

    • Work on an event-driven system.
    • Good for reacting to actions (e.g., customer login, order placement).
    • Cannot modify method arguments or return values directly.
    • Do not target specific methods — instead, they respond to system events.

    Use Cases:

    • Log customer actions
    • Send additional notifications
    • Modify data before saving
    • Trigger integrations (ERP, CRM)

    Plugins: Method-Level Interception

    Plugins intercept specific public methods in Magento classes.

    Characteristics:

    • Modify behavior of a single method.
    • Can change arguments (before plugin).
    • Can change return values (after plugin).
    • Can fully replace execution (around plugin).
    • More precise than observers.

    Use Cases:

    • Modify price calculation logic
    • Extend product save behavior
    • Change checkout totals
    • Adjust cart operations

    Key Differences (Summary)

    FeatureObserversPluginsBased OnEventsMethodsModifiesWorkflow triggered by eventSpecific method behaviorCan change arguments?NoYesCan change return value?NoYesUse CaseTrigger logic at specific stagesModify or wrap single method execution

    Conclusion:
    Use observers for reacting to system-level events and plugins for altering specific method behavior.

    22. What is EAV in Magento?

    EAV stands for Entity-Attribute-Value, a flexible database model used in Magento for storing complex and customizable data.

    Magento uses EAV for:

    • Products
    • Categories
    • Customers
    • Customer addresses

    Why EAV is Used:

    1. Supports dynamic attributes:
      Merchants can create unlimited attributes (color, size, brand) without altering database tables.
    2. Highly flexible:
      Useful for product catalogs with diverse attribute sets.
    3. Separation of Data:
      Values are stored based on type — varchar, text, int, decimal, datetime.

    EAV Structure Includes:

    • Entity Table: Holds base entity info (e.g., product ID).
    • Attribute Tables: Store metadata of attributes.
    • Value Tables: Store actual attribute values.

    Advantages:

    • Flexible and extensible
    • Supports huge product catalogs with variable attributes
    • Attributes can be created without schema changes

    Disadvantages:

    • More complex queries
    • Slower performance compared to flat tables
    • Requires indexing for speed

    EAV is ideal for systems needing high flexibility at the cost of complexity.

    23. What are EAV attributes?

    EAV attributes are individual properties or fields that belong to an EAV entity (product, customer, etc.). They define the nature of the data stored.

    Examples of Product EAV Attributes:

    • Name
    • SKU
    • Color
    • Size
    • Weight
    • Description
    • Price

    Attribute Properties Include:

    1. Frontend Input Type:
      (text, dropdown, multiselect, date, boolean)
    2. Backend Data Type:
      (varchar, int, decimal, datetime, text)
    3. Scope:
      (global, website, store)
    4. Visibility:
      Should it appear in frontend or admin.
    5. Searchable / Filterable:
      Used for layered navigation or search.
    6. Required or Optional:
      Determines if the value must be provided.

    Why EAV Attributes Matter:

    They give Magento the ability to support highly customizable catalogs without changing database schema.

    24. What is the difference between EAV and flat tables?

    Magento uses both EAV and flat table structures depending on performance and flexibility needs.

    EAV Model (Flexible, Complex):

    Pros:

    • Unlimited attributes
    • Easy to add new fields
    • Highly flexible

    Cons:

    • Multiple joins needed
    • Slower for large catalogs
    • Complex structure

    Use Case:
    Product attributes, customer profiles where flexibility is required.

    Flat Table Model (Optimized, Faster):

    Magento can flatten EAV data into a single table via indexing.

    Pros:

    • Faster SELECT queries
    • Ideal for catalog listing
    • Better for frontend performance

    Cons:

    • Less flexibility
    • Requires reindexing when attributes change

    Use Case:
    Product listing pages, search results, category pages.

    Summary Table

    FeatureEAVFlat TableFlexibilityHighLowPerformanceSlowerFastDatabase StructureMulti-tableSingle-tableUse CasesAttribute-rich dataRead-heavy queries

    Magento reconciles both systems using indexing.

    25. What is caching in Magento?

    Caching in Magento is the process of storing precomputed or pre-rendered data to improve performance and reduce server load.

    Why Cache Is Important:

    • Reduces page load time
    • Reduces database queries
    • Improves scalability
    • Enhances customer experience

    Magento Uses Multiple Cache Layers:

    1. In-memory cache: Redis, Memcached
    2. Full Page Cache: Varnish or built-in FPC
    3. Block cache: Reusable block HTML
    4. Configuration cache: Stores merged configuration

    Examples of Cached Content:

    • Product data
    • Layout XML
    • Translations
    • Template output
    • Config settings

    Without caching, Magento would be extremely slow due to its dynamic, modular architecture.

    26. Explain Magento’s different cache types.

    Magento has several cache types, each serving a specific purpose. Key cache types include:

    1. Configuration Cache

    Stores merged configurations from config.xml, di.xml, and module settings.

    2. Layout Cache

    Stores layout instructions (structure of pages).

    3. Block HTML Output

    Caches block-level HTML to avoid regenerating it.

    4. Collections Data Cache

    Caches database query results for faster reuse.

    5. Page Cache (Full Page Cache)

    Stores full HTML output of pages.
    Huge performance benefit, especially with Varnish.

    6. Translation Cache

    Stores translation strings for different store views.

    7. EAV Cache

    Stores EAV attribute metadata.

    8. Web Services Configuration

    Caches API configuration for faster service calls.

    Manage Cache Using CLI:

    bin/magento cache:status
    bin/magento cache:flush
    bin/magento cache:clean
    

    Caching is key for optimized Magento performance.

    27. What is indexing in Magento?

    Indexing is the process of converting data from EAV tables into optimized flat structures, improving performance of frontend operations such as:

    • Product listing
    • Search results
    • Price calculations
    • Category relations

    Why Magento Needs Indexing:

    EAV tables are flexible but slow.
    Indexing transforms EAV data into fast lookup tables.

    Common Magento Indexers:

    • Product flat data
    • Category flat data
    • Stock data
    • Price index
    • URL rewrites
    • Storefront catalog search

    Index Modes:

    1. Update on Save:
      Index updates immediately.
    2. Update by Schedule:
      Cron updates the index periodically.

    Indexing ensures Magento remains performant with large catalogs.

    28. How do you reindex in Magento 2?

    Reindexing can be performed via:

    Command Line (Fastest Method):

    bin/magento indexer:reindex
    

    Reindex a Specific Indexer:

    bin/magento indexer:reindex indexer_name
    

    View Indexer Status:

    bin/magento indexer:status
    

    Set Indexer Mode:

    bin/magento indexer:set-mode schedule
    bin/magento indexer:set-mode realtime
    

    Admin Panel Method:

    Stores → Configuration → Index Management

    Reindexing ensures updated product, price, and category data appear correctly and performs efficiently.

    29. What is command line usage in Magento 2?

    Magento provides a powerful CLI tool (bin/magento) used for administration, setup, cache, indexing, deployment, and maintenance tasks.

    Common CLI Commands:

    1. Cache Management:

    bin/magento cache:clean
    bin/magento cache:flush
    

    2. Reindex:

    bin/magento indexer:reindex
    

    3. Module Management:

    bin/magento module:enable
    bin/magento module:disable
    

    4. Setup Upgrade:

    bin/magento setup:upgrade
    

    5. Deploy Static Content:

    bin/magento setup:static-content:deploy
    

    6. Maintenance Mode:

    bin/magento maintenance:enable
    bin/magento maintenance:disable
    

    7. Admin User Creation:

    bin/magento admin:user:create
    

    Advantages of CLI:

    • Faster than admin panel
    • Access to advanced commands
    • Essential for DevOps and deployments

    CLI usage is core to Magento development and server maintenance.

    30. What is cron in Magento?

    Cron is a scheduled task system that automates repetitive Magento operations.

    Magento uses cron jobs for:

    • Reindexing (when in schedule mode)
    • Email sending
    • Sitemap generation
    • Cache cleaning
    • Log cleanup
    • Currency rate updates
    • Sales reports updates
    • Order follow-up processes

    Magento Cron Runs in Three Cron Groups:

    1. default → general tasks
    2. index → indexers
    3. crontab → external/system tasks

    Cron is defined in:

    app/code/.../etc/crontab.xml
    

    Magento must have cron properly configured for:

    • Checkout success emails
    • Scheduled indexing
    • Auto-generated sitemaps
    • Stock updates

    Without cron, many features fail to work.

    31. What are store, store view, and website in Magento?

    Magento has a hierarchical structure that allows merchants to manage multiple storefronts from a single backend. It consists of Website → Store → Store View.

    Website

    A website is the top-level container in Magento’s multi-store architecture.

    Key characteristics:

    • Has its own customers, orders, and configuration scope.
    • Can have different base currencies.
    • Multiple stores can belong to one website.

    Use case:
    Different business units under one Magento installation (e.g., retail vs wholesale).

    Store

    A store represents a catalog root and defines a specific product structure.

    Characteristics:

    • Each store can have a unique catalog (root category).
    • Multiple stores share customer information if they belong to the same website.
    • Different stores may use different themes.

    Use case:
    Multiple brands sharing the same backend but having different product catalogs.

    Store View

    A store view is the presentation layer, typically used for localization.

    Characteristics:

    • Represents language or regional variations.
    • Customers can switch store views (e.g., English, French, German).
    • Pricing and taxes usually come from website scope, not store views.

    Use case:
    Same store, different languages or display formats.

    Summary Table

    LevelPurposeExampleWebsiteCustomer base, currencyUS Site vs EU SiteStoreCatalog structureElectronics vs FashionStore ViewLanguage/regionEnglish / French / German

    This architecture allows tremendous flexibility for global eCommerce operations.

    32. What is the purpose of configuration in admin panel?

    The Magento admin configuration section allows merchants and developers to customize system behavior without modifying code. It provides an organized interface to manage store settings.

    Main Purposes:

    1. Control Store Functionality:
      Manage checkout, payment methods, shipping methods, tax settings, emails, products, etc.
    2. Manage Extensions & Integrations:
      Third-party modules expose settings here so store owners can adjust API keys, modes, logging, etc.
    3. Set Global, Website, or Store View Values:
      Magento has different configuration scopes, enabling granular control:
      • Global
      • Website
      • Store
      • Store View
    4. System-Level Settings:
      Includes caching, index management, file storage, cron settings, and developer tools.
    5. Theming & Design:
      Change themes, logo upload, default pages, header/footer content.
    6. Security Controls:
      Admin passwords, session validation, CAPTCHA, reCAPTCHA.

    Why It’s Important?

    • Reduces need for code changes
    • Allows multi-store flexibility
    • Ensures maintainability
    • Enables non-technical administrators to manage store settings

    Magento’s configuration system makes it one of the most flexible eCommerce platforms.

    33. Explain the concept of static content deployment.

    Static content deployment (SCD) is the process of generating and publishing static frontend assets such as:

    • CSS
    • JS
    • HTML templates
    • Images
    • Fonts
    • LESS/SCSS compiled files

    These files are placed in the pub/static/ directory and served to customers.

    Why Static Content Deployment Is Needed:

    1. Performance Optimization:
      Pre-compiling assets improves loading speed.
    2. Theme Updates:
      When modifying a theme, SCD ensures changes are reflected on the frontend.
    3. Production Mode Requirement:
      In production mode, Magento does not generate static files automatically; they must be deployed.

    Main Command:

    bin/magento setup:static-content:deploy
    

    You can specify languages or themes:

    bin/magento setup:static-content:deploy en_US --theme Vendor/theme
    

    Modes Impacting SCD:

    ModeStatic Files HandlingDeveloper ModeAuto-generated on the flyProduction ModeMust be deployed manually

    Purpose:

    SCD ensures Magento generates optimized static assets suitable for fast, secure frontend delivery.

    34. What is var directory used for?

    The var/ directory is Magento’s runtime storage directory, used for caching, logs, session files, and other temporary data.

    Key Subdirectories:

    1. var/cache
      Stores cache entries for faster processing.
    2. var/page_cache
      Used by Full Page Cache (FPC).
    3. var/log
      Contains system logs and developer logs.
    4. var/session
      Stores session files when "file" session storage is used.
    5. var/view_preprocessed
      Contains preprocessed view files.
    6. var/report
      Stores error reports.
    7. var/importexport
      Temporary files for import/export operations.
    8. var/composer_home
      Composer-related cache.

    Purpose of var Directory:

    • Improve performance via caching
    • Store logs for debugging
    • Maintain temporary data
    • Assist in asset generation

    It is safe to delete most contents (not the folder) when troubleshooting caching issues.

    35. How do you enable or disable a module in Magento?

    Magento allows enabling and disabling modules via CLI.

    Check Module Status:

    bin/magento module:status
    

    Enable a Module:

    bin/magento module:enable Vendor_Module
    

    Followed by:

    bin/magento setup:upgrade
    

    Disable a Module:

    bin/magento module:disable Vendor_Module
    

    (Optional) To prevent static files from loading:

    bin/magento setup:upgrade
    

    Remove Code Executions (Optional):

    bin/magento cache:flush
    bin/magento setup:di:compile
    

    Important Notes:

    • Disabling important core modules can break Magento.
    • Use version control before modifying module states.

    Magento’s module system supports clean, modular extension management.

    36. What is Magento Marketplace?

    Magento Marketplace is the official platform where merchants and developers can purchase, download, and manage extensions and themes for Magento.

    Key Features:

    1. Trusted Extensions:
      All extensions undergo quality, security, and compatibility checks.
    2. Wide Range of Categories:
      • Payment gateways
      • Shipping methods
      • SEO tools
      • Marketing tools
      • ERP/CRM connectors
      • Themes & templates
    3. Developer Submissions:
      Developers can sell premium extensions.
    4. Extension Upgrades via Composer:
      Extensions integrate cleanly with Magento’s codebase.
    5. Account & License Management:
      Easy update management from Magento account dashboard.

    Purpose:

    • Provides reliable third-party modules
    • Reduces development time
    • Ensures quality standards
    • Helps merchants extend store functionality quickly

    Marketplace is essential to Magento’s ecosystem.

    37. Explain product types in Magento.

    Magento supports several product types to handle diverse eCommerce needs.

    1. Simple Product

    • Basic product without variations
    • Can be used as a child product in configurable products

    2. Configurable Product

    • Parent product with selectable options (size, color)
    • Each option is linked to simple child products

    3. Grouped Product

    • Collection of simple products displayed together
    • No parent price, customers choose quantities for each item

    4. Bundle Product

    • Customer-created product built from multiple items
    • Each component can be customizable (dropdown, radio, etc.)

    5. Virtual Product

    • No shipping required
    • Used for warranties, subscriptions, online services

    6. Downloadable Product

    • Files customers download after purchase
    • eBooks, software, digital media

    7. Gift Card Product

    • Available in fixed, open, or dropdown amounts
    • Used for gifting and stored value systems

    These options make Magento suitable for almost any business type.

    38. What is the difference between simple and configurable products?

    Simple Product

    • Single, standalone product
    • No variations
    • Has a unique SKU
    • Used for physical, virtual, or child products

    Example:
    A water bottle with one color.

    Configurable Product

    • Parent product with multiple variations
    • Each variation is a simple product with its own SKU
    • Allows customers to choose attributes like size, color, weight

    Example:
    A t-shirt available in multiple sizes and colors.

    Key Differences:

    FeatureSimpleConfigurableVariationsNoYesAttributesOne setMultiple selectableSKUOne per productOne per childInventoryTracked individuallyTracked per variationVisibilityCan be hiddenParent is visible

    Configurable products improve user experience by enabling attribute-driven selection.

    39. What is an attribute set?

    An attribute set is a collection of attributes assigned to products. It defines what fields a product will have in the admin.

    Why Attribute Sets Matter:

    1. Different product types need different data fields:
      Example:
      • Clothing → size, color, material
      • Electronics → warranty, model number, specifications
    2. Organizes attributes into groups for easier administration.
    3. Ensures fast product creation:
      Selecting an attribute set automatically loads associated attributes.

    Attributes Within a Set May Include:

    • General attributes
    • Technical specifications
    • Marketing fields
    • SEO metadata

    Magento allows merchants to create unlimited custom attribute sets, making it highly flexible.

    40. What is the role of MSI (Multi-Source Inventory)?

    MSI (Multi-Source Inventory) is a system in Magento 2 that allows merchants to manage inventory across multiple physical locations.

    Key Features of MSI:

    1. Multiple Inventory Sources
      Examples:
      • Warehouse A
      • Retail store B
      • Dropship supplier C
    2. Stocks
      Stocks link sales channels (websites) with inventory sources.
    3. Source Selection Algorithm (SSA)
      Determines from which warehouse an order should ship based on:
      • Distance
      • Stock availability
      • Priority rules
    4. Salable Quantity
      Separate from physical quantity; accounts for reservations during checkout.
    5. Inventory Reservations
      Prevents race conditions for high-volume stores.

    Benefits of MSI:

    • Supports enterprise-level inventory operations
    • Improves performance by offloading stock calculations
    • Allows splitting shipments
    • Enables omnichannel inventory visibility
    • Supports backorders and preorders more efficiently

    MSI is essential for modern multi-warehouse or multi-region Magento stores.

    Intermediate (Q&A)

    1. Explain the full request flow in Magento 2.

    Magento 2 follows a structured and modular request flow based on front controllers, routers, controllers, blocks, and layout rendering. Here’s a step-by-step explanation of how a request is processed:

    Step-by-Step Request Flow

    1. pub/index.php Entry Point

    Every Magento request begins at this file. It bootstraps the application and sets up the Object Manager.

    2. Initialization & Bootstrapping

    The system loads:

    • Dependency Injection (DI) configuration
    • Module configuration
    • Application state
    • Area code (frontend, adminhtml, crontab, etc.)

    3. Front Controller Dispatch

    Magento uses a Front Controller pattern, where a single controller handles all requests initially.

    The front controller receives the request and sends it to the routing system.

    4. Routing

    Routers determine which module should handle the request. Magento has four default routers:

    • Admin Router
    • Standard Router
    • CMS Router
    • Default Router

    Routers map the URL to:

    • Route (frontName)
    • Controller folder
    • Action class

    5. Controller Execution

    Once the matching route is found:

    • Controller action’s execute() method is called.
    • It processes input, loads models/services, and performs logic.

    The controller returns a Result Object (Page, JSON, Redirect, Raw, Layout, Forward).

    6. Layout & Block Loading (Frontend Only)

    Magento loads layout XML files based on request handles:

    • Defines page structure (containers)
    • Adds/removes blocks
    • Attaches templates to blocks

    7. View Rendering

    Blocks pass data to .phtml templates, which generate HTML.

    Static content (CSS, JS, images) is loaded from pub/static folder.

    8. Response Sent to Browser

    Magento returns the final HTML page, JSON, or other data.

    Summary

    Magento’s request flow is built on:

    • Front Controller
    • Routers
    • Controllers
    • Models
    • Layout XML
    • Blocks
    • Templates

    This highly modular flow enables flexible customization without modifying core code.

    2. What is service contracts architecture?

    Service Contracts are a set of interfaces (API contracts) that define how modules interact with each other. They provide a stable API layer for Magento.

    Components of Service Contracts:

    1. Data Interfaces (Api/Data/)
      Define data structures (DTOs) passed between services.
    2. Service Interfaces (Api/)
      Define operations (CRUD, business operations, repositories).

    Example:
    Magento\Catalog\Api\ProductRepositoryInterface

    Benefits of Service Contracts:

    1. API Stability

    Interfaces allow backward compatibility even if implementation changes.

    2. Clear Module Boundaries

    Modules communicate through contracts, not concrete implementations.

    3. Web API Integration

    REST, SOAP, and GraphQL automatically expose service contracts.

    4. Testing & Decoupling

    Easier to mock or replace implementations during testing.

    Purpose

    Service contracts enforce good architectural practices:

    • Loose coupling
    • Reusability
    • Abstract behavior over implementation

    Service Contracts are central to Magento 2’s extensibility and maintainability.

    3. What is the purpose of repositories in Magento 2?

    Repositories are part of Service Contracts architecture and provide a canonical way to perform CRUD operations on entities.

    Example:

    • ProductRepositoryInterface
    • CustomerRepositoryInterface
    • CategoryRepositoryInterface

    Purpose of Repositories:

    1. Encapsulate Data Persistence Logic
      Repositories hide database complexity from developers.
    2. Provide Data Access API
      They support:
      • save()
      • getById()
      • getList()
      • delete()
    3. Work with Web APIs Automatically
      Repositories are exposed to REST and SOAP automatically.
    4. Better than using Models Directly
      Models allow too much control and break encapsulation, whereas repositories enforce structured behavior.

    Why Repositories Matter:

    They provide a standardized, decoupled, and service-oriented interface to access and manage Magento entities.

    4. Explain dependency injection preference.

    In Magento, dependency injection preferences are used to tell the system which concrete implementation should be used for a given interface.

    Defined in di.xml:

    <preference for="Vendor\Module\Api\MyInterface" type="Vendor\Module\Model\MyClass" />
    

    Purpose of Preferences:

    1. Replace Implementations Easily
      Allows overriding of default Magento classes.
    2. Promotes Interface-Based Architecture
      Forces developers to code against interfaces.
    3. Custom Business Logic Injection
      Replace Magento core behavior with custom implementations.

    Important Note:

    Preferences should be used sparingly, because:

    • They override entire classes.
    • They can conflict with other modules.
    • Plugins are usually a better choice for small modifications.

    When to Use Preference?

    • When you need to completely replace a class implementation.
    • When no plugin or observer can achieve the requirement.

    5. What are virtual types in Magento?

    Virtual types allow Magento to create variations of existing classes without writing a new PHP class file.

    Definition Example (di.xml):

    <virtualType name="CustomLogger" type="Magento\Framework\Logger\Monolog">
        <arguments>
            <argument name="name" xsi:type="string">custom_logger</argument>
        </arguments>
    </virtualType>
    

    Key Characteristics:

    1. No Physical Class File
      Virtual types exist only in DI configuration.
    2. Different Constructor Arguments
      Virtual types enable customized object instantiation.
    3. Useful for Reusing Logic
      Example: Multiple loggers using the same Monolog class.
    4. Lightweight Customization
      No need to extend classes unnecessarily.

    When to Use Virtual Types:

    • To generate variations of classes with different dependencies.
    • To avoid class inheritance.

    Virtual types reduce code duplication and promote configuration-driven development.

    6. Explain factories in Magento.

    Factories in Magento are used to create objects dynamically at runtime instead of directly using new ClassName().

    Magento generates factory classes automatically during code compilation.

    Purpose of Factories:

    1. Dynamic Object Creation
      Used when objects require runtime parameters.
    2. Avoid Direct Instantiation
      Ensures compatibility with DI and Magento’s object manager.
    3. Supports Object Scopes
      Factory-created objects are never shared (non-singleton).

    Example Usage:

    public function __construct(
        \Vendor\Module\Model\CustomModelFactory $customModelFactory
    ) {
        $this->customModelFactory = $customModelFactory;
    }
    
    $model = $this->customModelFactory->create();
    

    Advantages:

    • Clean, decoupled object creation
    • Supports constructor changes without breaking code
    • Essential for models, data objects, and forms

    Factories are a core part of Magento’s DI and object lifecycle management.

    7. What is a data patch and schema patch?

    Magento introduced data patches and schema patches in 2.3 to replace setup scripts.

    Schema Patch

    Used to modify database structure (schema).

    Example operations:

    • Create tables
    • Add/modify columns
    • Add foreign keys

    Defined in:

    Setup/Patch/Schema
    

    Implements:

    SchemaPatchInterface
    

    Data Patch

    Used to insert or update data.

    Operations include:

    • Insert default values
    • Create CMS pages
    • Add product attributes
    • Update configuration values

    Defined in:

    Setup/Patch/Data
    

    Implements:

    DataPatchInterface
    

    Advantages Over Setup Scripts:

    • Version-controlled
    • Declarative
    • Re-runnable
    • Trackable
    • Executed only once automatically

    8. Difference between setup scripts and data patches.

    FeatureSetup Scripts (Old)Data/Schema Patches (New)LocationSetup folderPatch folderExecutionRun on every upgradeExecuted onceTrackingNoYesRollback SupportPoorGoodDeclarativeNoYesMaintainabilityHardEasyError-proneVeryMinimal

    Setup Scripts Problems:

    • Required conditional checks
    • Hard to maintain
    • Not modular

    Patch System Fixes:

    • More modular
    • Auto-managed execution
    • Version-aware

    Magento strongly recommends using patches instead of legacy setup scripts.

    9. Explain the use of UI components.

    UI components are XML-driven frontend and admin elements used to build dynamic user interfaces, especially in the admin panel.

    Key Characteristics:

    1. Reusable Components
      Data grids, forms, filters, modals.
    2. Powered by Knockout.js & RequireJS
      Makes the UI dynamic and reactive.
    3. Used Heavily in Admin
      Grids, edit forms, filters rely on UI component XML.
    4. MVC-Like Structure
      • XML configuration
      • JS ViewModel
      • HTML templates
    5. Supports Data Providers
      Used to load data for forms/grids.

    Common UI Components:

    • Data Grid
    • Form
    • Listing
    • Datepicker
    • Select fields with dynamic data
    • Modal windows

    Benefits:

    • Reduces custom JS coding
    • Clean separation between data and UI
    • Declarative, extensible architecture
    • Fits Magento’s modular system well

    UI components are essential for building advanced admin functionality.

    10. What is knockout.js role in Magento frontend?

    Knockout.js is a JavaScript MVVM (Model-View-ViewModel) library used heavily in Magento’s frontend, especially during dynamic interactions.

    Role in Magento:

    1. Data Binding
      Binds data models to UI elements in real-time.
    2. Dynamic Checkout
      Magento’s checkout is built entirely with Knockout.js templates and observables.
    3. Customer Account & Cart Interactions
      Dynamic blocks like minicart and shipping methods update automatically.
    4. UI Components Integration
      KO is the core JS framework behind UI components.
    5. Two-Way Binding
      Changes in UI update data models and vice-versa.

    Why Magento Uses Knockout.js:

    • Lightweight and flexible
    • Works well with RequireJS
    • Efficient reactive binding
    • Ideal for dynamic eCommerce processes

    Knockout.js powers Magento's dynamic user experiences without requiring page reloads.

    11. Explain requirejs-config.js in Magento.

    requirejs-config.js is a key configuration file used to manage Magento's JavaScript modules through RequireJS, a JavaScript module loader that supports asynchronous loading, dependency resolution, and modular programming.

    Main Purposes of requirejs-config.js:

    1. Map Custom JS Paths

    You can remap default JS modules to custom ones.

    var config = {
        map: {
            '*': {
                customScript: 'Vendor_Module/js/custom-script'
            }
        }
    };
    

    This allows swapping Magento core JS with customized JS files without touching core code.

    2. Configure Shims

    Shim configurations allow you to use non-AMD libraries like jQuery plugins by defining:

    • Dependencies
    • Exported global variables

    Example:

    var config = {
        shim: {
            'custom/lib': {
                deps: ['jquery']
            }
        }
    };
    

    3. Mixins

    Mixins allow modifying JS modules without overriding them.

    var config = {
        config: {
            mixins: {
                'Magento_Checkout/js/view/shipping': {
                    'Vendor_Module/js/shipping-mixin': true
                }
            }
        }
    };
    

    4. Path Aliases

    Shorten and organize paths to JS resources.

    Where It Is Located?

    • app/code/Vendor/Module/view/frontend/requirejs-config.js
    • app/design/frontend/Vendor/theme/requirejs-config.js

    Why RequireJS Is Important in Magento?

    • Improves performance via async loading
    • Avoids JS conflicts
    • Helps implement modular and maintainable JavaScript architecture

    requirejs-config.js is essential for custom frontend JS development.

    12. How do you override a controller in Magento 2?

    Overriding a controller is done using a preference or plugin, but the recommended way is controller rewriting via dependency injection.

    Steps to Override a Controller:

    1. Create a Custom Module

    Example: Vendor/Module.

    2. Create Your Custom Controller

    Path:

    Vendor/Module/Controller/Checkout/Cart/Add.php
    

    This class must extend the original class:

    class Add extends \Magento\Checkout\Controller\Cart\Add
    {
        public function execute()
        {
            // custom logic
            return parent::execute();
        }
    }
    

    3. Define Preference in di.xml

    Located in:

    etc/frontend/di.xml
    

    Example:

    <preference for="Magento\Checkout\Controller\Cart\Add"
                type="Vendor\Module\Controller\Checkout\Cart\Add" />
    

    Alternative: Using Plugins

    This is recommended when modifying method behavior without rewriting entire controller logic.

    Key Notes:

    • Use controller overrides sparingly.
    • A preference means replacing the entire class → risk of conflicts.
    • Plugins allow safer, more modular customization.

    13. How do you override a model in Magento 2?

    Model overriding is typically done using preferences or plugins depending on the requirement.

    Method 1: Override Using Preference

    Use when replacing the entire model logic.

    Step 1: Create your custom model class.

    Vendor/Module/Model/Product.php
    

    Extend Magento’s core Product model:

    class Product extends \Magento\Catalog\Model\Product
    {
        public function getSpecialPrice()
        {
            // custom logic
        }
    }
    

    Step 2: Add preference in di.xml

    <preference for="Magento\Catalog\Model\Product"
                type="Vendor\Module\Model\Product" />
    

    Method 2: Override Using Plugins

    Preferred for modifying only certain methods.

    Example:

    <type name="Magento\Catalog\Model\Product">
        <plugin name="custom_price_plugin"
                type="Vendor\Module\Plugin\Product" />
    </type>
    

    Plugins allow modifying:

    • Arguments
    • Return values
    • Entire method execution

    without rewriting the whole model.

    14. How do you override a block or helper?

    Overriding a block or helper is similar to overriding models, using preferences.

    Override Block Example:

    Step 1: Create your custom block:

    Vendor/Module/Block/Product/View.php
    

    class View extends \Magento\Catalog\Block\Product\View
    {
        public function getMyCustomData()
        {
            return "Custom block logic here";
        }
    }
    

    Step 2: Define preference in di.xml

    <preference for="Magento\Catalog\Block\Product\View"
                type="Vendor\Module\Block\Product\View" />
    

    Override Helper Example:

    Magento helpers are in Helper/Data.php.

    Create custom helper:

    class Data extends \Magento\Catalog\Helper\Data
    {
        public function customFunction()
        {
            return 'Hello';
        }
    }
    

    Add preference:

    <preference for="Magento\Catalog\Helper\Data"
                type="Vendor\Module\Helper\Data" />
    

    Best Practice:

    Use plugins instead of overriding blocks or helpers unless necessary.

    15. What is an extension attribute?

    Extension attributes allow developers to extend Magento’s data objects (entities) without modifying the core database structure.

    These are defined in:

    etc/extension_attributes.xml
    

    Why Extension Attributes?

    • Add additional information to API data models
    • Make your custom attributes visible in REST/SOAP
    • Attach related data not originally part of the entity

    Examples:

    • Adding warehouse data to the product object
    • Adding extra order metadata from external systems
    • Adding a customer's loyalty points balance

    How Extension Attributes Work?

    1. Define extension attribute
    2. Create getter and setter
    3. Modify repository to load/save the extra data

    Difference from Custom Attributes:

    FeatureExtension AttributeCustom AttributeDefined inextension_attributes.xmleav_attributes or db columnsPurposeAdd non-EAV metadata to APIAdd EAV field to entityVisible in APIYesYes (if configured)StorageCustom tablesEAV or flat

    Extension attributes are mainly used for module-to-module communication and API expansion.

    16. What is a custom attribute and how to add it?

    A custom attribute is an attribute added to:

    • Products
    • Customers
    • Categories
    • Orders

    Custom attributes are usually EAV-based.

    Ways to Add Custom Attributes:

    1. Using Data Patch

    Create a file:

    Setup/Patch/Data/AddCustomAttribute.php
    

    Example for product attribute:

    $eavSetup->addAttribute(
        \Magento\Catalog\Model\Product::ENTITY,
        'custom_attribute',
        [
            'type' => 'varchar',
            'label' => 'Custom Attribute',
            'input' => 'text',
            'required' => false,
            'visible' => true
        ]
    );
    

    2. Using Admin Panel for Product Attributes

    Stores → Attributes → Product → Add New Attribute

    Why Custom Attributes Are Used?

    • Add product specifications
    • Customer metadata like GST number
    • Integrations with ERP/CRM
    • Improve layered navigation

    Custom attributes give Magento its flexible, dynamic catalog structure.

    17. What is the purpose of etc/adminhtml/system.xml?

    system.xml defines admin configuration settings shown in:

    Stores → Configuration

    Main Uses:

    1. Create admin configuration sections, groups, and fields
    2. Store system configuration values
    3. Expose module settings to admin users
    4. Allow enabling/disabling features
    5. Enter API keys, tokens, credentials
    6. Set default values for modules

    Example Fields it Defines:

    • API keys
    • Email templates
    • Feature toggles
    • Payment method configurations
    • Cron settings
    • Logging switches

    system.xml is the backbone of module configuration management.

    18. How do you create custom admin configuration fields?

    Use system.xml to declare settings fields.

    Steps:

    1. Create system.xml

    app/code/Vendor/Module/etc/adminhtml/system.xml
    

    Example:

    <section id="vendor_section">
        <group id="general" label="General Settings">
            <field id="enabled" type="select" label="Enable Module">
                <source_model>Magento\Config\Model\Config\Source\Yesno</source_model>
            </field>
            <field id="api_key" type="text" label="API Key" />
        </group>
    </section>
    

    2. Access Values in Code

    $this->scopeConfig->getValue('vendor_section/general/api_key');
    

    3. Optional: Create Backend Models

    To validate or preprocess field values.

    4. Optional: Add Custom Field Types

    Custom renderers can create:

    • Color pickers
    • Date fields
    • Image uploads
    • Multi-select lists

    Purpose:

    • Gives admin users easy configuration options
    • Avoids hardcoding values
    • Makes module flexible and user-friendly

    19. Explain how Magento handles checkout flow.

    Magento checkout is powered by:

    • Knockout.js view models
    • UI components
    • REST API calls
    • Quote object

    Checkout Stages:

    1. Cart Page

    Customer reviews product selections.

    2. Checkout Initiation

    Magento loads:

    • Shipping step
    • Payment step
    • Review step

    3. Shipping Information

    Customer enters:

    • Address
    • Shipping method

    Magento uses shipping providers to calculate rates.

    4. Payment Information

    Magento loads available payment methods dynamically.

    5. Place Order

    On clicking "Place Order":

    • Payment is processed
    • Quote is converted to Order object
    • Order details stored in database

    6. Order Confirmation

    Customer sees success page, order email is triggered.

    Key Components:

    LayerTechnologyFrontendKnockout.js / UI ComponentsBackendQuote, Totals Collectors, Payment Gateway AdaptersDBEAV + flat order tables

    Magento checkout is highly extensible using plugins, observers, and checkout UI components.

    20. What is the role of quote and order objects?

    Quote Object (Pre-order data)

    The quote stores shopping cart data before the order is placed.

    Quote Contains:

    • Cart items
    • Shipping address
    • Billing address
    • Totals (subtotal, tax, shipping)
    • Payment method
    • Coupons / discounts

    Role:

    • Used during checkout calculations
    • Stores temporary data
    • Supports multi-step checkout
    • Tracks customer selections

    Quote is stored in the database as quote and associated tables.

    Order Object (Finalized purchase data)

    Once the customer confirms checkout, the quote is converted into an order.

    Order Contains:

    • Final product list
    • Prices and totals
    • Shipping & billing details
    • Payment status
    • Sales transactions
    • Invoices
    • Shipments
    • Credit memos

    Role:

    • Immutable record of the purchase
    • Used for fulfillment and reporting
    • Supports invoicing, shipping, refunds

    Key Differences

    FeatureQuoteOrderStatusTemporaryFinalEditableYesLimitedPurposeCheckout calculationsFulfillment & historyTablesquote_*sales_order_*

    Quote → Order conversion is the core logic of Magento checkout.

    21. Explain Magento pricing architecture.

    Magento’s pricing architecture is a layered, modular, and extensible system designed to calculate product prices dynamically based on various rules, catalog settings, cart conditions, customer groups, and currency configurations.

    Core Components of Pricing Architecture

    1. Price Models

    Magento uses dedicated price model classes such as:

    • CatalogProduct\Type\Price
    • BundleProduct\Type\Price
    • ConfigurableProduct\Price

    Each product type has its own logic for calculating final price.

    2. Price Types

    Magento supports multiple price types:

    • Regular Price
    • Special Price
    • Tier Price
    • Group Price
    • Final Price (after applying all rules)

    The final price is the result of applying all pricing rules and adjustments.

    3. Price Collectors

    Magento’s totals collectors apply transformations to the price:

    • Tax calculation
    • Discount rules
    • Tier price rules
    • Customer group pricing
    • Currency conversion

    Collectors run in a specific order during quote and checkout processing.

    4. Catalog Price Rules

    Configured in admin, rules apply promotional discounts before items enter cart.

    5. Cart Price Rules

    Apply at cart level, implementing:

    • Coupon codes
    • Buy X get Y
    • Percentage discounts
    • Free shipping

    6. Repositories and APIs

    Product repository returns price data including:

    • Minimum price
    • Maximum price (configurables)
    • Custom options price adjustments

    7. Indexing

    Price indexes flatten price data for fast lookup.

    Example index: catalog_product_index_price

    Purpose of Magento Pricing Architecture

    • Support dynamic, rule-based pricing
    • Enable per-customer, per-website price variations
    • Improve performance using indexing
    • Simplify third-party pricing integrations

    Magento’s pricing system is one of the most flexible in the eCommerce industry.

    22. What is storefront rendering process?

    Magento’s storefront rendering process converts backend data (products, categories, CMS blocks) into a fully structured HTML page shown to customers.

    Steps in Storefront Rendering:

    1. URL → Routing → Controller

    Magento resolves the route and identifies which controller should serve the request.

    2. Load Layout XML

    Magento merges layout XML files from:

    • Core modules
    • Themes
    • Custom modules

    Handles such as:

    • catalog_product_view
    • cms_index_index

    define blocks and containers.

    3. Blocks Execution

    Magento instantiates block classes defined in layout XML:

    • Blocks prepare data
    • Blocks fetch models, helpers, configuration
    • Blocks pass data to templates

    4. Templates Rendering

    Each block is linked to a .phtml template that outputs HTML.

    5. Static Assets Loading

    Static files (CSS, JS, fonts, images) are loaded from:

    pub/static/
    

    Using RequireJS for JS dependency management.

    6. Combine, Minify, Bundle (If Enabled)

    Magento can optimize frontend performance by:

    • Minimizing JS & CSS
    • Bundling scripts
    • Using HTTP/2 multiplexing

    7. Full Page Cache (FPC)

    If FPC is enabled, cached HTML is returned, skipping rendering steps.

    8. Response Sent to Browser

    Final page is sent to the user.

    Why Storefront Rendering Is Important?

    • Defines how Magento builds pages dynamically
    • Provides extension points via layout XML, blocks, templates
    • Plays a key role in site performance

    23. Explain GraphQL implementation in Magento.

    Magento introduced GraphQL to power Headless Commerce scenarios, enabling progressive web apps (PWAs) like PWA Studio.

    GraphQL Architecture in Magento

    1. Schema Definition

    GraphQL schema files define:

    • Queries
    • Mutations
    • Types
    • Input objects

    Located in:

    etc/schema.graphqls
    

    2. Resolvers

    Resolvers are PHP classes that return data requested by GraphQL queries.

    Magento provides:

    • Query resolvers
    • Mutation resolvers
    • Nested field resolvers

    3. Schema Generation

    Magento compiles GraphQL schema into executable schema using:

    bin/magento dev:urn-catalog:generate
    

    4. Authentication

    GraphQL supports:

    • Customer token
    • Admin token
    • Guest operations (limited)

    Example mutation to generate customer token:

    mutation {
      generateCustomerToken(email: "test@mail.com", password: "Pass123") {
        token
      }
    }
    

    5. Extensibility

    Modules can add:

    • New queries
    • New mutations
    • Custom resolvers
    • Custom object types

    Benefits of GraphQL in Magento

    • Fetches only required data → faster frontend
    • Reduces API over-fetching/under-fetching
    • Ideal for building PWAs, mobile apps, SPAs
    • Fully extendable architecture

    Magento’s GraphQL layer is now the recommended API for headless storefronts.

    24. What is the REST API in Magento and how do you authenticate?

    Magento’s REST API provides a standardized way to integrate third-party applications such as ERP, CRM, PIM, or mobile apps.

    Types of API Authentication:

    1. Token-Based Authentication

    Customer Token

    Generated via:
    POST /V1/integration/customer/token

    This returns a JWT token used in subsequent API calls.

    Example header:

    Authorization: Bearer <token>
    

    Admin Token

    Generated via:
    POST /V1/integration/admin/token

    Used for administrative API operations.

    2. OAuth 1.0a Authentication

    For secure integrations where token generation is not preferred.

    Requires:

    • Consumer key
    • Consumer secret
    • Access token
    • Access token secret

    3. Guest Access

    Some APIs allow guest operations (e.g., retrieving products).

    Common REST Endpoints

    PurposeEndpoint ExampleProducts/V1/productsCategories/V1/categoriesOrders/V1/ordersCustomers/V1/customers

    REST API Benefits

    • Simple to implement
    • Highly extendable
    • Secure authentication
    • Excellent for backend integrations

    25. What is OAuth in Magento API?

    OAuth 1.0a is a secure authorization protocol used for API authentication without exposing user credentials.

    Why Magento Uses OAuth?

    • Works well for server-to-server communication
    • No need for username/password exchange
    • Ensures strong cryptographic validation
    • Used for integrations with enterprise systems

    OAuth Steps in Magento:

    1. Generate consumer key and secret
      (Admin → System → Extensions → Integrations)
    2. Request token from Magento
    3. Authorize access
    4. Receive access token and secret
    5. Use signed OAuth request to access API endpoints

    Purpose of OAuth:

    • Authentication for integrations
    • Protect sensitive operations like order management
    • Provide controlled access level scopes

    OAuth is secure, scalable, and suitable for enterprise-grade integrations.

    26. How to create custom API endpoints?

    Magento allows creating custom REST and GraphQL endpoints via module-level API definitions.

    Steps to Create Custom REST API Endpoint:

    1. Create API Interface

    Api/CustomManagementInterface.php
    

    2. Implement Interface

    Model/CustomManagement.php
    

    3. Define Web API Route

    etc/webapi.xml:

    <route url="/V1/custom/endpoint" method="POST">
        <service class="Vendor\Module\Api\CustomManagementInterface" method="process"/>
        <resources>
            <resource ref="anonymous"/>
        </resources>
    </route>
    

    4. Add DI Preference

    <preference for="Vendor\Module\Api\CustomManagementInterface"
                type="Vendor\Module\Model\CustomManagement" />
    

    5. Clear Cache and Test API

    Using Postman or cURL.

    Why Custom APIs Are Important?

    • Integrate external systems
    • Provide custom business logic
    • Extend Magento data models
    • Build mobile applications

    27. What is the role of Varnish in Magento?

    Varnish is a high-performance HTTP accelerator used as a Full Page Cache (FPC) for Magento.

    Why Magento Uses Varnish?

    1. Huge Performance Improvement

    Varnish can serve cached pages 10–20x faster than PHP.

    2. Reduces Server Load

    Offloads HTML rendering from Magento’s backend.

    3. Edge Side Includes (ESI)

    Supports partial caching of dynamic blocks (minicart, wishlist count).

    How It Works:

    1. First request hits Magento → page is rendered → stored in Varnish
    2. Subsequent requests served directly from Varnish cache
    3. Magento invalidates cache when data changes:
    • Product update
    • Category change
    • Pricing rule changes

    Key Concepts:

    • VCL (Varnish Configuration Language)
    • FPC invalidation
    • Cache tags (Magento sends tags for fine-grained invalidation)

    Benefits:

    • Faster page loading
    • Increased scalability
    • Reduced CPU and memory usage

    Varnish is strongly recommended for production deployments.

    28. How do you configure Redis in Magento?

    Redis is used in Magento for:

    • Default cache
    • Full page cache
    • Session storage

    Configuration is done in env.php:

    1. Redis as Cache Backend

    'cache' => [
        'frontend' => [
            'default' => [
                'backend' => 'Cm_Cache_Backend_Redis',
                'backend_options' => [
                    'server' => '127.0.0.1',
                    'port' => '6379',
                    'database' => '0'
                ]
            ]
        ]
    ]
    

    2. Redis for Full Page Cache

    'page_cache' => [
        'backend' => 'Cm_Cache_Backend_Redis',
        'backend_options' => [
            'server' => '127.0.0.1',
            'port' => '6379',
            'database' => '1'
        ]
    ]
    

    3. Redis for Sessions

    'session' => [
        'save' => 'redis',
        'redis' => [
            'host' => '127.0.0.1',
            'port' => '6379',
            'db' => '2'
        ]
    ]
    

    Benefits of Redis in Magento:

    • Extremely fast in-memory storage
    • Supports tagging and advanced eviction
    • Highly scalable and stable
    • Ideal for large, high-traffic stores

    Redis dramatically improves Magento’s performance.

    29. What is full page cache and how does it work?

    Full Page Cache (FPC) stores the entire rendered HTML output of pages so Magento doesn’t need to rebuild it for each request.

    How It Works:

    1. First request → Magento builds page → stores it in cache
    2. Second request → Cache serves HTML in milliseconds
    3. Cache invalidation happens based on:
    • Product update
    • Category change
    • Price rule updates
    • CMS changes

    FPC Storage Options:

    • Built-in file cache
    • Redis (recommended)
    • Varnish (best performance)

    Block Caching and Hole Punching

    Magento supports hole punching using:

    • Private content via Knockout.js
    • Customer data sections
    • Varnish ESI blocks

    Benefits:

    • Reduces TTFB (Time to First Byte) dramatically
    • Supports thousands of concurrent users
    • Minimizes database and PHP workload

    FPC is essential for achieving high-speed Magento performance.

    30. Explain Magento logging mechanism.

    Magento uses PSR-3 compliant logging based on Monolog.

    Log Structure

    Magento writes logs into:

    var/log/
    

    Examples:

    • system.log
    • exception.log
    • Custom module logs

    How to Use Logging in Custom Code:

    Inject logger:

    public function __construct(
        \Psr\Log\LoggerInterface $logger
    ) {
        $this->logger = $logger;
    }
    

    Log messages:

    $this->logger->info('Informational message.');
    $this->logger->error('Error occurred.');
    

    Custom Log Files

    You can define a custom logger channel via di.xml.

    Error Logging

    Magento automatically logs:

    • Exceptions
    • Cron failures
    • API errors
    • Plugin failures
    • DB errors

    Benefits of Magento Logging:

    • Helps debug issues
    • Tracks system health
    • Records business-critical events
    • Essential for production monitoring

    Magento's logging framework integrates deeply with its modular structure for powerful diagnostics.

    WeCP Team
    Team @WeCP
    WeCP is a leading talent assessment platform that helps companies streamline their recruitment and L&D process by evaluating candidates' skills through tailored assessments