Wyniki egzaminu

Nowy egzamin

Informacje o egzaminie:

Zawód: Technik informatyk
Kwalifikacja: INF.03 - Tworzenie i administrowanie stronami i aplikacjami internetowymi oraz bazami danych
Data rozpoczęcia: 8 czerwca 2026 14:33
Data zakończenia: 8 czerwca 2026 14:48

Egzamin niezdany

Wynik: 17/40 punktów (42,5%)

Wymagane minimum: 20 punktów (50%)

Nowe

Analiza przebiegu egzaminu- sprawdź jak rozwiązywałeś pytania

Przebieg egzaminu

Udostępnij swój wynik

Facebook

X.com

Szczegółowe wyniki:

Pytanie 1

Jakie sformułowanie najlepiej opisuje metodę POST do przesyłania formularzy?

A. Może być zarejestrowana jako zakładka w przeglądarce internetowej

B. Dane są przesyłane przez adres URL, co czyni je widocznymi dla użytkownika

C. Jest zalecana, gdy przesyłane są dane poufne, na przykład hasło, numer telefonu lub numer karty kredytowej

D. Ma dodatkowe ograniczenia związane z długością adresu - maksimum 255 znaków

Metoda POST jest jedną z podstawowych metod przesyłania danych w protokole HTTP, której głównym celem jest umożliwienie przesyłania dużych objętości danych, w tym informacji poufnych. Gdy używamy metody POST do wysyłania formularzy, dane nie są widoczne w adresie URL, co czyni tę metodę bardziej odpowiednią do przesyłania wrażliwych informacji, takich jak hasła, numery kart kredytowych czy dane osobowe. W przeciwieństwie do metody GET, która dodaje dane do adresu URL, metoda POST przesyła je w ciele zapytania, co ogranicza ryzyko przypadkowego ujawnienia informacji. Standardy bezpieczeństwa w branży webowej zalecają użycie metody POST do wszelkich operacji, które zmieniają stan serwera, jak dodawanie użytkowników, logowanie czy przesyłanie informacji finansowych. Przykładem może być formularz logowania, w którym dane użytkownika są przesyłane do serwera w sposób niewidoczny dla osób trzecich, co minimalizuje ryzyko przechwycenia tych informacji przez złośliwe oprogramowanie.

Pytanie 2

GRANT CREATE, ALTER ON sklep.* TO adam; Zakładając, że użytkownik adam nie dysponował wcześniej żadnymi uprawnieniami, to polecenie SQL przyzna mu prawa jedynie do

A. tworzenia oraz modyfikacji struktury wszystkich tabel w bazie sklep

B. tworzenia oraz modyfikacji struktury w tabeli sklep

C. wstawiania oraz modyfikacji danych we wszystkich tabelach bazy sklep

D. wstawiania oraz modyfikacji danych w tabeli sklep

Odpowiedzi, które sugerują, że użytkownik adam ma ograniczone prawa tylko do konkretnej tabeli lub tylko do wstawiania i zmiany danych, wynikają z mylnego zrozumienia mechanizmu przyznawania uprawnień w SQL. W kontekście opisanego polecenia, przyznawanie praw na poziomie tabeli (sklep.*) oznacza, że wszystkie tabele w bazie danych sklep są objęte tymi uprawnieniami. W praktyce, wstawianie oraz modyfikacja danych (DML) są różnymi operacjami od tworzenia i zmiany struktury tabel (DDL). Przyznanie uprawnień CREATE i ALTER jednoznacznie wskazuje na możliwość edytowania struktury bazy, a nie tylko na manipulację danymi. Wiele osób, które mogą mylić te dwa aspekty, może zakładać, że nadanie praw do konkretnej tabeli ogranicza się do operacji na danych, co jest mylnym podejściem. Mylne jest również ograniczanie praw do jednej tabeli, gdyż polecenie dotyczy wszystkich tabel w bazie. W związku z tym, aby poprawnie zarządzać uprawnieniami w bazie danych, należy zrozumieć różnice między uprawnieniami DDL i DML oraz ich zastosowanie w kontekście całej bazy danych, nie tylko pojedynczej tabeli.

Pytanie 3

Z ilustracji można odczytać, że użytkownik bazy danych posiada uprawnienia do:

A. dodawania, aktualizacji i usuwania danych.

B. wyświetlania, dodawania i usuwania danych.

C. wyświetlania, aktualizacji i usuwania danych.

D. wyświetlania, dodawania i aktualizacji danych.

Na ilustracji pokazano panel nadawania uprawnień do operacji na danych w bazie. Każda z widocznych opcji odpowiada konkretnemu typowi polecenia SQL: SELECT to odczyt danych, INSERT to wstawianie nowych rekordów, UPDATE to modyfikacja istniejących wierszy, a DELETE to ich usuwanie. Typowym błędem jest mechaniczne kojarzenie „pracy na danych” tylko z dodawaniem i usuwaniem, bez zwrócenia uwagi na to, które pola są naprawdę zaznaczone. Na obrazku INSERT nie jest zaznaczony, więc użytkownik nie może dodawać nowych rekordów. Jeśli ktoś wybrał odpowiedź zawierającą „dodawanie danych”, to prawdopodobnie założył, że skoro użytkownik ma prawo zmieniać i kasować dane, to na pewno może też je dodawać. W praktyce w administracji bazą to tak nie działa – każde z tych uprawnień jest rozdzielone i może być nadawane osobno. Innym typowym nieporozumieniem jest mylenie UPDATE z INSERT. UPDATE nie tworzy nowych wierszy, tylko zmienia pola w rekordach, które już istnieją. To ważne rozróżnienie, bo w wielu systemach biznesowych pracownik ma prawo poprawić dane klienta (UPDATE), ale nie może dodawać nowych klientów (INSERT). Podobnie DELETE, czyli usuwanie danych, często jest ograniczane, bo kasowanie rekordów bywa nieodwracalne albo wymaga dodatkowych procedur. Jeśli odpowiedź sugeruje, że użytkownik może dodawać dane, to stoi to w sprzeczności z tym, co realnie widać na ilustracji – brak zaznaczenia przy INSERT jasno mówi, że wstawianie nowych rekordów jest zablokowane. Warto wyrabiać sobie nawyk dokładnego czytania takiego interfejsu: sprawdzić każdy checkbox i od razu przełożyć go na konkretne operacje SQL. W codziennej pracy z bazami danych poprawne rozumienie różnicy między SELECT, INSERT, UPDATE i DELETE jest absolutną podstawą bezpiecznego projektowania uprawnień i unikania przypadkowych modyfikacji danych.

Pytanie 4

Które polecenie nadaje użytkownikowi „uczen” najniższy poziom uprawnień (tylko odczyt, bez zmiany danych i struktury)?

GRANT ALTER, SELECT ON szkola.przedmioty TO uczen;

GRANT DROP ON szkola.przedmioty TO uczen;

GRANT SELECT ON szkola.przedmioty TO uczen;

GRANT INSERT, DROP ON szkola.przedmioty TO uczen;

Uprawnienia w SQL nadaje się poleceniem GRANT, a ich „poziom” zależy od tego, co użytkownik może zrobić. Najwęższy, najbezpieczniejszy zakres to wyłącznie odczyt danych, czyli SELECT - użytkownik widzi dane, lecz nie może ich zmieniać ani ruszać struktury tabeli. Zgodnie z zasadą najmniejszych uprawnień kontu aplikacyjnemu czy „uczniowi” daje się tylko tyle, ile naprawdę potrzebuje. Dlatego najniższy poziom uprawnień nadaje GRANT SELECT.

Pytanie 5

W którym pliku konfiguracyjnym serwera Apache ustawia się przekierowanie 301 (z jednego URL na inny)?

