Laravel interview concepts and question bank

An interviewer shows you a loop over ten batches that prints each batch’s teacher, and asks how many SQL queries it sends. Run on Laravel 13.34.0, that loop sent 11, and the same loop with with('teacher') sent 2: a number you can predict, explain and then prove is the strongest answer you can give.

This lesson trains that kind of answer on six topics: the shape of a strong answer, the service container and facades, middleware, queries, transactions with queued jobs, and security. Each section shows a short program first, so you can write down your prediction, and then the output it printed when it ran. The questions at the end are original and graded by level.

A strong answer names the mechanism and how it fails

Take the question “What is a facade?”. A common reply is “a static class you call with ::”, and the next question exposes it: if it is static, how do you swap it for a fake in a test? The reply describes the syntax, not the thing.

A strong answer has four parts, and a fifth that you bring with you:

1. A definition in one exact sentence.
2. The mechanism: the class or method that does it in Laravel, by name.
3. One trade-off: what the choice costs, and when you would choose otherwise.
4. A failure mode: how it breaks, and how you would see it break.
5. The proof: a run or a test whose output shows the claim.

Step through the facade answer built this way. Each step adds what the reply above lacked:

The first four parts can come from any page of the documentation, and the proof is what you bring. Each section below gives you one: a probe of a few lines whose output you can quote. The container probe in the next section supplied the facade answer’s failure mode and its proof, so you can check both lines yourself.

What the container returns: bind, singleton and scoped

Ask the service containerservice container: The object that builds and stores the classes an application needs. Laravel's application object is the container, and providers put their bindings into it. More in “How Laravel handles a request” for the same thing twice, and what you get back depends on how it was registered. The probe below registers one small class three ways, asks for each twice, and then starts a new lifecycle the way a queue worker does before each job. Write down your prediction for every line before you read the run:

<?php

// Predict the output: what Laravel's service container hands back when you ask for the same thing
// twice. spl_object_id() names an object, so equal ids mean one object. The first line calls a facade
// before the application exists. Run:  php container.php
use Illuminate\Contracts\Console\Kernel;
use Illuminate\Support\Facades\Cache;

require __DIR__.'/vendor/autoload.php';

function show(string $case, string $result): void
{
    printf("%-34s %s\n", $case, $result);
}

function same(object $a, object $b): string
{
    return spl_object_id($a) === spl_object_id($b) ? 'same object' : 'two objects';
}

// 1. A facade with no application behind it yet.
try {
    Cache::get('fee-total');
} catch (RuntimeException $e) {
    show('Cache::get() before the app boots:', $e->getMessage());
}

$app = require __DIR__.'/bootstrap/app.php';
$app->make(Kernel::class)->bootstrap();

// A class with no constructor arguments, so the container can build it without being told how.
class FeeCalculator {}

$app->bind('fees.bind', fn () => new FeeCalculator);
$app->singleton('fees.singleton', fn () => new FeeCalculator);
$app->scoped('fees.scoped', fn () => new FeeCalculator);

// 2-4. Ask for each binding twice.
show('make() of a class, no binding:', same($app->make(FeeCalculator::class), $app->make(FeeCalculator::class)));
show('bind(), asked twice:', same($app->make('fees.bind'), $app->make('fees.bind')));
show('singleton(), asked twice:', same($app->make('fees.singleton'), $app->make('fees.singleton')));

// 5-6. A new lifecycle: what a queue worker does before each job, and Octane before each request.
$scoped = $app->make('fees.scoped');
$single = $app->make('fees.singleton');
show('scoped(), same lifecycle:', same($scoped, $app->make('fees.scoped')));
$app->forgetScopedInstances();
show('scoped(), next lifecycle:', same($scoped, $app->make('fees.scoped')));
show('singleton(), next lifecycle:', same($single, $app->make('fees.singleton')));

// 7. A facade is a static-looking front for one object in the container.
show('Cache facade vs app(\'cache\'):', same(Cache::getFacadeRoot(), $app->make('cache')));
show('the object behind the facade:', get_class(Cache::getFacadeRoot()));

from session import run

