laravel basic exmaple: 18 MCQs with answers

`public/index.php`

The request enters through `public/index.php`, which bootstraps the framework and hands the request to the router. Routes, controllers, and views are reached later in the pipeline.

`routes/web.php`

Web routes live in `routes/web.php`, where URLs and HTTP verbs are mapped to closures or controller methods.

Outputs the value of `$name`

Double curly braces are Blade's output syntax. They echo the value of the variable, escaped for safety. Control flow uses directives like `@if` and `@foreach`.

`php artisan migrate`

`php artisan migrate` runs all pending migrations. `make:migration` only creates the migration file; it does not apply it.

A tiny demo or quick test

Closure routes that return a string are the absolute minimum working example. They suit tiny demos and quick checks; real features move logic into controllers.

True

Laravel follows the MVC pattern, separating routes, controllers, models, and views into distinct layers.

`return view('hello', ['name' => 'Veda']);`

The `view()` helper takes the template name and an array of data. The array keys become variables available inside the Blade template.

So each layer holds one responsibility and stays readable

Routes map URLs to actions, controllers hold logic, and views hold presentation. Keeping each layer to one job is the habit a basic example teaches; mixing them breaks down as the app grows.

Views should hold presentation, not data logic

Blade compiles to plain PHP, so a query technically runs — but views are for presentation. Data fetching belongs in the controller or model, keeping each layer to one responsibility.

A collection of all rows from the `posts` table

`Post::all()` fetches every row from the `posts` table as a collection of `Post` model instances, ready to be passed to a view.

Migrations, applied with `php artisan migrate`

Migrations are version-controlled PHP files defining table structure. Running `php artisan migrate` recreates the database with one command, avoiding manual SQL and drift between machines.

It scaffolds a controller file with boilerplate to fill in

Artisan's `make:` commands generate boilerplate files. They do not register routes, create tables, or compile views — you still write the logic and wire the route yourself.

`Post::where('published', true)->get()`

Eloquent's query builder chains `where()` with `get()`, reading almost like English while hiding raw SQL. The other calls are not valid Eloquent query methods.

Why Laravel separates concerns as features grow

Closure routes are fine for tiny demos, but as logic grows, controllers keep routes readable and logic testable and reusable. The refactor itself demonstrates the value of separation of concerns.

A controller method referenced by each route

Controllers group logic into testable methods and let multiple routes point at the same action. Copied closures duplicate logic, and views should never decide routing.

Production apps are the same loop scaled up

Every large Laravel app begins as a basic example: one route, one controller, one view, one model. The request-to-response loop, MVC separation, and Artisan workflow stay identical — only the scale changes.

The request is routed to the HelloController, which processes the logic and returns a view.

The correct option is true because the request to '/hello' is routed to the `HelloController`, which processes the request and returns a view. This illustrates the MVC structure where the controller is responsible for handling the request logic.

It defines the structure of the 'posts' table, and you must run 'php artisan migrate' to apply it.

The correct option is true because running the migration command creates a migration file that defines the structure of the 'posts' table. To actually create the table in the database, you must run 'php artisan migrate', which applies the migration.