.htaccess

apacheConf

conf.php

configuration.php

Przekierowania (np. trwałe 301) na serwerze Apache ustawia się w pliku .htaccess - to plik konfiguracyjny katalogu, w którym definiuje się reguły przepisywania adresów. Dlatego przekierowanie 301 ustawia się w .htaccess.

Pytanie 6

Co sprawdzić przed wykonaniem kopii zapasowej bazy, aby dało się ją potem poprawnie odtworzyć?

A. spójność bazy danych

B. możliwość udostępnienia bazy

C. prawa dostępu do serwera

D. poprawność składni zapytań

Przed wykonaniem kopii zapasowej należy sprawdzić SPÓJNOŚĆ bazy - jeśli dane są uszkodzone lub niespójne, backup utrwali ten zły stan i odtworzona baza również będzie wadliwa. Weryfikacja spójności daje pewność, że kopia nadaje się do poprawnego przywrócenia. Dlatego sprawdza się spójność bazy danych.

Pytanie 7

Jakie mechanizmy przydzielania zabezpieczeń, umożliwiające przeprowadzanie operacji na bazie danych, są powiązane z zagadnieniami dotyczącymi zarządzania kontami, użytkownikami oraz uprawnieniami?

A. Z przywilejami systemowymi

B. Z regułami

C. Z przywilejami obiektowymi

D. Z atrybutami

Uprawnienia związane z atrybutami i regułami mogą mylnie wydawać się odpowiednie w kontekście zarządzania dostępem, ale ich zrozumienie jest kluczowe, aby uniknąć błędnych wniosków. Atrybuty w kontekście systemów zarządzania bazami danych są często używane do definiowania cech obiektów, takich jak kolumny w tabelach, ale nie są bezpośrednio związane z mechanizmami nadawania uprawnień. Reguły, choć mogą być wykorzystywane do definiowania polityk bezpieczeństwa, nie są tym samym co przywileje systemowe. Przywileje obiektowe, z kolei, dotyczą dostępu do konkretnych obiektów w bazie danych, takich jak tabele czy widoki, a nie ogólnych uprawnień administracyjnych. Często występuje nieporozumienie, że wszystkie te mechanizmy są równoważne, co prowadzi do niewłaściwego stosowania uprawnień w systemach. Kluczowe jest zrozumienie, że przywileje systemowe są tymi, które kontrolują dostęp do całej struktury bazy danych, a nie tylko do jej poszczególnych elementów, co stanowi podstawę dla skutecznego zarządzania bezpieczeństwem w środowiskach IT. W praktyce niepoprawne przypisywanie uprawnień może prowadzić do nieautoryzowanego dostępu do danych, co jest sprzeczne z najlepszymi praktykami ochrony informacji.

Pytanie 8

Po zrealizowaniu polecenia SQL użytkownik Ela zyska możliwość wykorzystania poniższych uprawnień:

GRANT SELECT, INSERT, UPDATE, DELETE ON baza1.tab1 TO 'Ela'@'localhost';

A. realizować wszystkie działania na strukturze danych

B. przeprowadzać wszystkie operacje na danych

C. tylko dodawać oraz zmieniać dane

D. tylko tworzyć i zmieniać strukturę tabeli

Wybór odpowiedzi, która sugeruje, że użytkownik może jedynie dodawać i modyfikować dane, jest mylny, ponieważ nie uwzględnia uprawnienia SELECT, które jest również częścią przyznanych uprawnień. Ograniczając interpretację do dodawania i modyfikowania danych, można zignorować kluczowy aspekt bazy danych – możliwość ich przeglądania. Ponadto, twierdzenie, że użytkownik może jedynie tworzyć i modyfikować strukturę tabel, jest nieadekwatne, ponieważ polecenie GRANT nie dotyczy uprawnień do zmiany struktury bazy danych, takich jak dodawanie nowych tabel czy kolumn. Takie operacje są regulowane przez inne uprawnienia, które muszą być również przyznane. W sytuacji, gdy mówimy o operacjach na strukturze danych, należy uwzględnić, że uprawnienia GRANT dotyczą jedynie pracy z danymi przechowywanymi w tabelach, a nie z ich strukturalnymi aspektami. Pojęcie 'wszystkie operacje na strukturze danych' może wprowadzać w błąd, ponieważ nie odnosi się do przyznanych uprawnień, które nie obejmują na przykład tworzenia nowych tabel lub zmiany ich definicji. Dlatego ważne jest, aby dokładnie zrozumieć różnicę między uprawnieniami do operacji na danych a uprawnieniami do zarządzania strukturą bazy danych. Kluczowym błędem jest zatem niedostrzeganie znaczenia uprawnienia SELECT oraz niewłaściwe rozumienie zakresu przyznawanych uprawnień w kontekście SQL.

Pytanie 9

W tabeli artykuly wykonano określone instrukcje dotyczące uprawnień użytkownika jan. Po ich realizacji użytkownik jan uzyska możliwość

GRANT ALL PRIVILEGES ON artykuly TO jan
REVOKE SELECT, UPDATE ON artykuly FROM jan

A. tworzenia tabeli i wypełniania jej informacjami

B. sprawdzania zawartości tabeli

C. tworzenia tabeli oraz edytowania jej zawartości

D. edycji danych i przeglądania zawartości tabeli

Analizując pytanie i dostępną sekwencję poleceń SQL jasno wynika że użytkownik jan po wykonaniu tych poleceń nie zachowa uprawnień do przeglądania ani aktualizowania danych w tabeli artykuly. Pierwsze polecenie GRANT ALL PRIVILEGES przyznaje pełne uprawnienia co obejmuje tworzenie modyfikowanie usuwanie danych oraz ich przeglądanie. Jednakże drugie polecenie REVOKE SELECT UPDATE wycofuje konkretne prawa do przeglądania (SELECT) oraz aktualizowania (UPDATE) danych co oznacza że jan nie będzie mógł ani przeglądać ani modyfikować istniejących danych. To wyklucza odpowiedzi dotyczące aktualizowania danych i przeglądania tabeli jako poprawne. Często błędem jest założenie że cofnięcie tylko dwóch uprawnień nie wpłynie na możliwość podstawowych operacji takich jak przeglądanie. W rzeczywistości koordynacja uprawnień w bazach danych wymaga dokładnej analizy wszystkich przyznanych i cofniętych praw. Takie zarządzanie dostępem jest kluczowe dla zapewnienia bezpieczeństwa i integralności danych szczególnie w środowiskach produkcyjnych gdzie błędna konfiguracja może prowadzić do niepożądanych modyfikacji lub utraty danych.

Pytanie 10

W MS SQL Server rola predefiniowana o nazwie dbcreator umożliwia użytkownikowi

A. zarządzanie bezpieczeństwem systemu

B. wykonywanie wszelkich operacji na serwerze i posiadanie praw do każdej bazy

C. zarządzanie plikami na dysku

D. tworzenie, modyfikowanie, usuwanie oraz przywracanie bazy danych

Rola dbcreator w MS SQL Server rzeczywiście pozwala użytkownikowi na tworzenie, modyfikowanie, usuwanie i odzyskiwanie baz danych. Użytkownicy, którzy mają przypisaną tę rolę, mogą łatwo zarządzać bazami danych w danym serwerze, co jest kluczowe w środowiskach, gdzie bazy danych muszą być regularnie aktualizowane lub tworzone od podstaw. Przykładowo, w przypadku rozwijania aplikacji biznesowej, programista może korzystać z tej roli do tworzenia nowych baz danych na potrzeby testów, co pozwala na szybkie wdrażanie oraz iterację w procesie rozwoju oprogramowania. W praktyce, przypisanie roli dbcreator powinno być stosowane z uwagą, aby ograniczyć do minimum dostęp do krytycznych operacji tylko dla zaufanych użytkowników. Dobre praktyki sugerują regularne przeglądanie i audyt przypisania ról oraz monitorowanie działań użytkowników, aby zapobiegać nieautoryzowanym zmianom w strukturze baz danych.