# Asks the service container for the same thing twice under each kind of binding, and calls a facade before
# and after the application boots. The overlay carries the probe; nothing secret is printed.
run(
    """
php container.php
""",
    app=True,
    overlay=("predict",),
)

$ php container.php
Cache::get() before the app boots: A facade root has not been set.
make() of a class, no binding:     two objects
bind(), asked twice:               two objects
singleton(), asked twice:          same object
scoped(), same lifecycle:          same object
scoped(), next lifecycle:          two objects
singleton(), next lifecycle:       same object
Cache facade vs app('cache'):      same object
the object behind the facade:      Illuminate\Cache\CacheManager

Read the lines in pairs. bind(), and a class with no binding at all, built a new object on every make(). A singletonsingleton: A binding whose object is built the first time something asks for it and then shared until the process ends, registered with singleton() or the #[Singleton] attribute. In a queue worker every job of the worker shares it. More in “The service container and dependency injection” was built once and returned again, even after the new lifecycle. A scopedscoped instance: An object the container shares within one request or one queued job and drops before the next one, registered with scoped() or the #[Scoped] attribute. Queue workers and Octane reset these between units of work. More in “The service container and dependency injection” binding was shared within one lifecycle, and forgetScopedInstances() dropped it, so the next lifecycle got a new object. The queue worker calls that method before every job, and the container documentation says scoped instances are flushed when an Octane worker starts a new request.

The difference shows in an interview the moment the process lives longer than a request. Under PHP-FPMPHP-FPM: PHP's FastCGI Process Manager: a service that keeps a pool of PHP processes running, takes each request from the web server over FastCGI, runs the script and returns the response. More in “Deploying Laravel to a Linux server” each request boots a new application, so a singleton lasts one request and the bug stays hidden. A queue worker runs job after job in one booted application, so a singleton that keeps the current user, centre or locale in a property hands it to the next job. Laravel OctaneLaravel Octane: A first-party package that serves a Laravel application from a long-running server such as FrankenPHP, Swoole or RoadRunner. The application boots once and stays in memory between requests, so state kept in a singleton carries over to the next request. also keeps the booted application in memory between requests, so a singleton can carry such state into a later request there as well.

The last two lines are the facade answer’s proof: Cache::getFacadeRoot() and app('cache') were one CacheManager, which is what a facadefacade: A class that names one entry of Laravel's container and forwards every static call on it to the object stored there, as Cache::get() forwards to the cache manager. More in “Service providers, facades and contracts” is, a static-looking front for one object in the container. The first line was its failure mode, the facade called before any application existed.

Middleware wrap the controller: in, then out in reverse

A route lists two middlewaremiddleware: A class that sits between the web server and the controller. It can inspect or change a request, stop it with its own response, or pass it inward and then change the response on the way out. More in “How Laravel handles a request”, Outer and then Inner. Each prints one line before it calls $next($request) and another after it, and Outer also has a terminate() method. The probe sends two requests through the real HTTP kernelHTTP kernel: The class that runs a web request from start to finish: it boots the framework, sends the request through the middleware and the router, and returns a response. More in “How Laravel handles a request”, and the second asks for a closed report, which Inner refuses. Predict both sets of lines:

<?php

namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;
use Symfony\Component\HttpFoundation\Response;

// The first route middleware of the probe. It prints a line before it passes the request on, a line
// when the response comes back, and a third from terminate(), which runs after the response is sent.
class Outer
{
    public function handle(Request $request, Closure $next): Response
    {
        echo "Outer: on the way in\n";
        $response = $next($request);
        echo "Outer: on the way out, status {$response->getStatusCode()}\n";

        return $response;
    }

    public function terminate(Request $request, Response $response): void
    {
        echo "Outer: terminate(), after the response\n";
    }
}

<?php

namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;
use Symfony\Component\HttpFoundation\Response;

// The second route middleware of the probe. When the request asks for a closed report it answers
// 403 itself and never calls $next, so the controller does not run.
class Inner
{
    public function handle(Request $request, Closure $next): Response
    {
        if ($request->boolean('closed')) {
            echo "Inner: answers 403 itself, never calls \$next\n";

            return response('this report is closed', 403);
        }

        echo "Inner: on the way in\n";
        $response = $next($request);
        echo "Inner: on the way out\n";

        return $response;
    }
}

