Quarkus Interview Questions

Core Concepts & Architecture

1. What makes Quarkus different from traditional Java frameworks like Spring Boot?

Answer:
Quarkus is designed as a "container-first" framework with key differences:

• Build-time optimization: Does most wiring, reflection, and classpath scanning at build time rather than runtime

• Ultra-fast startup: Starts in milliseconds (10-50ms native, ~500ms JVM) vs seconds for traditional frameworks

• Low memory footprint: Native executables can use <50MB RAM vs hundreds of MB

• Unified imperative/reactive: Seamlessly combines traditional and reactive programming

• Developer joy: Live coding with quarkus:dev provides instant feedback

2. Explain Quarkus' build-time optimization approach.

Answer:
Quarkus shifts work from runtime to build time through:

• Build-time metadata processing: Analyzes annotations, dependencies, and configuration during build

• Closed-world assumption: Only includes what's actually used in the final application

• AOT (Ahead-of-Time) compilation: Pre-generates boilerplate code and configuration

• GraalVM native image: Compiles to native machine code eliminating JVM overhead

• CDI bean resolution: All dependency injection is resolved during build

3. What is the difference between JVM mode and Native mode in Quarkus?

Answer:

• JVM Mode:

  • Runs on standard JVM

  • Faster build times

  • Better peak performance after warmup

  • Good for development and traditional deployment

• Native Mode:

  • Compiled to native executable via GraalVM

  • Ultra-fast startup (ms vs seconds)

  • Lower memory consumption

  • Longer build times

  • Ideal for containers, serverless, and microservices

Development & Testing

4. How does Quarkus Dev Mode improve developer productivity?

Answer:
quarkus:dev provides:

• Live coding: Code changes are automatically reflected without restart

• Continuous testing: Tests run automatically on code changes

• Dev Services: Auto-starts databases, message brokers in containers

• Debugging support: Hot deployment maintains debug sessions

• Configuration hot-reload: Config changes take effect immediately

5. Explain how Quarkus handles dependency injection.

Answer:
Quarkus uses a streamlined CDI (Contexts and Dependency Injection) implementation:

java

@ApplicationScoped  // One instance per application
public class MyService {
    public String process() { return "done"; }
}

@Inject
MyService service;  // Injected automatically

Key features:

• Build-time resolution: DI errors caught during build, not runtime

• Minimal overhead: Optimized for fast startup

• Standard annotations: @Inject, @ApplicationScoped, @RequestScoped

• Producer methods: @Produces for programmatic bean creation

6. What are Quarkus Dev Services and how do they work?

Answer:
Dev Services automatically provide development infrastructure:

• Auto-detection: Detects needed services from dependencies (PostgreSQL, Kafka, Redis)

• Container management: Starts required containers in dev/test mode

• Zero configuration: Automatically configures application to connect

• Isolation: Each developer gets their own instances

Example: Adding quarkus-jdbc-postgresql automatically starts a PostgreSQL container.

Database & Persistence

7. What is Hibernate Panache and how does it simplify data access?

Answer:
Panache provides two patterns to reduce boilerplate:

Active Record Pattern:

java

@Entity
public class Person extends PanacheEntity {
    public String name;
    public LocalDate birth;
    
    public static Person findByName(String name) {
        return find("name", name).firstResult();
    }
}

Repository Pattern:

java

@ApplicationScoped
public class PersonRepository implements PanacheRepository<Person> {
    public List<Person> findAlive() {
        return list("status", "alive");
    }
}

Benefits: 70% less code, type-safe queries, automatic pagination.

8. How do you handle transactions in Quarkus?

Answer:
Using @Transactional annotation:

java

@ApplicationScoped
public class OrderService {
    
    @Inject
    EntityManager em;
    
    @Transactional
    public void placeOrder(Order order) {
        em.persist(order);
        // Auto-rollback on exception
    }
    
    @Transactional(rollbackOn = {ValidationException.class})
    public void updateOrder(Order order) {
        // Custom rollback rules
    }
}

9. Compare reactive and imperative database access in Quarkus.

Answer:

• Imperative: Traditional blocking JDBC with Hibernate ORM

• Reactive: Non-blocking with Vert.x SQL clients

java

// Reactive PostgreSQL client
@Inject 
io.vertx.mutiny.pgclient.PgPool client;

public Uni<List<User>> getUsers() {
    return client.query("SELECT * FROM users")
        .execute()
        .map(rows -> { /* process results */ });
}

Use reactive for high-concurrency, non-blocking scenarios.

Security

10. How do you implement JWT authentication in Quarkus?

Answer:

properties

# application.properties
quarkus.smallrye-jwt.enabled=true
quarkus.smallrye-jwt.public-key-location=publicKey.pem
mp.jwt.verify.issuer=https://your-issuer.com

java

@Path("/secure")
@Authenticated
public class SecureResource {
    
    @GET
    @RolesAllowed("admin")
    public String adminEndpoint(@Inject JsonWebToken jwt) {
        return "Hello " + jwt.getName();
    }
}

11. Explain how to implement role-based security in Quarkus.

Answer:
Using security annotations:

java

@Path("/api")
public class Resource {
    
    @GET
    @Path("/public")
    @PermitAll  // No authentication required
    public String publicData() { return "public"; }
    
    @GET
    @Path("/user")
    @RolesAllowed("user")  // Requires user role
    public String userData() { return "user data"; }
    