Pytanie 11

Który opis dotyczy metody POST przesyłania formularza?

A. ma ograniczenie długości adresu do 255 znaków

B. dane są przesyłane w adresie URL, widoczne dla użytkownika

C. można ją zapisać jako zakładkę w przeglądarce

D. jest zalecana przy przesyłaniu danych wrażliwych (hasło, numer karty)

Metoda POST przesyła dane w treści żądania (a nie w adresie URL), więc nie są one widoczne w pasku adresu - dlatego zaleca się ją dla danych wrażliwych, jak hasło czy numer karty. Dlatego POST jest zalecana przy danych wrażliwych.

Pytanie 12

Aby przenieść pliki strony internetowej na serwer, można skorzystać z programu:

A. Bugzilla

B. Go!Zilla

C. FileZilla

D. CloneZilla

FileZilla to popularny, darmowy klient FTP, FTPS i SFTP. Umożliwia przesyłanie plików między komputerem a serwerem, dlatego używa się go do publikacji witryny: po połączeniu z kontem na serwerze kopiuje się pliki strony do właściwego katalogu. Obsługuje połączenia szyfrowane i wznawianie transferu. To typowe narzędzie do wdrażania strony, więc poprawną odpowiedzią jest FileZilla.

Pytanie 13

W języku SQL wykonano przedstawione poniżej polecenia GRANT. Kto będzie miał prawo do przeglądania danych oraz ich zmiany?

GRANT ALL ON firmy TO 'adam'@'localhost';
GRANT ALTER, CREATE, DROP ON firmy TO 'anna'@localhost;
GRANT SELECT, INSERT, UPDATE ON firmy TO 'tomasz'@'localhost';

A. Tomasz i Adam

B. Jedynie Tomasz

C. Anna i Tomasz

D. Adam i Anna

Analizując inne odpowiedzi, można zauważyć, że niektóre z nich nie spełniają podstawowych wymogów związanych z przydzielaniem uprawnień w bazach danych. Na przykład, stwierdzenie, że tylko Anna ma prawo do przeglądania i modyfikowania danych, jest błędne, ponieważ w przydzielonych jej uprawnieniach nie ma komendy SELECT, która jest niezbędna do przeglądania danych. Uprawnienia ALTER, CREATE i DROP, które otrzymała, dotyczą jedynie zmiany struktury bazy, a nie samego przeglądania danych, co jest kluczowe dla jej roli w systemie. Warto także zwrócić uwagę na odpowiedź mówiącą o Tomaszu i Annie. Tomasz rzeczywiście ma przydzielone uprawnienia do przeglądania i modyfikacji danych, jednak Anna nie ma uprawnienia SELECT, więc nie może przeglądać danych. Analogicznie, odpowiedź wskazująca na Tomasza i Adama również pomija fakt, że Anna nie ma dostępu do przeglądania danych, co czyni ją nieprawidłową. W kontekście przydzielania uprawnień, istotne jest zrozumienie, że dostęp do danych powinien być zgodny z rolą użytkownika oraz zadaniami, jakie ma do wykonania. Właściwe przydzielenie uprawnień jest fundamentalne w zapewnieniu bezpieczeństwa danych i ich integralności.

Pytanie 14

W zakresie ochrony serwera bazy danych przed atakami hakerównie wlicza się

A. aktywacja zapory

B. blokada portów powiązanych z bazą danych

C. defragmentacja dysków

D. używanie skomplikowanych haseł do bazy

Wybór odpowiedzi związanej z blokowaniem portów, włączeniem zapory oraz stosowaniem złożonych haseł jest zgodny z najlepszymi praktykami w zakresie zabezpieczeń serwera bazy danych. Blokowanie portów to kluczowy krok, który ogranicza dostęp do usług bazodanowych tylko dla autoryzowanych użytkowników. Wiele ataków z zewnątrz wykorzystuje otwarte porty, dlatego ich zablokowanie jest podstawowym zabezpieczeniem. Zapory sieciowe, zarówno sprzętowe, jak i programowe, są niezbędne do filtrowania ruchu i ochrony przed nieautoryzowanym dostępem. Z kolei stosowanie złożonych haseł jest fundamentalnym elementem ochrony danych - hasła powinny być długie, zawierać znaki specjalne, cyfry oraz różne przypadki liter, aby znacznie utrudnić ich złamanie. Praktyczne przykłady pokazują, że organizacje, które nie implementują tych zabezpieczeń, stają się łatwym celem dla cyberprzestępców. Warto również wspomnieć o dodatkowych środkach, takich jak szyfrowanie danych w bazach, co dodatkowo podnosi poziom ochrony informacji. Brak znajomości tych zasad może prowadzić do niedostatecznej ochrony przed zagrożeniami, co w dzisiejszym, złożonym środowisku IT, jest nieakceptowalne.

Pytanie 15

Aby przywrócić bazę danych o nazwie Sklep z pliku towary.sql, należy w miejsce gwiazdek wpisać nazwę użytkownika. Polecenie wygląda następująco:

mysql -u ******* -p Sklep < towary.sql

A. adres IP bazy danych.

B. nazwę odzyskiwanej tabeli.

C. nazwę użytkownika.

D. liczbę importowanych obiektów bazy.

Polecenie mysql ma dość sztywną i dobrze udokumentowaną składnię, więc warto ją sobie poukładać raz a dobrze. W przedstawionym przykładzie mamy: mysql -u ******* -p Sklep < towary.sql. Przełącznik -u w kliencie MySQL zawsze oznacza nazwę użytkownika, czyli konto w systemie bazy danych, którym się logujemy. To nie jest ani adres IP, ani nazwa tabeli, ani żadna liczba obiektów. Klient mysql w ogóle nie przyjmuje w tym miejscu takich danych. Częsty błąd polega na mieszaniu pojęć: adres IP czy hostname serwera bazy podaje się inną opcją, -h (np. -h 192.168.1.10 lub -h db.example.com). Parametr -u nie ma nic wspólnego z lokalizacją serwera, tylko z tożsamością użytkownika w systemie uprawnień MySQL. Podobnie nazwa odzyskiwanej tabeli nie jest nigdzie wpisywana w linii poleceń mysql przy imporcie. Tabele są tworzone i wypełniane wewnątrz pliku SQL – to tam znajdują się instrukcje CREATE TABLE i INSERT, więc nie ma potrzeby ani możliwości podania nazwy jednej konkretnej tabeli w miejscu, gdzie klient oczekuje nazwy użytkownika. Jeśli importujemy tylko jedną tabelę, to i tak cały proces kontroluje zawartość pliku towary.sql, a nie argument -u. Równie mylące jest myślenie o „liczbie importowanych obiektów bazy”. Narzędzie mysql nie ma opcji, w której wpisujemy jakąś liczbę tabel czy rekordów do zaimportowania. Importuje po prostu wszystko, co jest w skrypcie SQL, aż do końca pliku lub do wystąpienia błędu. Właściwy sposób myślenia jest taki: -h mówi „do jakiego serwera się łączę”, -u mówi „kim się loguję”, -p wymusza podanie hasła, dalej podajemy nazwę bazy (Sklep), a znak < przekierowuje zawartość pliku towary.sql na wejście programu. Z mojego doświadczenia wynika, że jak się raz zrozumie to rozdzielenie ról poszczególnych parametrów, to znika większość nieporozumień przy pracy z kopią zapasową i przywracaniem baz danych.

Pytanie 16