<?php

use App\Http\Middleware\Inner;
use App\Http\Middleware\Outer;
use Illuminate\Support\Facades\Route;

// Two routes for the predict-the-output probes. /report runs two route middleware in the order they
// are listed; /notices is a plain POST route inside the default web group, so the request-forgery
// check runs on it exactly as it would on a form.
Route::get('/report', function () {
    echo "Controller: builds the response\n";

    return response('the fee report');
})->middleware([Outer::class, Inner::class]);

Route::post('/notices', fn () => response('a notice was posted'));

<?php

// Predict the output: two requests through the real HTTP kernel to a route with two middleware,
// Outer and Inner, listed in that order. The second request asks for a closed report, which Inner
// refuses. terminate() is called the way public/index.php calls it, after the response. Run:  php middleware.php
use Illuminate\Contracts\Http\Kernel;
use Illuminate\Http\Request;

require __DIR__.'/vendor/autoload.php';
$app = require __DIR__.'/bootstrap/app.php';
$kernel = $app->make(Kernel::class);

foreach (['/report', '/report?closed=1'] as $uri) {
    echo "--- GET {$uri}\n";
    $request = Request::create($uri, 'GET');
    $response = $kernel->handle($request);
    echo "Kernel: handle() returned {$response->getStatusCode()}\n";
    $kernel->terminate($request, $response);
}

from session import run

# Sends two requests through the real HTTP kernel to a route with two middleware and prints the order in
# which each layer and the controller ran. The overlay carries the probe, the two middleware and the routes.
run(
    """
php middleware.php
""",
    app=True,
    overlay=("predict",),
)

$ php middleware.php
--- GET /report
Outer: on the way in
Inner: on the way in
Controller: builds the response
Inner: on the way out
Outer: on the way out, status 200
Kernel: handle() returned 200
Outer: terminate(), after the response
--- GET /report?closed=1
Outer: on the way in
Inner: answers 403 itself, never calls $next
Outer: on the way out, status 403
Kernel: handle() returned 403
Outer: terminate(), after the response

The code before $next ran in the order the route lists, and the code after it ran in reverse, because each middleware wraps the ones listed after it. For the closed report, Inner returned its own 403 without calling $next: the controller never ran and Inner had no way out to print, yet Outer still printed the 403 on its way out. Step through both requests:

terminate() ran last, after handle() had returned, because the kernel calls it once the response has been sent; the middleware documentation adds that with FastCGI the browser already has the response by then. The probe is the request lifecyclerequest lifecycle: The path one request takes through an application: the front controller, the kernel, the middleware, the router and the controller, then the response and the work that runs after it. More in “How Laravel handles a request” in miniature. public/index.php loads the application from bootstrap/app.php, and the kernel bootstraps it: configuration, error handling and logging, then every service provider’s register() and, once all are registered, each one’s boot(). Global middleware run next, the router picks the route, and its group and route middleware run around the controller. The response travels back out through the same layers before it is sent and terminated.

Counting queries: 11 for the lazy loop, 2 with eager loading

Here is the opening’s question, run. The probe makes ten batches with one teacher each, sends the same loop four ways and then switches lazy loading off. The query logquery log: A record of every SQL statement a connection ran during a request, with its text, bindings and time. Laravel's DB::enableQueryLog() collects it, DB::getQueryLog() returns it, DB::listen() watches each one. More in “Databases and the query builder” records every statement, so its length is the count. Predict each number before you read it:

<?php

// Predict the output: how many SQL statements each version of one loop sends for ten batches and
// their teachers. The query log records every statement Eloquent sends, so its length is the count.
// Run:  php queries.php
use Illuminate\Contracts\Console\Kernel;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\LazyLoadingViolationException;
use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Schema;

require __DIR__.'/vendor/autoload.php';
$app = require __DIR__.'/bootstrap/app.php';
$app->make(Kernel::class)->bootstrap();

class Teacher extends Model
{
    public $timestamps = false;
}

class Batch extends Model
{
    public $timestamps = false;

    public function teacher()
    {
        return $this->belongsTo(Teacher::class);
    }
}

