What is pom.xml?
pom.xml (Project Object Model) is the configuration file for Maven projects.
Defines project information, dependencies, plugins, build settings, and more.
Used by Maven to manage builds, dependency resolution, and project lifecycle.
What is the difference between a JAR and a WAR?
JAR (Java ARchive):
* Packages Java classes, libraries, and resources for standalone applications or libraries.
* Used for running Java programs with java -jar.
WAR (Web Application Archive):
* Packages web applications (servlets, JSPs, static files) for deployment on a web server (like Tomcat).
* Contains a specific directory structure (WEB-INF, etc.).
What are Maven default lifecycles and their phases?
Maven has three default lifecycles:
* clean: Cleans up artifacts from previous builds.
* default (build): Handles project deployment (main build process).
* site: Generates project documentation.
Key phases in the default (build) lifecycle:
validate → compile → test → package → verify → install → deploy
In a large multi-module Maven project, how would you manage dependency versions across all modules while avoiding conflicts or duplications?
Use a parent POM to centralize dependency versions and plugin management.
Define dependencies and their versions in the <dependencyManagement> section of the parent POM.</dependencyManagement>
Child modules inherit versions from the parent, ensuring consistency and avoiding duplication.
Use the same parent for all modules to prevent conflicts.
What dependency scopes are available in Maven?
compile: Default; available in all build phases and included in the final artifact.
provided: Needed for compile/test but provided by the runtime environment (e.g., servlet API).
runtime: Needed at runtime but not for compilation.
test: Only available for testing; not included in the final artifact.
system: Similar to provided, but requires an explicit path on the local system.
import: Used only in <dependencyManagement> for importing dependencies from other BOMs.</dependencyManagement>
What are the steps after applying “mvn clean package”?
The project is compiled, tested, and packaged into a JAR or WAR file in the target directory.
Next steps:
* Deploy the artifact to a server or application container.
* Optionally, run mvn install to add the artifact to your local Maven repository.
* Optionally, run mvn deploy to upload the artifact to a remote repository.
What is the difference between “mvn package” and “mvn install”?
mvn package:
Compiles, tests, and packages the project into a JAR/WAR file in the target directory.
mvn install:
Does everything package does, plus installs the built artifact into your local Maven repository for use as a dependency in other projects.
What is Maven BOM? When should you use it?
BOM (Bill of Materials): A special POM file that manages and centralizes dependency versions.
Use it:
* To ensure consistent dependency versions across multiple modules or projects.
* Import the BOM in your project’s <dependencyManagement> section to avoid version conflicts and duplication.</dependencyManagement>
What are the most commonly used build tools for Java?
Maven: XML-based, manages dependencies and build lifecycle.
Gradle: Groovy/Kotlin-based, flexible and fast, supports both Java and other languages.
Ant: XML-based, procedural, requires manual dependency management.
What deployment strategies do you know? (e.g., blue-green, canary)
Blue-Green Deployment: Two environments (blue and green); switch traffic to the new version after testing.
Canary Deployment: Gradually roll out the new version to a small subset of users before full release.
Rolling Deployment: Update servers in batches, so some run the old version while others run the new.
Recreate Deployment: Stop the old version completely before starting the new one.
A/B Testing: Deploy different versions to user segments to compare performance or features.
What is a canary deployment?
A deployment strategy where a new version of an application is released to a small subset of users first.
Monitors performance and errors before gradually rolling out to all users.
Reduces risk by limiting the impact of potential issues.
What is CI/CD? What are the steps in a CI/CD pipeline?
CI/CD:
* Continuous Integration (CI): Automatically build and test code changes when developers commit.
* Continuous Delivery/Deployment (CD): Automatically deliver or deploy code to production after passing tests.
Typical pipeline steps:
* Code commit
* Build
* Automated tests
* Artifact packaging
* Deployment to staging/production
* Post-deployment tests/monitoring
Where would you put Sonar scan in your pipeline? What are the benefits/disadvantages of blocking the pipeline on Sonar?
Placement:
* Run Sonar scan after build and unit tests, before deployment.
Blocking benefits:
* * Ensures code quality and security standards are met before release.
* * Prevents technical debt and vulnerabilities from reaching production.
Blocking disadvantages:
* Can slow down delivery if false positives or strict rules block progress.
* May frustrate developers if not tuned to project needs.
How can you convince your client to implement CD? What are some pitfalls?
Convincing points:
* Faster, more reliable releases.
* Reduced manual errors and deployment risks.
* Quick feedback and ability to respond to market changes.
* Improved quality through automated testing and validation.
Pitfalls:
* Initial setup effort and learning curve.
* Requires cultural change and team buy-in.
* Poorly designed pipelines can cause bottlenecks or failures.
How do you manage secrets and credentials securely in CI/CD pipelines? Can you share an example?
Best practices:
* Store secrets in secure vaults or secret managers (e.g., HashiCorp Vault, AWS Secrets Manager, Azure Key Vault).
* Use environment variables or pipeline-specific secret stores (e.g., GitHub Actions Secrets, GitLab CI Variables).
* Never hard-code secrets in code or config files.
* Limit access to secrets using least privilege principles.
Example:
* In GitHub Actions, store API keys as repository secrets and reference them in the workflow using ${{ secrets.MY_API_KEY }}.
How do you implement rollback strategies in a CI/CD pipeline? Can you share an example?
Rollback strategies:
* Keep previous stable versions of artifacts for quick redeployment.
* Use deployment strategies like blue-green or canary, allowing easy switch back to the old version.
* Automate rollback on failure detection (e.g., failed health checks or tests).
Example:
* In a blue-green deployment, if the new (green) version fails, route traffic back to the old (blue) environment.
How would you investigate a failed deployment? What tools would you use?
Steps:
* Review CI/CD pipeline logs for errors.
* Check application and server logs for stack traces or failures.
* Analyze monitoring and alerting dashboards for anomalies (e.g., CPU, memory, response times).
* Use version control to compare changes with the last successful deployment.
* Reproduce the issue in a staging environment if possible.
Tools:
* CI/CD platform logs (e.g., Jenkins, GitHub Actions, GitLab CI)
* Log aggregators (e.g., ELK Stack, Splunk)
* Monitoring tools (e.g., Prometheus, Grafana, Datadog)
* Version control systems (e.g., Git)
After deployment, users complain about performance and stability. How do you investigate and resolve the issue?
Investigation steps:
* Check application and server logs for errors or exceptions.
* Analyze monitoring dashboards (CPU, memory, response times, error rates).
* Review recent code and configuration changes.
* Use APM tools (e.g., New Relic, Datadog) to trace slow transactions or bottlenecks.
* Reproduce issues in a test/staging environment.
Resolution:
* Roll back to the previous stable version if needed.
* Fix code/configuration issues and redeploy.
* Scale resources or optimize queries as required.
What Maven plugins can be used to run automated tests created by Java test engines like JUnit or TestNG?
maven-surefire-plugin: Runs unit tests during the test phase (supports JUnit, TestNG).
maven-failsafe-plugin: Runs integration tests during the integration-test phase (supports JUnit, TestNG).
How can you manage dependency versions centrally in a Maven multi-module project with different subsets of dependencies?
Use a parent POM with a <dependencyManagement> section to define versions for all shared dependencies.</dependencyManagement>
Each module declares only the dependencies it needs (without versions); versions are inherited from the parent.
For module-specific dependencies, declare them in the module’s own pom.xml.