Jakie uprawnienia będzie miał użytkownik jan po wykonaniu poniższych poleceń na bazie danych?

GRANT ALL PRIVILEGES ON klienci TO jan;
REVOKE SELECT, INSERT, UPDATE, DELETE ON klienci FROM jan;

A. Będzie mógł zmieniać strukturę tabeli klienci.

B. Będzie mógł eliminować rekordy z tabeli klienci.

C. Będzie mógł przeszukiwać dane w tabeli klienci.

D. Będzie mógł dodawać rekordy do tabeli klienci.

Odpowiedź "Będzie mógł zmienić strukturę tabeli klienci" jest prawidłowa, ponieważ użytkownik jan zyskał pełne uprawnienia do tabeli klienci za pomocą polecenia GRANT ALL PRIVILEGES. Oznacza to, że posiada on wszystkie dostępne uprawnienia w tym zakresie, w tym możliwość modyfikacji struktury tabeli, co obejmuje dodawanie lub usuwanie kolumn, zmienianie typów danych oraz wprowadzanie modyfikacji do indeksów. Jednakże, zastosowane polecenie REVOKE powoduje odebranie wybranych uprawnień, tj. SELECT, INSERT, UPDATE oraz DELETE. W związku z tym, mimo że jan może zmieniać strukturę tabeli, nie ma już możliwości wprowadzania, usuwania ani przeglądania danych. Praktycznie, na przykład, jeżeli jan chciałby dodać nową kolumnę do tabeli klienci, ma taką możliwość, jednak nie będzie mógł dodać nowych rekordów ani ich edytować. To podejście jest zgodne z najlepszymi praktykami zarządzania uprawnieniami w systemach baz danych, gdzie ważne jest precyzyjne określenie, jakie operacje mogą być realizowane przez różnych użytkowników.

Pytanie 17

Odizolowane środowisko ogólnego przeznaczenia, utworzone na fizycznym serwerze z wykorzystaniem wirtualizacji, to:

A. serwer VPS

B. serwer dedykowany

C. serwer DHCP

D. serwer aplikacji

Pozostałe pojęcia oznaczają coś innego. Serwer aplikacji to oprogramowanie uruchamiające konkretne aplikacje (np. dla danego frameworka) - to rola serwera, a nie sposób jego utworzenia przez wirtualizację. Serwer dedykowany to cała fizyczna maszyna oddana jednemu klientowi na wyłączność, więc nie jest „odizolowanym środowiskiem na współdzielonym sprzęcie”. Serwer DHCP odpowiada za automatyczne przydzielanie adresów IP w sieci. Odizolowane środowisko utworzone wirtualizacją na fizycznym serwerze to VPS, dlatego ta odpowiedź jest poprawna.

Pytanie 18

W SQL przeprowadzono zapytanie, jednak jego realizacja nie powiodła się, co skutkowało błędem: #1396 - Operation CREATE USER failed for 'anna'@'localhost'. Możliwą przyczyną takiego zachowania bazy danych może być

CREATE USER 'anna'@'localhost' IDENTIFIED BY '54RTu8';

A. niewystarczające hasło dla konta anna

B. istnienie użytkownika anna w bazie

C. nieznane polecenie CREATE USER

D. błędna składnia polecenia CREATE USER

Odpowiedź wskazująca na istnienie użytkownika 'anna' w bazie jest prawidłowa, ponieważ MySQL nie pozwala na tworzenie nowego użytkownika, jeśli użytkownik o takiej samej nazwie już istnieje. W przypadku próby wykonania kwerendy CREATE USER dla istniejącego użytkownika, system generuje błąd #1396, co jest zgodne z zasadami zarządzania użytkownikami w bazach danych. Dobra praktyka polega na sprawdzaniu, czy użytkownik już istnieje przed próbą jego utworzenia, co można zrobić za pomocą zapytania SELECT z tabeli mysql.user. Jeśli użytkownik 'anna' byłby już zdefiniowany, aby uniknąć błędów, programista powinien najpierw usunąć istniejącego użytkownika lub zmodyfikować jego uprawnienia, jeżeli to konieczne. Stosowanie poprawnych procedur zarządzania użytkownikami oraz regularne audyty kont użytkowników są kluczowe dla bezpieczeństwa i wydajności systemu baz danych.

Pytanie 19

Z jakim problemem wiąże się poziom izolacji transakcji Repeatable Read (powtarzalny odczyt)?

A. z odczytami widmowymi (phantom reads)

B. z brudnymi odczytami

C. z niepowtarzalnymi odczytami

D. z utratą aktualizacji

Poziom izolacji Repeatable Read gwarantuje, że te same wiersze odczytane w transakcji nie zmienią się - ale wciąż dopuszcza ODCZYTY WIDMOWE (phantom reads): gdy inna transakcja DODA nowe wiersze pasujące do warunku, powtórne zapytanie może zwrócić ich więcej. Zapamiętaj: Repeatable Read blokuje zmiany istniejących wierszy, lecz nie pojawianie się nowych (widm).

Pytanie 20

Aby stworzyć poprawną kopię zapasową bazy danych, która będzie mogła zostać później przywrócona, należy najpierw sprawdzić

A. możliwość udostępnienia bazy danych

B. poprawność składni zapytań

C. uprawnienia dostępu do serwera bazy danych

D. spójność bazy

Sprawdzanie możliwości udostępniania bazy danych jest ważne, ale nie ma bezpośredniego wpływu na jakość i integralność samej kopii bezpieczeństwa. Może to dotyczyć kwestii użytkowników i ról, jednak nawet przy poprawnym udostępnieniu, jeżeli dane są niespójne, kopia może być bezużyteczna. Prawa dostępu do serwera bazy danych, choć istotne z punktu widzenia bezpieczeństwa, również nie wpływają na jakość danych. Użytkownik mógłby mieć pełne prawa dostępu, ale to nie gwarantuje, że baza danych jest poprawna i gotowa do stworzenia kopii zapasowej. Poprawność składni zapytań to kolejny aspekt ważny dla efektywnego działania bazy danych, jednak w kontekście wykonywania kopii zapasowej, nie odnosi się bezpośrednio do spójności danych. Nawet poprawnie sformułowane zapytania mogą prowadzić do błędnych wyników, jeśli dane w bazie są w złym stanie. Dlatego też, żadne z wymienionych zagadnień nie zastąpi konieczności sprawdzenia spójności bazy jako kluczowego elementu przed wykonaniem kopii bezpieczeństwa.

Pytanie 21

Po wykonaniu przedstawionego poniżej polecenia SQL użytkownik Ela będzie mógł

GRANT SELECT, INSERT, UPDATE, DELETE ON baza1.tab1 TO 'Ela'@'localhost';

A. wykonywania wszelkich działań na danych

B. jedynie dodawania i edytowania danych

C. wykonywania wszystkich operacji na strukturze danych

D. jedynie tworzenia i zmiany struktury tabel

Polecenie SQL GRANT SELECT INSERT UPDATE DELETE ON baza1.tab1 TO 'Ela'@'localhost' przyznaje użytkownikowi Ela pełny dostęp do danych w tabeli tab1 w bazie danych baza1. Oznacza to możliwość wykonywania wszystkich operacji związanych z zarządzaniem danymi w tej tabeli. Komenda GRANT jest używana do nadawania uprawnień użytkownikom bazy danych. W tym przypadku uprawnienia obejmują SELECT do odczytu danych INSERT do dodawania nowych rekordów UPDATE do modyfikacji istniejących danych oraz DELETE do usuwania rekordów. Uprawnienia te pokrywają pełne spektrum operacji związanych z manipulacją danymi co jest kluczowe w sytuacjach gdzie użytkownik musi mieć elastyczność w zarządzaniu zawartością tabeli. Dobrymi praktykami jest ograniczanie nadawania takich szerokich uprawnień tylko wtedy gdy jest to absolutnie konieczne w celu minimalizacji ryzyka nieautoryzowanej manipulacji danymi. Rozumienie i zarządzanie uprawnieniami użytkowników jest kluczowym elementem bezpieczeństwa bazy danych ponieważ pozwala na kontrolę dostępu i zapewnienie integralności danych. Tak szeroki dostęp jak w tym przypadku powinien być przyznawany z rozwagą i jedynie zaufanym użytkownikom w środowiskach produkcyjnych gdzie dane są szczególnie wrażliwe.