    @GET
    @Path("/admin")
    @RolesAllowed("admin")  // Requires admin role
    public String adminData() { return "admin data"; }
}

Cloud & Deployment

12. How do you create a native executable with Quarkus?

Answer:

bash

# Using Maven
./mvnw package -Dnative

# Using container build (no local GraalVM needed)
./mvnw package -Dnative -Dquarkus.native.container-build=true

# For specific container runtime
./mvnw package -Dnative -Dquarkus.native.container-build=true -Dquarkus.native.container-runtime=podman

Configuration in application.properties:

properties

quarkus.package.type=native
quarkus.native.enable-all-security-services=true
quarkus.native.resources.includes=**/*.properties

13. What are the benefits of using Quarkus in a Kubernetes environment?

Answer:

• Fast startup: Quick pod startup enables efficient auto-scaling

• Low memory: Higher density - more pods per node

• Health checks: Built-in /q/health/live and /q/health/ready endpoints

• Config management: Integration with Kubernetes ConfigMaps and Secrets

• Service discovery: Native Kubernetes service discovery

• Small images: Minimal base images reduce storage and pull times

14. How do you configure Quarkus for different environments (dev, test, prod)?

Answer:
Using configuration profiles in application.properties:

properties

# Common configuration
quarkus.application.name=myapp
quarkus.http.port=8080

%dev.quarkus.log.level=DEBUG
%dev.quarkus.datasource.jdbc.url=jdbc:postgresql://localhost:5432/devdb

%test.quarkus.log.level=INFO  
%test.quarkus.datasource.jdbc.url=jdbc:postgresql://localhost:5432/testdb

%prod.quarkus.log.level=WARN
%prod.quarkus.datasource.jdbc.url=${DATABASE_URL}
%prod.quarkus.datasource.username=${DB_USERNAME}

Advanced Concepts

15. What are Quarkus Extensions and why are they important?

Answer:
Extensions are the heart of Quarkus - they:

• Integrate capabilities: Add support for databases, messaging, security, etc.

• Provide build-time optimization: Each extension optimizes its domain at build time

• Unify configuration: Consistent configuration approach across all features

• Enable native compilation: Ensure GraalVM compatibility for their functionality

Examples: quarkus-hibernate-orm, quarkus-resteasy-reactive, quarkus-amazon-lambda

16. How does Quarkus handle reactive programming?

Answer:
Quarkus uses Mutiny as its reactive programming library:

java

@Inject 
@Channel("prices") 
MutinyEmitter<Double> priceEmitter;

public Uni<String> processAsync() {
    return Uni.createFrom().item("data")
        .onItem().transform(String::toUpperCase)
        .onFailure().recoverWithItem("fallback");
}

public Multi<String> streamData() {
    return Multi.createFrom().ticks().every(Duration.ofSeconds(1))
        .onItem().transform(tick -> "Tick: " + tick);
}

17. Explain the difference between RESTEasy Classic and RESTEasy Reactive.

Answer:

• RESTEasy Classic: Traditional JAX-RS implementation, blocking I/O

• RESTEasy Reactive: New implementation, supports both blocking and non-blocking

java

// RESTEasy Reactive - implicit non-blocking
@GET
@Path("/reactive")
public Uni<String> reactiveEndpoint() {
    return Uni.createFrom().item("Hello Reactive");
}

// Can also do blocking
@GET  
@Path("/blocking")
@Blocking
public String blockingEndpoint() {
    return "Hello Blocking";
}

18. How do you implement caching in Quarkus?

Answer:
Using the @CacheResult and related annotations from Caffeine:

java

@ApplicationScoped
public class ExpensiveService {
    
    @CacheResult(cacheName = "expensive-calc")
    public String expensiveOperation(String input) {
        // Simulate expensive computation
        return expensiveComputation(input);
    }
    
    @CacheInvalidate(cacheName = "expensive-calc")
    public void invalidateCache(String key) {
        // Cache will be invalidated
    }
}

Configuration:

properties

quarkus.cache.caffeine.expensive-calc.maximum-size=1000
quarkus.cache.caffeine.expensive-calc.expire-after-write=10M

Troubleshooting & Best Practices

19. What are common issues when building native images and how do you solve them?

Answer:
Common issues and solutions:

1. Missing reflection configuration:

   java

   @RegisterForReflection(targets = {MyClass.class})
   public class ReflectionConfig {}

2. Resource not found:

   properties

   quarkus.native.resources.includes=**/*.json,**/*.xml

3. Class initialization errors:

   properties

   quarkus.native.initialize-at-build-time=com.mypackage

4. JNI issues:

   properties

   quarkus.native.enable-all-security-services=true

20. How do you monitor and manage a Quarkus application in production?

Answer:
Using built-in endpoints and integrations:

Health Checks:

java

@Liveness
@ApplicationScoped
public class CustomHealthCheck implements HealthCheck {
    public HealthCheckResponse call() {
        return HealthCheckResponse.up("Custom check");
    }
}

Metrics:

properties

quarkus.micrometer.enabled=true
quarkus.smallrye-health.extensions.enabled=true

Monitoring endpoints:

• /q/health - Application health

• /q/metrics - Application metrics

• /q/info - Application information

• /q/openapi - API documentation

Logging:

properties

quarkus.log.level=INFO
quarkus.log.category."com.myapp".level=DEBUG
quarkus.log.console.json=true  # JSON format for log aggregation

These questions cover the essential aspects of Quarkus that are commonly discussed in technical interviews, from basic concepts to advanced deployment scenarios.