Schema::create('teachers', function ($table) {
    $table->id();
    $table->string('name');
});
Schema::create('batches', function ($table) {
    $table->id();
    $table->string('name');
    $table->foreignId('teacher_id');
});
foreach (range(1, 10) as $i) {
    DB::table('teachers')->insert(['name' => "Teacher {$i}"]);
    DB::table('batches')->insert(['name' => "Batch {$i}", 'teacher_id' => $i]);
}

// Run some work and return how many statements it sent.
function queries(callable $work): int
{
    DB::flushQueryLog();
    DB::enableQueryLog();
    $work();
    DB::disableQueryLog();

    return count(DB::getQueryLog());
}

function show(string $case, string $result): void
{
    printf("%-44s %s\n", $case, $result);
}

$names = fn ($batches) => $batches->map(fn ($batch) => $batch->teacher->name)->all();

show('1. Batch::all(), then each ->teacher', queries(fn () => $names(Batch::all())).' queries');
show('2. Batch::with(\'teacher\')->get()', queries(fn () => $names(Batch::with('teacher')->get())).' queries');
show('3. Batch::all()->load(\'teacher\')', queries(fn () => $names(Batch::all()->load('teacher'))).' queries');

Model::automaticallyEagerLoadRelationships();
show('4. Batch::all(), automatic eager loading on', queries(fn () => $names(Batch::all())).' queries');
Model::automaticallyEagerLoadRelationships(false);

// What AppServiceProvider::boot() does with Model::preventLazyLoading(! app()->isProduction()).
Model::preventLazyLoading();
try {
    $names(Batch::all());
    show('5. lazy loading prevented, ten batches', 'no exception');
} catch (LazyLoadingViolationException $e) {
    show('5. lazy loading prevented, ten batches', class_basename($e));
    echo '   '.$e->getMessage()."\n";
}
show('6. lazy loading prevented, Batch::find(1)', queries(fn () => Batch::find(1)->teacher->name).' queries, no exception');

from session import run

# Counts the SQL statements four versions of one loop send for ten batches and their teachers, then turns
# lazy loading off. The overlay carries the probe; it makes its own two tables in the project's SQLite file.
run(
    """
php queries.php
""",
    app=True,
    overlay=("predict",),
)

$ php queries.php
1. Batch::all(), then each ->teacher         11 queries
2. Batch::with('teacher')->get()             2 queries
3. Batch::all()->load('teacher')             2 queries
4. Batch::all(), automatic eager loading on  2 queries
5. lazy loading prevented, ten batches       LazyLoadingViolationException
   Attempted to lazy load [teacher] on model [Batch] but lazy loading is disabled.
6. lazy loading prevented, Batch::find(1)    2 queries, no exception

The first loop is the N+1 patternN+1 query problem: A page that sends one query for a list and then one more for every row of it, usually by reading a relationship inside a loop, so its query count is 1 + N and grows with the data. More in “Eager loading and the N+1 query problem”: one query for the batches and one for each batch’s teacher, 1 + 10 = 11, a count that grows with the data. Eager loadingeager loading: Loading a relationship for a whole set of models at once, before the code reads it: with('student') sends one extra query with an IN list of keys and matches the rows in memory. More in “Eager loading and the N+1 query problem” with with('teacher') sent 2, the batches and then one query for every teacher whose id is in the list. load('teacher') did the same after the batches were already in memory, and automatic eager loadingautomatic eager loading: Laravel's mode, switched on with Model::automaticallyEagerLoadRelationships(), that loads a relationship for a whole collection the first time one of its models reads it lazily. More in “Eager loading and the N+1 query problem” reached the same 2 without any change to the loop.

Line 5 is the guard. With Model::preventLazyLoading() on, the lazy loop threw LazyLoadingViolationException at its first lazy read. Line 6 is the detail that lifts an answer above the definition: Batch::find(1)->teacher loaded lazily and threw nothing. In Laravel 13.34.0, Eloquent marks models for the check only when a query returns more than one of them, because a single lazy load cannot multiply.

Transactions and queued jobs: what survives a rollback