Pytanie 22

Jakie zadania programistyczne należy wykonać na serwerze?

A. Ukrywanie i wyświetlanie elementów strony w zależności od aktualnej pozycji kursora

B. Weryfikacja danych wprowadzonych do pola tekstowego na bieżąco

C. Zmiana stylu HTML na stronie spowodowana ruchem kursora

D. Zapisanie danych pozyskanych z aplikacji internetowej w bazie danych

Wszystkie pozostałe zadania, takie jak zmiana stylu HTML na stronie wywołana przesunięciem kursora, sprawdzenie danych wpisanych do pola tekstowego w czasie rzeczywistym, czy ukrywanie i pokazywanie elementów strony w zależności od aktualnego stanu kursora, są zadaniami, które powinny być realizowane po stronie klienta. Podejście to wynika z faktu, iż interakcje z użytkownikiem powinny być jak najbardziej responsywne i natychmiastowe, co jest możliwe jedynie przy użyciu JavaScriptu w przeglądarkach. Na przykład, zmiana stylu HTML jest operacją, która nie wymaga komunikacji z serwerem, ponieważ wszystkie potrzebne informacje są już dostępne na kliencie. W przypadku sprawdzania danych w czasie rzeczywistym, przetwarzanie odbywa się lokalnie, co pozwala na natychmiastowe informowanie użytkownika o błędach w formularzach bez opóźnienia wynikającego z oczekiwania na odpowiedź serwera. Ukrywanie i pokazywanie elementów strony również powinno być realizowane po stronie klienta, aby zapewnić płynność interakcji. Użytkownicy oczekują szybkiej reakcji na swoje działania, a operacje po stronie klienta, takie jak animacje czy zmiany widoczności elementów, są znacznie bardziej efektywne, gdy są wykonywane lokalnie, ponieważ nie wymagają dodatkowych zasobów serwera ani czasu przetwarzania. W przeciwnym razie, realizacja tych zadań na serwerze prowadziłaby do zbędnych opóźnień i obciążenia infrastruktury serwerowej, co w konsekwencji ograniczyłoby wydajność i doświadczenie użytkownika.

Pytanie 23

Polecenie serwera MySQL postaci

REVOKE DELETE, UPDATE ON pracownicy FROM 'tKowal'@'localhost'

sprawi, że użytkownikowi tKowal zostaną

A. przydzielone uprawnienia do wszelkiej zmiany struktury tabeli pracownicy

B. przydzielone uprawnienia do usuwania i aktualizowania danych w tabeli pracownicy

C. odebrane uprawnienia usuwania i modyfikowania danych w tabeli pracownicy

D. odebrane uprawnienia usuwania i dodawania rekordów w tabeli pracownicy

Wszystkie niepoprawne odpowiedzi dotyczą różnych aspektów zarządzania uprawnieniami w MySQL, ale nie odzwierciedlają skutków działania polecenia REVOKE. W pierwszej z nieprawidłowych odpowiedzi stwierdza się, że użytkownik otrzymuje prawa do usuwania i aktualizowania danych w tabeli 'pracownicy'. Jest to nieprawda, ponieważ komenda REVOKE ma na celu odebranie, a nie przydzielenie jakichkolwiek uprawnień. Kolejna odpowiedź sugeruje, że użytkownik traci prawa do usuwania i dodawania rekordów w tabeli. Chociaż uprawnienie do usuwania jest słuszne, dodawanie rekordów (INSERT) nie zostało wymienione w poleceniu REVOKE, więc ta odpowiedź jest myląca. Ostatnia niepoprawna opcja wskazuje, że użytkownik zyskuje prawa do zmiany struktury tabeli 'pracownicy'. W rzeczywistości REVOKE nie ma nic wspólnego z uprawnieniami związanymi ze strukturą tabeli, takimi jak ALTER czy CREATE. Właściwe zrozumienie mechanizmów zarządzania uprawnieniami jest kluczowe dla zapewnienia bezpieczeństwa danych oraz skutecznego zarządzania bazą danych w MySQL.

Pytanie 24

Domyślna CAPTCHA

CAPTCHA - reCAPTCHA▼

W CMS Joomla! opcja konfiguracji globalnej, pokazana na ilustracji, służy do

A. wyświetlenia okna umożliwiającego wyszukiwanie tekstu na stronie.

B. wyświetlania okna informującego o zgodzie użytkownika na pliki cookie.

C. dopuszczenia do przesyłania danych z formularzy wypełnionych tylko przez człowieka.

D. zapobiegania atakom typu SQL Injection.

Na ilustracji widoczna jest opcja wyboru domyślnej CAPTCHA w konfiguracji globalnej Joomla!, czyli mechanizmu służącego do ochrony formularzy przed botami. Łatwo tu wpaść w kilka typowych pułapek myślowych i skojarzyć ten element z innymi funkcjami bezpieczeństwa lub interfejsu, które z CAPTCHA nie mają wiele wspólnego.

Częstym błędem jest utożsamianie każdego „zabezpieczenia” w panelu administracyjnym z ochroną przed SQL Injection lub innymi atakami na bazę danych. Ochrona przed SQL Injection polega na poprawnym programowaniu po stronie serwera: stosowaniu przygotowanych zapytań (prepared statements), filtrowaniu i walidacji danych wejściowych, poprawnym użyciu API bazy danych. CAPTCHA w ogóle nie dotyka warstwy SQL – jej zadaniem jest ograniczenie liczby automatycznych zgłoszeń z formularzy, a nie filtrowanie treści pod kątem złośliwych zapytań. To jest inna warstwa zabezpieczeń.

Podobnie mylące bywa skojarzenie z wyszukiwarką na stronie. Okno wyszukiwania to zwykły formularz z polem tekstowym, którego wygląd i działanie zależy od modułu lub komponentu wyszukiwarki, a nie od globalnej opcji „Domyślna CAPTCHA”. Ustawienie CAPTCHA nie dodaje żadnego pola wyszukiwania, nie wpływa też na mechanizm przeszukiwania treści, tylko na to, czy przed wysłaniem formularza pojawi się test antybotowy.

Kolejne skojarzenie to okna związane z RODO i zgodą na pliki cookie. Bannery cookie, pop-upy z informacją o polityce prywatności czy zgody marketingowe są realizowane przez osobne wtyczki lub skrypty JavaScript, często całkowicie niezależne od mechanizmu CAPTCHA. Ich zadaniem jest spełnienie wymogów prawnych, a nie weryfikacja, czy użytkownik jest człowiekiem. CAPTCHA nie służy do obsługi zgód na cookies, nie zarządza ciasteczkami, nie pokazuje komunikatów o prywatności.

Sedno tej opcji w Joomla! polega na wskazaniu, który mechanizm antybotowy ma być standardowo używany w formularzach. Dzięki temu dane z formularzy mogą być przyjmowane tylko wtedy, gdy użytkownik przejdzie test potwierdzający, że nie jest automatem. Jeśli myli się tę funkcję z wyszukiwaniem, banerem cookie czy obroną przed SQL Injection, to w praktyce oznacza niezrozumienie warstwowego podejścia do bezpieczeństwa i użyteczności: CAPTCHA to filtr na poziomie interakcji człowiek–formularz, a nie ogólny „magiczny przełącznik” bezpieczeństwa lub interfejsu.

