diff --git a/docs/2023/exercise1.md b/docs/2023/exercise1.md
new file mode 100644
index 0000000000000000000000000000000000000000..88c45c230514d42c6d7909eb00a9d84ad5e107c4
--- /dev/null
+++ b/docs/2023/exercise1.md
@@ -0,0 +1,137 @@
+# Exercise 1: Automated Quality Assurance Activities
+
+You are given a codebase of [a Web app named Sitodo PMPL](https://gitlab.cs.ui.ac.id/pmpl/2023/test-automation-exercise)
+that implemented using Java and Spring Boot.
+The codebase contains both the production code and the test code.
+The production code is the implementation of all features in the application.
+The test code comprises unit test suite and functional test suite that covers **97%** of the production code when
+tested locally using Maven.
+
+## PMD Static Code Analyser
+
+As part of the exercise, you are asked to modify the existing CI/CD pipeline for performing automated quality assurance activities.
+Besides running the test suites (i.e., unit and functional tests),
+the pipeline also runs a static analyser called [PMD][PMD] as part of `verify` Maven task execution.
+
+The analysis report generated by PMD currently only displayed as log messages in the CI job log,
+which is too verbose to be communicated to the management or the person with non-technical role.
+The sample log messages that reporting code quality issues identified by PMD can be seen in the following snippet:
+
+```shell
+[INFO] PMD Failure: com.example.sitodo.SitodoApplication:7 Rule:UseUtilityClass Priority:3 All methods are static.  Consider using a utility class instead. Alternatively, you could add a private constructor or make the class abstract to silence this warning..
+[INFO] PMD Failure: com.example.sitodo.controller.TodoListController:16 Rule:TooManyMethods Priority:3 This class has too many methods, consider refactoring it..
+[INFO] PMD Failure: com.example.sitodo.controller.TodoListController:51 Rule:GuardLogStatement Priority:2 Logger calls should be surrounded by log level guards..
+```
+
+It is possible to create the HTML version of the analysis report that much neater for reporting purpose.
+In fact, the PMD already been configured to produce the HTML report into a file named `pmd.html` located at `target/site`.
+However, it is not yet downloadable as part of the CI artefact.
+Hence, one of your tasks in this exercise will be modifying the CI/CD pipeline configuration so the `pmd.html` can be downloaded by the project collaborators.
+
+An example of the HTML report generated by PMD can be seen in the following screenshot:
+
+![PMD report example](./images/example_pmd_html.png)
+
+You may also notice that some rules used by PMD are not relevant to the codebase or even not applicable to Spring Boot.
+Therefore, you will also need to customise the configuration used by PMD to produce a report with less noise.
+
+To summarise, your tasks related to PMD are as follows:
+
+- Modify the existing CI/CD pipeline so the `pmd.html` generated by PMD as part of the `verify` Maven task is captured as part of the CI artefact.
+- Ensure you can download the HTML report generated by PMD as part of the CI artefact after you updated the CI/CD pipeline configuration.
+- Look at the HTML report and identify which PMD rules are still relevant to the codebase and PMD rules that may already outdated.
+  For example, `StdCyclomatic` and `ModifiedCyclomatic` rules are already deprecated, thus can be excluded from the PMD rules later.
+- List out the finalised set of PMD rules that you use into the bottom section of your `README.md` of the codebase.
+  Then, give two examples of rules that are applicable to another application but may lead to a bad design if applied to Spring Boot application.
+  There is no absolute correct answer for this part. Therefore, it is important to justify your reasoning.
+- Update the PMD rules by modifying the corresponding PMD configuration section in `pom.xml`.
+  Make sure, at least, the deprecated rules are excluded.
+- Try to improve the code quality and security that relevant based on the analysis produced by the CI/CD
+  pipeline. Based on the identified issues, you have to fix the production code and the test code to resolve the issues.
+  Please ensure the code coverage percentage is still maintained **above 97%**.
+
+## Exploring GitLab CI Job Templates
+
+PMD is one among possible tools that can be used for analysing code quality.
+There are other tools such as SonarQube, which require a separate application for analysing and reporting the code quality.
+To keep stay within the GitLab platform, GitLab also provides several CI job templates that can be included as part of automated quality assurance in the CI/CD pipeline.
+
+As part of the exercise, you need to modify the existing CI/CD pipeline configuration to include the following CI job template:
+
+- [Code Quality](https://docs.gitlab.com/ee/ci/testing/code_quality.html)
+- [Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/)
+- [Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)
+
+Once you have updated the configuration, look at a CI/CD pipeline that has run
+and see what kinds of information produced by the included CI job templates.
+
+## Faculty's CI Infrastructure
+
+For your information when setting up the GitLab CI/CD configuration that will run on [GitLab CSUI](https://gitlab.cs.ui.ac.id),
+the following is the overview of the CI infrastructure in the faculty at the time of writing:
+
+- GitLab Runner is running on a server using [Docker executor](https://docs.gitlab.com/runner/executors/docker.html)
+  with [privileged mode enabled](https://docs.gitlab.com/runner/executors/docker.html#privileged-mode).
+  Consequently, all CI jobs running on projects hosted at GitLab CSUI will run in a container by default
+  and able to access the Docker daemon running on the server.
+- The containers spawned by the Docker executor may utilise all CPU cores available on the server,
+  but limited to memory allocation, which is only 8 GB per running container.
+- GitLab Runner has been configured to use a separate [Minio](https://min.io) cache server,
+  thus allowing caching files and folders across multiple stages in a CI/CD pipeline.
+
+> Note: If you are interested with Infrastructure-as-Code (IaC) configuration of the runner,
+> you can find the Ansible playbook used for setting up the server and installing GitLab Runner
+> at [Infra Kuda repository](https://gitlab.cs.ui.ac.id/ppl-fasilkom-ui/infra/kuda).
+
+## Tasks
+
+To guide you working on the exercise, the following are the tasks you need to complete:
+
+1. [ ] Fork [Sitodo PMPL codebase](https://gitlab.cs.ui.ac.id/pmpl/2023/test-automation-exercise) into your own namespace
+   on [GitLab CSUI](https://gitlab.cs.ui.ac.id) and set the visibility of your fork to **Internal**.
+2. [ ] Clone the forked repository into your local development machine and load it into your favourite IDE.
+   We recommend [IntelliJ IDEA](https://www.jetbrains.com/idea/download/) since the project was built and tested using
+   IntelliJ.
+3. [ ] Set up the development environment on your local development machine.
+   You can find the information required to set up the development environment in the project's `README.md` file.
+4. [ ] Ensure you can test and run the application locally.
+5. [ ] Update the CI/CD pipeline configuration in the codebase according to the tasks mentioned in [PMD](#pmd-static-code-analyser)
+   and [CI job template](#exploring-gitlab-ci-job-templates) sections.
+6. [ ] Identify code quality and security issues, then resolve the identified issues.
+7. [ ] Write a short report at the end of the project's `README.md` that describes:
+   1. [ ] List of identified code quality and security issues in the codebase.
+   2. [ ] Explanation on how you resolve at least two issues identified by PMD in the codebase.
+      You can explain it by comparing the `diff` of the codebase and explain the changes you made.
+   3. [ ] Reflection on your experience making changes to the codebase with existing test suites.
+      Did the presence of test code make you more confident in making changes to the production code?
+      Explain why!
+
+## Additional Tasks
+
+Explore and implement SonarQube in your CI/CD pipeline. Use [SonarQube CSUI](https://sonarqube.cs.ui.ac.id/).
+You can read more details and relevant config on the website.
+
+- [ ] Modify `pom.xml` with SonarQube relevant config
+- [ ] Add a CI/CD pipeline to run SonarQube scanner task
+- [ ] Improve the code quality based on the SonarQube scanner result.
+- [ ] Summarise your findings in the bottom section of the `README.md`
+
+## Deliverables
+
+At the end of this exercise, you are required to prepare the following artefacts:
+
+- [ ] A fork repository of Sitodo PMPL project in your own namespace on GitLab CSUI.
+- [ ] An updated GitLab CI/CD configuration, i.e. `.gitlab-ci.yml`, in the fork repository.
+- [ ] An example of working pipeline in the fork repository that shows the CI/CD pipeline successfully build and test the application.
+- [ ] An updated `README.md` in the fork repository.
+
+The due date of this exercise is: **10 November 2023, 23:55 UTC+7**.
+Submit the URL of your fork repository to the designated submission slot on SCELE.
+Please ensure any updates to the fork repository related to this exercise were made and pushed before the due date.
+
+## References
+
+- [GitLab CI/CD Configuration Reference](https://docs.gitlab.com/ee/ci/yaml/)
+- [SonarQube CSUI](https://sonarqube.cs.ui.ac.id/)
+
+[PMD]: https://pmd.github.io/
diff --git a/docs/2023/images/example_pmd_html.png b/docs/2023/images/example_pmd_html.png
new file mode 100644
index 0000000000000000000000000000000000000000..e4eef814689e1213b7b26386afaef481a5e840a3
Binary files /dev/null and b/docs/2023/images/example_pmd_html.png differ
diff --git a/mkdocs.yml b/mkdocs.yml
index e2757376ae02963289a7ea814791626b56fc7eec..f10a5e4c579ca1b4e3c95a8093274ea455d2ce89 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -58,6 +58,7 @@ nav:
     - Day 2 - TDD: workshops/day_2_tdd.md
     - Day 3 - BDD: workshops/day_3_bdd.md
   - Problem Set:
+    - (2023) Exercise 1 - Automated QA: 2023/exercise1.md
     - (2022) Exercise 1 - Automated QA: 2022/exercise1.md
     - (2022) Exercise 2 - Input Domain Modeling: 2022/exercise2.md
     - (2022) Exercise 3 - Behavior Driven Development: 2022/exercise3.md