A fee payment is saved inside DB::transaction(), and a job that sends the receipt is dispatched in the same closure. Then the gateway times out and the closure throws. The probe runs this three ways on the sync queue, which runs a job the moment it is dispatched, the earliest a real worker could take it:

<?php

// Predict the output: a fee payment saved inside a database transaction that fails, and a receipt
// job dispatched inside it, first as a plain dispatch and then with afterCommit(). The queue is the
// sync driver here: it runs a job the moment it is dispatched, the earliest a real worker could pick
// it up. Run:  php transactions.php
use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Console\Kernel;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Bus\Dispatchable;
use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Schema;

require __DIR__.'/vendor/autoload.php';
$app = require __DIR__.'/bootstrap/app.php';
$app->make(Kernel::class)->bootstrap();
config(['queue.default' => 'sync']);

class SendReceipt implements ShouldQueue
{
    use Dispatchable, Queueable;

    public static int $sent = 0;

    public function __construct(public int $paymentId) {}

    public function handle(): void
    {
        self::$sent++;
        $row = DB::table('payments')->where('id', $this->paymentId)->exists() ? 'exists' : 'is missing';
        echo "   job ran: receipt for payment {$this->paymentId}, the payment row {$row}\n";
    }
}

Schema::create('payments', function ($table) {
    $table->id();
    $table->unsignedInteger('paise');
});

// Run one payment attempt; $fail makes it throw after the insert and the dispatch, as a gateway timeout would.
function attempt(string $case, bool $afterCommit, bool $fail): void
{
    echo "{$case}\n";
    SendReceipt::$sent = 0;
    try {
        DB::transaction(function () use ($afterCommit, $fail) {
            $id = DB::table('payments')->insertGetId(['paise' => 150000]);
            $afterCommit ? SendReceipt::dispatch($id)->afterCommit() : SendReceipt::dispatch($id);
            if ($fail) {
                throw new RuntimeException('gateway timeout');
            }
        });
    } catch (RuntimeException $e) {
        echo "   transaction rolled back: {$e->getMessage()}\n";
    }
    printf("   payments in the table: %d, receipts sent: %d\n", DB::table('payments')->count(), SendReceipt::$sent);
    DB::table('payments')->delete();
}

attempt('1. dispatch() inside, then the transaction fails', afterCommit: false, fail: true);
attempt('2. dispatch()->afterCommit() inside, then it fails', afterCommit: true, fail: true);
attempt('3. dispatch()->afterCommit() inside, and it commits', afterCommit: true, fail: false);

from session import run

# Saves a payment inside a transaction that fails and dispatches a receipt job inside it, with and without
# afterCommit(), on the sync queue. The overlay carries the probe; it makes its own table.
run(
    """
php transactions.php
""",
    app=True,
    overlay=("predict",),
)

$ php transactions.php
1. dispatch() inside, then the transaction fails
   job ran: receipt for payment 1, the payment row exists
   transaction rolled back: gateway timeout
   payments in the table: 0, receipts sent: 1
2. dispatch()->afterCommit() inside, then it fails
   transaction rolled back: gateway timeout
   payments in the table: 0, receipts sent: 0
3. dispatch()->afterCommit() inside, and it commits
   job ran: receipt for payment 1, the payment row exists
   payments in the table: 1, receipts sent: 1

A transactiondatabase transaction: A group of database writes that succeed or fail together: either all of them are committed, or a rollback undoes every one. Work outside the database is not undone. More in “Events, listeners and model observers” undoes database writes, and only those. In case 1 the job ran inside the transaction, found the payment row and sent its receipt; then the rollback removed the row, so the guardian holds a receipt for a payment the table does not have. A Redis or SQS queue reaches the same state another way: the queue documentation warns that a worker may take the job before the transaction commits, so the job can also find no row at all.

afterCommit() changes when the job is queued, not what it does. In case 2 the rollback discarded the job and nothing was sent; in case 3 the job waited for the commit and ran with the row in place. The same after-commitafter commit: Running a handler only once the surrounding database transaction has committed, so it never acts on writes that a rollback undoes. With no transaction open, the handler runs at once. More in “Events, listeners and model observers” behaviour exists as the after_commit option of a queue connection, and an Eloquent observer gets it by implementing ShouldHandleEventsAfterCommit.