Pytanie 25

Podane w ramce polecenie SQL nadaje prawo SELECT

GRANT SELECT ON hurtownia.* TO 'sprzedawca'@'localhost';

A. do wszystkich tabel w bazie hurtownia.

B. do wszystkich pól w tabeli hurtownia.

C. dla użytkownika 'root' na serwerze localhost.

D. dla użytkownika 'root' na serwerze sprzedawca.

To polecenie GRANT jest typowym przykładem, gdzie drobny szczegół składni całkowicie zmienia znaczenie. Wiele osób intuicyjnie myśli, że skoro pojawia się nazwa hurtownia, to chodzi o tabelę o takiej nazwie, albo że skoro często pracuje się na koncie root, to uprawnienia dotyczą właśnie jego. Tutaj jednak kluczowe są dwie rzeczy: zapis hurtownia.* oraz dokładna forma 'sprzedawca'@'localhost'.
W MySQL konstrukcja nazwa_bazy.* jednoznacznie oznacza całą bazę danych, czyli wszystkie tabele znajdujące się w tej bazie. Gwiazdka nie oznacza „wszystkich pól w tabeli”, jak w SELECT * FROM tabela; tylko „wszystkie obiekty danego typu w tym kontekście”, czyli w tym wypadku wszystkie tabele w bazie hurtownia. Błąd myślowy bierze się stąd, że ludzie przenoszą swoje skojarzenia z SELECT * na GRANT, a to są jednak różne miejsca w składni SQL.
Jeśli chcielibyśmy nadać uprawnienie tylko do jednej tabeli, używamy zapisu nazwa_bazy.nazwa_tabeli, bez gwiazdki. Na przykład GRANT SELECT ON hurtownia.klienci TO 'sprzedawca'@'localhost'; dotyczyłoby tylko tabeli klienci. Wtedy dopiero można by mówić o dostępie do wszystkich pól w tej konkretnej tabeli, bo SELECT z założenia domyślnie widzi wszystkie kolumny, chyba że zastosujemy uprawnienia na poziomie kolumn, co jest już bardziej zaawansowanym tematem.
Druga częsta pomyłka to utożsamianie każdego polecenia GRANT z użytkownikiem root. W MySQL użytkownik jest identyfikowany przez parę login@host. W naszym przykładzie stoi tam wyraźnie 'sprzedawca'@'localhost', więc nie ma tu żadnego roota. Gdyby chodziło o konto root, składnia musiałaby wyglądać np. 'root'@'localhost'. Co więcej, host sprzedawca w ogóle nie występuje w tym poleceniu – pojawia się tylko jako nazwa użytkownika. To powoduje czasem dodatkowe zamieszanie: ktoś widzi słowo sprzedawca i myśli, że to nazwa serwera, a localhost to użytkownik, co jest całkowicie odwrotnie.
Z punktu widzenia dobrych praktyk administracji bazą danych, nadawanie uprawnień rootowi poleceniem GRANT w aplikacjach produkcyjnych jest zresztą złym pomysłem. Standardem jest tworzenie osobnych kont, takich jak sprzedawca, księgowy czy aplikacja_web, z precyzyjnie dobranymi uprawnieniami do konkretnych baz. Wtedy dokładnie wiemy, kto może co czytać i modyfikować. Z mojego doświadczenia wynika, że większość problemów z bezpieczeństwem wynika właśnie z używania zbyt szerokich uprawnień, głównie konta root tam, gdzie absolutnie nie jest potrzebne.
Podsumowując: to polecenie nie nadaje dostępu do „wszystkich pól w tabeli hurtownia”, bo hurtownia jest tu bazą, a nie tabelą. Nie dotyczy też użytkownika root ani żadnego serwera o nazwie sprzedawca. Nadaje ono prawo SELECT do wszystkich tabel w bazie hurtownia konkretnemu użytkownikowi o nazwie sprzedawca, który łączy się z hosta localhost. Zrozumienie tej składni jest kluczowe przy zarządzaniu uprawnieniami w MySQL i ogólnie w systemach baz danych.

Pytanie 26

W jaki sposób lokalny System Zarządzania Bazą Danych (SZBD) udostępnia bazę?

A. jako serwer w sieci

B. w chmurze obliczeniowej

C. jako usługę serwerową w sieci

D. wyłącznie na jednym, wyznaczonym komputerze

Udostępnianie bazy w sieci, jako usługi serwerowej czy w chmurze to cechy SZBD SIECIOWEGO lub serwerowego, a nie lokalnego. Lokalny system zarządzania bazą działa wyłącznie na jednym komputerze.

Pytanie 27

Co oznacza termin „upload” danych?

A. opóźnienie w transmisji pliku

B. trasę transferu pliku

C. pobieranie plików z serwera

D. przesyłanie plików na serwer

Pozostałe opisy dotyczą czego innego. POBIERANIE plików z serwera to „download” (kierunek odwrotny). „Trasa transferu” i „opóźnienie w transmisji” to pojęcia sieciowe niezwiązane z samym kierunkiem przesyłu. Wysyłanie plików na serwer to upload.

Pytanie 28

W języku SQL zrealizowano polecenia GRANT przedstawione w ramce. Kto uzyska prawo do przeglądania i modyfikowania danych?

GRANT ALL ON frmy TO 'adam'@'localhost';
GRANT ALTER, CREATE, DROP ON frmy TO 'anna'@'localhost';
GRANT SELECT, INSERT, UPDATE ON frmy TO 'tomasz'@'localhost';

A. Jedynie Tomasz

B. Tomasz i Adam

C. Tomasz oraz Anna

D. Adam oraz Anna

Wybór odpowiedzi, który wskazuje na tylko jednego użytkownika, jest nieprawidłowy, ponieważ nie uwzględnia pełnego zakresu przyznanych uprawnień. Tomasz, dzięki poleceniu 'GRANT SELECT, INSERT, UPDATE', ma przyznane prawo do przeglądania (SELECT) oraz modyfikacji (INSERT, UPDATE) danych w bazie 'frmy'. Odpowiedzi wskazujące wyłącznie na Tomasza pomijają fakt, że Adam również ma pełne uprawnienia do tej samej bazy danych, a więc równie dobrze może przeglądać i zmieniać dane. W przypadku Anny, jej przyznane uprawnienia dotyczą głównie operacji strukturalnych (ALTER, CREATE, DROP), co nie daje jej możliwości przeglądania ani modyfikacji danych, co czyni ją niewłaściwym wyborem w kontekście omawianego pytania. Typowym błędem w analizie takich pytań jest poleganie na domniemaniach dotyczących uprawnień, zamiast dokładnego zapoznania się z przyznanymi rolami i uprawnieniami. Właściwe zrozumienie i analiza poleceń GRANT w SQL są kluczowe dla efektywnego zarządzania bazami danych oraz zapewnienia odpowiedniego poziomu bezpieczeństwa informacyjnego.

Pytanie 29

Uprawnienia obiektowe nadawane użytkownikom bazy danych mogą zezwalać lub zabraniać:

A. wykonywania instrukcji typu tworzenie kopii zapasowej

B. zmiany ról i kont użytkowników

C. dziedziczenia uprawnień

D. wykonywania operacji na danych, np. wstawiania lub modyfikowania

Pozostałe opcje to uprawnienia SYSTEMOWE lub administracyjne, a nie obiektowe. Zmiana ról i kont użytkowników oraz wykonywanie kopii zapasowej to operacje na poziomie serwera. „Dziedziczenie uprawnień” to mechanizm, a nie operacja na danych. Uprawnienia obiektowe rządzą operacjami na danych.

Pytanie 30

Używając komendy BACKUP LOG w MS SQL Server, można

A. wykonać kopię zapasową dziennika transakcyjnego

B. zalogować się do kopii zapasowej

C. zrealizować pełną kopię zapasową

D. odczytać komunikaty generowane podczas tworzenia kopii

Polecenie BACKUP LOG w MS SQL Server służy do wykonywania kopii zapasowej dziennika transakcyjnego, co jest kluczowe dla zapewnienia integralności danych w bazach danych transakcyjnych. Dziennik transakcyjny rejestruje wszystkie zmiany dokonane w bazie, co pozwala na odtworzenie stanu bazy na dany moment oraz na przywrócenie bazy do stanu sprzed awarii. Wykonując kopię zapasową dziennika transakcyjnego, użytkownicy mogą minimalizować ryzyko utraty danych, ponieważ pozwala to na przywrócenie bazy do najnowszego stanu przed wystąpieniem awarii. W praktyce, regularne tworzenie takich kopii jest częścią polityki backupu, która powinna być dostosowana do potrzeb organizacji oraz do intensywności operacji na bazie danych. Ustalając harmonogram kopii zapasowych, należy także brać pod uwagę obciążenie bazy danych oraz wymagania dotyczące RPO (Recovery Point Objective) i RTO (Recovery Time Objective). Według najlepszych praktyk, zaleca się wykonywanie kopii zapasowych dziennika transakcyjnego przynajmniej co kilka godzin, a w środowisku o wysokiej dostępności – nawet co kilka minut.

Pytanie 31

Jakie uprawnienia są konieczne do wykonania oraz przywrócenia kopii zapasowej bazy danych Microsoft SQL Server 2005 Express?

A. Administrator systemu

B. Users

C. Security users

D. Użytkownik lokalny

Aby wykonać i odtworzyć kopię zapasową bazy danych Microsoft SQL Server 2005 Express, wymagane jest posiadanie uprawnień administratora systemu. Administratorzy mają pełny dostęp do wszystkich funkcji i zasobów systemu, co jest kluczowe podczas zarządzania kopiami zapasowymi, które są niezbędne dla bezpieczeństwa i integralności danych. W kontekście SQL Server, administratorzy mogą korzystać z różnych narzędzi, takich jak SQL Server Management Studio (SSMS), aby tworzyć kopie zapasowe baz danych oraz przywracać je w razie potrzeby. Dobrą praktyką jest regularne tworzenie kopii zapasowych, co pozwala na minimalizację ryzyka utraty danych wskutek awarii systemu, błędów ludzkich czy ataków złośliwego oprogramowania. Ponadto, znajomość polityk przechowywania kopii zapasowych, takich jak ich rotacja i przechowywanie w bezpiecznych lokalizacjach, stanowi integralną część zarządzania danymi w organizacji. Warto również pamiętać o testowaniu procesów przywracania danych, aby upewnić się, że w sytuacji kryzysowej dostęp do informacji będzie możliwy w sposób szybki i efektywny.

Pytanie 32

Po awarii serwera bazy danych, aby jak najszybciej przywrócić pełne działanie bazy, konieczne jest wykorzystanie

A. kompletnej listy użytkowników serwera

B. opisu struktur danych w tabelach

C. najświeższej wersji instalacyjnej serwera

D. aktualnej wersji kopii zapasowej

Aby skutecznie przywrócić działanie bazy danych po jej uszkodzeniu, kluczowe jest wykorzystanie aktualnej wersji kopii zapasowej. Kopie zapasowe są fundamentem każdego planu odzyskiwania danych i powinny być regularnie tworzone zgodnie z polityką zarządzania danymi. Przykładowo, jeśli korzystamy z bazy danych w środowisku produkcyjnym, zaleca się wykonywanie codziennych kopii zapasowych oraz pełnych kopii co tydzień. W przypadku awarii, przywrócenie systemu do stanu sprzed incydentu za pomocą najnowszej kopii zapasowej minimalizuje utratę danych i przestoje. Praktyki takie jak backup w czasie rzeczywistym (real-time backup) mogą być również rozważane, aby ograniczyć ryzyko utraty danych. W kontekście standardów branżowych, organizacje powinny stosować zasady RTO (Recovery Time Objective) i RPO (Recovery Point Objective), które pomogą w określeniu najodpowiedniejszej strategii tworzenia kopii zapasowych i ich przechowywania. Zastosowanie aktualnych kopii zapasowych jest zatem najskuteczniejszym sposobem na przywrócenie funkcjonalności bazy danych.

Pytanie 33

Jakie uprawnienia posiada użytkownik jan po wykonaniu poniższych poleceń na bazie danych?

GRANT ALL PRIVILEGES ON klienci TO jan;

REVOKE SELECT, INSERT, UPDATE, DELETE ON klienci FROM jan;

A. Będzie miał możliwość wstawiania rekordów do tabeli klienci

B. Będzie miał możliwość wyszukiwania danych w tabeli klienci

C. Będzie miał możliwość usuwania rekordów z tabeli klienci

D. Będzie miał możliwość zmiany struktury tabeli klienci

Odpowiedź jest poprawna, ponieważ po wykonaniu poleceń SQL użytkownik jan ma przyznane wszystkie uprawnienia do tabeli klienci, a następnie odebrano mu konkretne uprawnienia do wykonywania operacji SELECT, INSERT, UPDATE oraz DELETE. Oznacza to, że jedynym uprawnieniem, które pozostaje jemu po tych operacjach, jest możliwość zmiany struktury tabeli, co oznacza operacje takie jak ADD COLUMN czy DROP COLUMN. W praktyce, gdy przyznajemy użytkownikowi rolę, często stosujemy uprawnienia do wykonywania operacji DDL (Data Definition Language), które są niezbędne do modyfikacji schematu bazy danych. Odpowiedzi na pytania dotyczące uprawnień powinny uwzględniać kontekst celów administracyjnych, ponieważ różne role użytkowników mogą mieć różne poziomy dostępu. W związku z tym, zrozumienie systemu uprawnień w kontekście zarządzania bazą danych jest kluczowe, a dobrym standardem jest nadawanie użytkownikom tylko tych uprawnień, które są niezbędne do wykonywania ich zadań.

Pytanie 34

Wymień dwa sposoby na zabezpieczenie bazy danych w Microsoft Access.

A. Używanie funkcji anonimowych oraz ustawienie hasła dostępu do bazy danych

B. Zaszyfrowanie pliku bazy danych oraz wysyłanie SMS-ów z kodem autoryzacyjnym

C. Wprowadzenie zabezpieczeń na poziomie użytkownika oraz sesji

D. Określenie hasła do otwarcia bazy danych oraz wprowadzenie zabezpieczeń na poziomie użytkownika

Odpowiedzi sugerujące stosowanie funkcji anonimowych oraz SMS-ów z kodem autoryzującym nie są właściwe w kontekście zabezpieczania bazy danych Microsoft Access. Funkcje anonimowe nie istnieją w standardowym pakiecie Access, co czyni tę koncepcję niepraktyczną i mylącą. W praktyce, anonimowość w systemach baz danych nie jest pożądana, ponieważ uniemożliwia identyfikację użytkowników oraz monitorowanie ich działań, co jest kluczowe dla bezpieczeństwa i zgodności z regulacjami prawnymi, takimi jak RODO. Ponadto, pomysł zabezpieczenia bazy danych za pomocą SMS-ów z kodami autoryzującymi jest stosunkowo nieodpowiedni dla tego typu systemu, ponieważ Microsoft Access nie obsługuje natywnie autoryzacji dwuskładnikowej ani nie jest zaprojektowany do integracji z zewnętrznymi systemami SMS. Takie podejście nie tylko wprowadza dodatkowe ryzyko związane z bezpieczeństwem, ale również stwarza problemy praktyczne, takie jak zależność od zewnętrznych usług, co może prowadzić do przestojów w dostępie do danych. Dlatego kluczowe jest zastosowanie sprawdzonych metod zabezpieczeń, takich jak hasła i uprawnienia użytkowników, które są standardem w zarządzaniu danymi i zapewniają właściwą ochronę przed zagrożeniami.