Two more details complete the answer. DB::transaction() throws the closure’s exception again after the rollback, which is why the probe caught it outside, and its attempts argument retries the whole closure when a deadlock happens. A job can also run twice, after a timeout or a crashed worker, and afterCommit() does nothing about that; it needs a different fix, which one of the interview questions below takes up.

Security answers with the classes Laravel uses

Security questions punish vague answers most, because “Laravel handles it” names nothing. The probe below shows four defences on one ordinary value each. Predict every line, the two validation messages included:

<?php

// Predict the output: four of Laravel's defences, each shown on one ordinary value: the
// request-forgery check, Blade escaping, validation and mass-assignment protection. Nothing here
// leaves this project. Run:  php security.php
use Illuminate\Contracts\Http\Kernel;
use Illuminate\Database\Eloquent\MassAssignmentException;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Blade;
use Illuminate\Support\Facades\Validator;

require __DIR__.'/vendor/autoload.php';
$app = require __DIR__.'/bootstrap/app.php';
$kernel = $app->make(Kernel::class);

function show(string $case, string $result): void
{
    printf("%-46s %s\n", $case, $result);
}

// 1-2. Request forgery: a POST to a web route, without a token, then with the header a browser sets.
$plain = $kernel->handle(Request::create('/notices', 'POST'));
show('1. POST /notices, no token', (string) $plain->getStatusCode());
$sameOrigin = $kernel->handle(Request::create('/notices', 'POST', server: ['HTTP_SEC_FETCH_SITE' => 'same-origin']));
show('2. POST /notices, Sec-Fetch-Site: same-origin', (string) $sameOrigin->getStatusCode());

// 3-4. Output: the same stored name printed with {{ }} and with {!! !!}.
$name = '<b>Asha</b>';
show('3. Blade {{ $name }}', Blade::render('{{ $name }}', ['name' => $name]));
show('4. Blade {!! $name !!}', Blade::render('{!! $name !!}', ['name' => $name]));

// 5-6. Validation: the messages, and what validated() keeps.
$input = ['email' => 'asha@', 'phone' => '98765'];
$validator = Validator::make($input, ['email' => 'required|email', 'phone' => 'required|digits:10']);
foreach ($validator->errors()->all() as $message) {
    show('5. validation message', $message);
}
$valid = Validator::make(['name' => 'Asha', 'is_admin' => '1'], ['name' => 'required|string']);
show('6. validated() keeps', implode(', ', array_keys($valid->validated())));

// 7-8. Mass assignment: a model that allows two fields, given a third.
class Guardian extends Model
{
    protected $fillable = ['name', 'phone'];
}

$guardian = new Guardian(['name' => 'Asha', 'is_admin' => 1]);
show('7. new Guardian([...]) keeps', implode(', ', array_keys($guardian->getAttributes())));
Model::preventSilentlyDiscardingAttributes();
try {
    new Guardian(['name' => 'Asha', 'is_admin' => 1]);
} catch (MassAssignmentException $e) {
    show('8. with discarding prevented', class_basename($e));
    echo '   '.$e->getMessage()."\n";
}

from session import run

# Shows four defaults on one ordinary value each: the request-forgery check, Blade escaping, validation and
# mass-assignment protection. The overlay carries the probe and its routes; tokens and cookies are never printed.
run(
    """
php security.php
""",
    app=True,
    overlay=("predict",),
)

$ php security.php
1. POST /notices, no token                     419
2. POST /notices, Sec-Fetch-Site: same-origin  200
3. Blade {{ $name }}                           <b>Asha</b>
4. Blade {!! $name !!}                         <b>Asha</b>
5. validation message                          The email field must be a valid email address.
5. validation message                          The phone field must be 10 digits.
6. validated() keeps                           name
7. new Guardian([...]) keeps                   name
8. with discarding prevented                   MassAssignmentException
   Add fillable property [is_admin] to allow mass assignment on [Guardian].