Pytanie 35

Jakie mechanizmy przydzielania zabezpieczeń, umożliwiające wykonywanie działań na bazie danych, są związane z tematyką zarządzania kontami, użytkownikami oraz ich uprawnieniami?

A. Z właściwościami

B. Z przywilejami systemowymi

C. Z przywilejami obiektowymi

D. Z zasadami

Zarządzanie dostępem do baz danych często opiera się na kilku koncepcjach, które jednak nie są właściwymi odpowiedziami na postawione pytanie. Reguły, jako mechanizmy kontroli dostępu, mogą definiować warunki, które muszą być spełnione, aby użytkownik mógł uzyskać dostęp do danych, jednakże same w sobie nie są odpowiednie do opisywania systemowego nadawania uprawnień. Reguły mogą być stosowane w kontekście bardziej skomplikowanych polityk bezpieczeństwa, ale nie są bezpośrednio związane z przywilejami systemowymi. Atrybuty, z drugiej strony, odnoszą się do cech lub właściwości obiektów w bazie danych, takie jak typ danych, długość czy wartość, ale nie mają one wpływu na systemowe zarządzanie uprawnieniami. W kontekście zabezpieczeń atrybuty mogą być używane w modelach opartych na atrybutach, ale nie są one kluczowe w kontekście przydzielania przywilejów. Przywileje obiektowe to zbiór uprawnień przypisanych do konkretnych obiektów, takich jak tabele czy widoki, które pozwalają użytkownikom na wykonywanie określonych operacji, jak SELECT, INSERT, UPDATE czy DELETE. Chociaż są one istotnym elementem ochrony danych, to jednak nie obejmują one szerszego zarządzania kontami i użytkownikami, które obejmuje również przywileje systemowe. W związku z tym, odpowiedzi te nie dostarczają pełnego obrazu mechanizmów zabezpieczeń stosowanych w zarządzaniu bazami danych.

Pytanie 36

Jakie środowisko jest wymagane do uruchomienia systemu CMS Joomla! (domyślna konfiguracja)?

A. IIS, Perl i MySQL

B. Python i MySQL

C. Apache, PHP i MySQL

D. C++ i MySQL

Pozostałe zestawy nie pasują do Joomli. C++ i Python to inne języki (Joomla działa w PHP). IIS z Perlem to środowisko spoza domyślnej konfiguracji Joomli. Wymagane jest Apache, PHP i MySQL.

Pytanie 37

Który typ komunikatu jest przesyłany WYŁĄCZNIE „w dół” - od kierownika do pracownika?

A. uwagi dotyczące polityki organizacji

B. powierzenie zadania

C. poszukiwanie rozwiązań

D. zgłaszanie

Pozostałe komunikaty płyną inaczej. „Zgłaszanie” (np. problemu) idzie „w GÓRĘ”, od pracownika do kierownika. „Poszukiwanie rozwiązań” to zwykle współpraca dwustronna, a „uwagi o polityce organizacji” mogą płynąć w obie strony. Wyłącznie „w dół” idzie powierzenie zadania.

Pytanie 38

Które polecenie MySQL służy do odebrania uprawnień użytkownikowi?

REVOKE

GRANT

RENAME

CREATE

Odebranie wcześniej nadanych uprawnień realizuje polecenie REVOKE, np. REVOKE INSERT ON baza.* FROM anna;. To przeciwieństwo GRANT, obie należą do grupy DCL (sterowanie dostępem). Zapamiętaj parę: GRANT daje, REVOKE odbiera.

Pytanie 39

W SQL, aby zabezpieczyć kwerendę CREATE USER przed utworzeniem konta, jeżeli ono już istnieje, należy użyć składni

A. CREATE OR REPLACE USER 'anna'@'localhost' IDENTIFIED BY 'yu&T%';

B. CREATE USER 'anna'@'localhost' IDENTIFIED BY 'yu&T%';

C. CREATE USER OR DROP 'anna'@'localhost' IDENTIFIED BY 'yu&T%';

D. CREATE USER IF NOT EXISTS 'anna'@'localhost' IDENTIFIED BY 'yu&T%';

Odpowiedzi takie jak 'CREATE USER 'anna'@'localhost' IDENTIFIED BY 'yu&T%';' są nieprawidłowe, ponieważ nie zawierają mechanizmu do weryfikacji istnienia użytkownika przed jego utworzeniem. W przypadku, gdy konto o nazwie 'anna' już istnieje, wykona się próba utworzenia go ponownie, co skutkuje błędem. Tego typu podejście nie tylko narusza praktyki zarządzania bazami danych, ale również wprowadza potencjalne problemy z bezpieczeństwem, gdyż mogą wystąpić niezamierzone konsekwencje w przypadku nadpisania istniejących uprawnień. Odpowiedź 'CREATE USER OR DROP 'anna'@'localhost' IDENTIFIED BY 'yu&T%';' także jest błędna, gdyż takiej składni nie definiuje standard SQL. 'CREATE OR REPLACE USER 'anna'@'localhost' IDENTIFIED BY 'yu&T%';' myli pojęcie zastępowania użytkownika, gdyż nie zawsze jest to pożądane. Użytkownicy mogą mieć różne uprawnienia, a ich usunięcie lub nadpisanie może prowadzić do problemów z dostępem. Takie myślenie często prowadzi do błędnych założeń, że można swobodnie zarządzać użytkownikami bez przemyślanej strategii, co może skutkować poważnymi lukami w bezpieczeństwie oraz problemami z audytem. Zrozumienie, jak ważne jest stosowanie odpowiednich praktyk przy zarządzaniu kontami użytkowników w bazach danych, jest kluczowe dla zapewnienia ich integralności oraz ochrony danych.

Pytanie 40

W MySQL nadanie roli DBManager użytkownikowi pozwala na uzyskanie praw umożliwiających

A. wszelkie operacje na bazach danych serwera

B. wszystkie działania na bazach danych oraz użytkownikach serwera

C. nadzorowanie serwera

D. tworzenie kont użytkowników na serwerze oraz przypisywanie im haseł

Odpowiedź 'wszelkie operacje na bazach danych serwera' jest prawidłowa, ponieważ rola DBManager w MySQL przyznaje użytkownikowi pełne uprawnienia do zarządzania bazami danych. Obejmuje to możliwość tworzenia, modyfikowania i usuwania baz danych oraz tabel, a także wykonywania zapytań w tych bazach. Rola ta jest użyteczna w kontekście administracji bazami danych, gdzie administratorzy muszą mieć dostęp do wszystkich funkcji związanych z danymi. Przykładowo, administrator może wykorzystać tę rolę do optymalizacji wydajności baz danych poprzez indeksowanie tabel lub do tworzenia kopii zapasowych. Z perspektywy dobrych praktyk, nadawanie ról z odpowiednimi uprawnieniami powinno być przeprowadzane z rozwagą, aby zminimalizować ryzyko nieautoryzowanego dostępu i zapewnić integralność danych. Warto również pamiętać, że w MySQL można zastosować szczegółowe uprawnienia dla poszczególnych użytkowników, co pozwala na dostosowanie dostępu do konkretnych zadań w organizacji.

Rozpocznij nowy egzamin

Powrót do strony głównej