Lines 1 and 2 are the request-forgery check: a POST with no proof got 419, and one carrying the browser-set Sec-Fetch-SiteSec-Fetch-Site: A request header the browser sets itself, saying whether a request came from the same origin, the same site or another site. A page cannot forge it, so Laravel 13 accepts same-origin as proof that a form was posted from its own pages. More in “Laravel's security model and hardening” header with same-origin got 200. Lines 3 and 4 are output escapingoutput escaping: Converting characters such as < and > into HTML entities before printing a value, so untrusted text shows as text; Blade's {{ }} does this with htmlspecialchars to prevent cross-site scripting. More in “Your first page: route, controller and view”: {{ $name }} printed the tags as entities, and {!! $name !!} printed them raw. Line 6 shows validated datavalidated data: The array a validator hands back: only the fields that had rules, holding the values the request carried, with no key the rules did not declare. More in “Validation rules and error messages” keeping only name, and lines 7 and 8 show mass assignmentmass assignment: Creating or updating a model from a whole array of fields in one call, which is why a model declares the columns such an array is allowed to write. More in “Your first CRUD feature with Eloquent” protection dropping is_admin silently and then, with discarding prevented, throwing. Each defence becomes one row of an answer:

The fourth row has no line in this probe, because an IDORinsecure direct object reference (IDOR): Access to a record through a real identifier, such as an id in a URL, that the application loaded but failed to authorize for the current user. More in “Authorization: gates and policies” is a missing check rather than a default you can print. The vulnerabilities lab runs it: the scoped query returned 404 for another centre’s note, and the unscoped one returned the note. An answer that names the policy or the scoped query, shows that 404, and says the check belongs on every route that takes an id is the complete one.

Practise: a week of spoken answers

Give each of these one sitting of about thirty minutes in your own copy of Pathshala, a day or two apart.

1. Answer each section’s question aloud in the five parts, with a two-minute timer.
2. Change one line of a probe, for example singleton() to scoped() or the order of the two middleware, write down the output you expect, then run it.
3. Write down how many queries one page of your own app sends, then count them with DB::enableQueryLog().
4. Score each answer with the table below and spend the next session on the weakest level you did not reach.

Interview questions

Warm-up (fresher): what is the difference between bind() and singleton() in Laravel’s service container?

bind() registers a recipe that the container follows on every make(), so each call gets a new object; singleton() builds the object the first time and returns that same object for as long as the application lives. The lesson’s probe printed “two objects” for bind() asked twice and “same object” for singleton(). The difference matters most in long-lived processes: a queue worker serves many jobs from one booted application, so a singleton that keeps per-job data hands it to the next job, and under Octane, which keeps the application in memory between requests, a singleton can carry per-request data into a later request. For state that belongs to one request or one job, scoped() shares the object within that lifecycle and drops it before the next.

Warm-up (fresher to 2-5 years): in what order do two route middleware run around the controller, and when does terminate() run?

In the order the route lists them on the way in, and in reverse on the way out, because each middleware wraps the ones after it. For a route with Outer and then Inner, the probe printed Outer in, Inner in, the controller, Inner out, Outer out. A middleware that returns its own response without calling $next stops the request there: the controller never runs, but every layer outside it still sees that response on its way out. terminate() runs after the response has been sent, so it suits work the visitor should not wait for, such as a log line.

Two longer questions grow out of this lesson’s probes, one on a page’s query count and one on a receipt job that runs twice. Sketch your first two moves for each before you open it, and check them against the opening of the answer:

Key takeaways

• A strong answer gives a definition, the mechanism by name, one trade-off and a failure mode, and backs them with a run whose output you can quote.
• bind() builds a new object on every make(), singleton() shares one for as long as the application lives, and scoped() shares one per request or job, which is what Octane and queue workers need.
• Middleware run in their listed order on the way in and in reverse on the way out; one that answers itself stops the request, and terminate() runs after the response is sent.
• A relationship read in a loop costs 1 + N queries, 11 for ten batches, while eager loading costs 2; preventLazyLoading() catches the loop but not a single model.
• A rollback undoes database writes only, so a job dispatched inside a transaction can act on a row that disappears; afterCommit() queues it only after the commit.
• Security answers name the mechanism: the request-forgery middleware, Blade’s escaping, $fillable with validated(), and a policy or an owner-scoped query against IDOR.